You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Joe Niski <jo...@NWEA.org> on 2010/08/17 02:00:40 UTC
durable subscription problems
i have a network of 2 brokers, let's call them "Remote" and "Central", running on ActiveMQ 5.0.3, in a store-and-forward configuration. i inherited this setup, i did not design it, but it seems like a generally solid configuration.
On the Remote broker, there are topics (e.g. "org.nwea.topics.license") that have durable subscriptions to topics of the same name on the Central broker. Messages that are published to topics on the Central broker find their way to Remote really fast - as long as the Remote is online when the message is published. Messages that are published when Remote is offline are never picked up by the remote.
i have a j2ee application that contains MDBs that are annotated to have durable subscriptions to the topics on the Remote broker.
The NetworkConnector configuration in the Remote broker's activemq.xml looks like this:
<networkConnectors>
<networkConnector name="${ApplianceID}"
userName="${networkConnectorUserName}"
password="${networkConnectorPassword}"
uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
duplex="true"
dynamicOnly="true">
<dynamicallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</dynamicallyIncludedDestinations>
<staticallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</staticallyIncludedDestinations>
</networkConnector>
</networkConnectors>
In reading through the book "ActiveMQ in Action" and reviewing the online docs at http://activemq.apache.org/networks-of-brokers.html, it seems that we should use the default setting for "dynamicOnly", "false" (the docs say "if true, only forward messages if a consumer is active on the connected broker").
However, when i set "dynamicOnly" to false, i see numerous startup errors and NullPointerExceptions in the Remote activemq.log, and connection errors in Central's logs. The Remote log simply reads:
[DemandForwardingBridge.serviceLocalException]: Network connection between vm://remotebroker.msg02.nweacolo.pvt#24 and ssl://msg01.se.nweacolo.pvt/192.168.1.94:51617 shutdown due to a local error: java.lang.NullPointerException
With "dynamicOnly" set to true, the log shows that existing durable subscriptions are reconnecting during startup.
Playing with the "prefetchSize" and "networkTTL" attributes for <networkConnector> on Remote (vaguely recommended in the docs) doesn't seem to have any effect.
This seems very similar to this issue from February 2009: http://old.nabble.com/Confusion-about-dynamicOnly-NetworkConnector-property-td22211600.html, which didn't seem to get resolved.
Any insight, recommendations, or help are most appreciated.
--
Joe Niski
IS Development | NWEA
NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
Re: durable subscription problems
Posted by Gary Tully <ga...@gmail.com>.
A single duplex connector on either end will work. It will create a
forwarding bridge in both directions.
Yes, selectors are JMS message selectors. The only think to note is
that with conduit subscriptions (where multiple consumers for a
destination are considered by the bridge to be a single consumer)
selectors are not honored by the bridge. All messages will be
forwarded to the other broker where the selector will have effect,
which can leave some unmatched messaged dangling on that broker. If
you don't want that, then you need to disable conduit subscriptions
and have each subscription with its relevant selector be mapped
independently by the forwarding bridge. If the selectors overlap there
will be duplicate messages.
On 24 August 2010 19:42, Joe Niski <jo...@nwea.org> wrote:
> Thanks, Gary, i appreciate the clarification. Still a couple of followup questions, with additional info:
>
> 1) B is analagous to the supermarket in section 10.2.1 of "ActiveMQ in Action", and A is the backoffice. B needs to send messages back to A, in addition to receiving messages from A via durable subscriptions. Like the supermarket/backoffice example, we may need to bring additional Bs online in the future, and would like to do so without changing A's configuration. That's why i asked about the duplex networkConnector on B. So, if i want messages to flow both directions between A and B, is a single duplex networkConnector on B sufficient, or do i also need a networkConnector on B?
>
> 2) By "selectors", do you include message selectors declared in MDB annotations (for example @ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "foo"))?
>
> 3) what do you mean by "coalesced" subscriptions? something like this? (this relates to question #4 form my first message in ths sub-thread)
>
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
>
> thanks again,
> Joe
>
>
> Joe Niski
> IS Development | NWEA
>
> PHONE 503.212.3382 | FAX 503.639.7873
>
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
> On 08/24/2010 03:11 AM, Gary Tully wrote:
>
> A single non-duplex networkConnector on A is all that is required as
> this will forward messages on demand (when it sees consumers on B
> provided advisory support is not disabled) from A to B.
>
> When B has a durable consumer, the proxy or forwarding consumer on A
> will also be durable, with a well known subscription id that allows it
> to outlive the durable consumer on B.
>
> On a restart of A, this durable consumer will be auto recreated but
> inactive, on a reconnect of a durable consumer to B, the corresponding
> durable on B should be activated and messages should again flow.
>
> To answer the questions:
> 1) that is over kill as there is no need for message flow from B to A.
> 2) yes. unless you want to use selectors, in which case subscriptions
> cannot be coalesced
> 3) no, provided advisory support is enabled (the default)
>
>
> On 24 August 2010 00:57, Joe Niski <jo...@nwea.org> wrote:
>> As i continue to work on this problem and dig further into the AMQ docs, additional clarifying questions have come up about network configuration in a store-and-forward scenario in which the broker A publishes to topics on broker A, and broker B subscribes to identically-named topics on broker B. i want to create durable subscriptions so the broker B will eventually receive messages published when it's offline.
>>
>> 1) Is a single duplex networkConnector on broker B sufficient? (section 10.2.1 of "ActiveMQ in Action" makes it seem like the answer is "yes".)
>>
>> 2) Is the "conduitSubscription" attribute required? (example 10.3 in "ActiveMQ in Action" makes it seem like the answer is "yes".)
>>
>> 3) In the networkConnection on broker B, do i need to define "durableDestinations" for the topics on broker A?
>>
>> 4) If the answer to (3) is "no", is it possible to point to the topics on broker A using the ">" wildcard in the "<dynamicallyIncludedDestinations>" or "<staticallyIncludedDestinations>" in broker B's networkConnector?
>>
>> thanks in advance,
>> Joe
>>
>> Joe Niski
>> IS Development | NWEA
>>
>> PHONE 503.212.3382 | FAX 503.639.7873
>>
>> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>>
>> On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
>>
>> Hi Joe,
>>
>> this sounds like a bug. Did you tested it with some newer version of
>> ActiveMQ (as there was a lot of work in that area since 5.0.3)
>>
>> Can you test newly released 5.4.0
>> http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
>> and see if the problem still exists?
>>
>> If it's still there, it would be great if you could raise a Jira
>> issue, ideally with a test case.
>>
>> Cheers
>> --
>> Dejan Bosanac - http://twitter.com/dejanb
>>
>> Open Source Integration - http://fusesource.com/
>> ActiveMQ in Action - http://www.manning.com/snyder/
>> Blog - http://www.nighttale.net
>>
>>
>>
>
>
>
> --
> http://blog.garytully.com
>
> Open Source Integration
> http://fusesource.com
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: durable subscription problems
Posted by Joe Niski <jo...@NWEA.org>.
Thanks, Gary, i appreciate the clarification. Still a couple of followup questions, with additional info:
1) B is analagous to the supermarket in section 10.2.1 of "ActiveMQ in Action", and A is the backoffice. B needs to send messages back to A, in addition to receiving messages from A via durable subscriptions. Like the supermarket/backoffice example, we may need to bring additional Bs online in the future, and would like to do so without changing A's configuration. That's why i asked about the duplex networkConnector on B. So, if i want messages to flow both directions between A and B, is a single duplex networkConnector on B sufficient, or do i also need a networkConnector on B?
2) By "selectors", do you include message selectors declared in MDB annotations (for example @ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "foo"))?
3) what do you mean by "coalesced" subscriptions? something like this? (this relates to question #4 form my first message in ths sub-thread)
<dynamicallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</dynamicallyIncludedDestinations>
<staticallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</staticallyIncludedDestinations>
thanks again,
Joe
Joe Niski
IS Development | NWEA
PHONE 503.212.3382 | FAX 503.639.7873
NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
On 08/24/2010 03:11 AM, Gary Tully wrote:
A single non-duplex networkConnector on A is all that is required as
this will forward messages on demand (when it sees consumers on B
provided advisory support is not disabled) from A to B.
When B has a durable consumer, the proxy or forwarding consumer on A
will also be durable, with a well known subscription id that allows it
to outlive the durable consumer on B.
On a restart of A, this durable consumer will be auto recreated but
inactive, on a reconnect of a durable consumer to B, the corresponding
durable on B should be activated and messages should again flow.
To answer the questions:
1) that is over kill as there is no need for message flow from B to A.
2) yes. unless you want to use selectors, in which case subscriptions
cannot be coalesced
3) no, provided advisory support is enabled (the default)
On 24 August 2010 00:57, Joe Niski <jo...@nwea.org> wrote:
> As i continue to work on this problem and dig further into the AMQ docs, additional clarifying questions have come up about network configuration in a store-and-forward scenario in which the broker A publishes to topics on broker A, and broker B subscribes to identically-named topics on broker B. i want to create durable subscriptions so the broker B will eventually receive messages published when it's offline.
>
> 1) Is a single duplex networkConnector on broker B sufficient? (section 10.2.1 of "ActiveMQ in Action" makes it seem like the answer is "yes".)
>
> 2) Is the "conduitSubscription" attribute required? (example 10.3 in "ActiveMQ in Action" makes it seem like the answer is "yes".)
>
> 3) In the networkConnection on broker B, do i need to define "durableDestinations" for the topics on broker A?
>
> 4) If the answer to (3) is "no", is it possible to point to the topics on broker A using the ">" wildcard in the "<dynamicallyIncludedDestinations>" or "<staticallyIncludedDestinations>" in broker B's networkConnector?
>
> thanks in advance,
> Joe
>
> Joe Niski
> IS Development | NWEA
>
> PHONE 503.212.3382 | FAX 503.639.7873
>
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
> On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
>
> Hi Joe,
>
> this sounds like a bug. Did you tested it with some newer version of
> ActiveMQ (as there was a lot of work in that area since 5.0.3)
>
> Can you test newly released 5.4.0
> http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
> and see if the problem still exists?
>
> If it's still there, it would be great if you could raise a Jira
> issue, ideally with a test case.
>
> Cheers
> --
> Dejan Bosanac - http://twitter.com/dejanb
>
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: durable subscription problems
Posted by Gary Tully <ga...@gmail.com>.
A single non-duplex networkConnector on A is all that is required as
this will forward messages on demand (when it sees consumers on B
provided advisory support is not disabled) from A to B.
When B has a durable consumer, the proxy or forwarding consumer on A
will also be durable, with a well known subscription id that allows it
to outlive the durable consumer on B.
On a restart of A, this durable consumer will be auto recreated but
inactive, on a reconnect of a durable consumer to B, the corresponding
durable on B should be activated and messages should again flow.
To answer the questions:
1) that is over kill as there is no need for message flow from B to A.
2) yes. unless you want to use selectors, in which case subscriptions
cannot be coalesced
3) no, provided advisory support is enabled (the default)
On 24 August 2010 00:57, Joe Niski <jo...@nwea.org> wrote:
> As i continue to work on this problem and dig further into the AMQ docs, additional clarifying questions have come up about network configuration in a store-and-forward scenario in which the broker A publishes to topics on broker A, and broker B subscribes to identically-named topics on broker B. i want to create durable subscriptions so the broker B will eventually receive messages published when it's offline.
>
> 1) Is a single duplex networkConnector on broker B sufficient? (section 10.2.1 of "ActiveMQ in Action" makes it seem like the answer is "yes".)
>
> 2) Is the "conduitSubscription" attribute required? (example 10.3 in "ActiveMQ in Action" makes it seem like the answer is "yes".)
>
> 3) In the networkConnection on broker B, do i need to define "durableDestinations" for the topics on broker A?
>
> 4) If the answer to (3) is "no", is it possible to point to the topics on broker A using the ">" wildcard in the "<dynamicallyIncludedDestinations>" or "<staticallyIncludedDestinations>" in broker B's networkConnector?
>
> thanks in advance,
> Joe
>
> Joe Niski
> IS Development | NWEA
>
> PHONE 503.212.3382 | FAX 503.639.7873
>
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
> On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
>
> Hi Joe,
>
> this sounds like a bug. Did you tested it with some newer version of
> ActiveMQ (as there was a lot of work in that area since 5.0.3)
>
> Can you test newly released 5.4.0
> http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
> and see if the problem still exists?
>
> If it's still there, it would be great if you could raise a Jira
> issue, ideally with a test case.
>
> Cheers
> --
> Dejan Bosanac - http://twitter.com/dejanb
>
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: durable subscription problems
Posted by Joe Niski <jo...@NWEA.org>.
As i continue to work on this problem and dig further into the AMQ docs, additional clarifying questions have come up about network configuration in a store-and-forward scenario in which the broker A publishes to topics on broker A, and broker B subscribes to identically-named topics on broker B. i want to create durable subscriptions so the broker B will eventually receive messages published when it's offline.
1) Is a single duplex networkConnector on broker B sufficient? (section 10.2.1 of "ActiveMQ in Action" makes it seem like the answer is "yes".)
2) Is the "conduitSubscription" attribute required? (example 10.3 in "ActiveMQ in Action" makes it seem like the answer is "yes".)
3) In the networkConnection on broker B, do i need to define "durableDestinations" for the topics on broker A?
4) If the answer to (3) is "no", is it possible to point to the topics on broker A using the ">" wildcard in the "<dynamicallyIncludedDestinations>" or "<staticallyIncludedDestinations>" in broker B's networkConnector?
thanks in advance,
Joe
Joe Niski
IS Development | NWEA
PHONE 503.212.3382 | FAX 503.639.7873
NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
Hi Joe,
this sounds like a bug. Did you tested it with some newer version of
ActiveMQ (as there was a lot of work in that area since 5.0.3)
Can you test newly released 5.4.0
http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
and see if the problem still exists?
If it's still there, it would be great if you could raise a Jira
issue, ideally with a test case.
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
Re: durable subscription problems
Posted by Gary Tully <ga...@gmail.com>.
Schema validation is the default with spring 3. Elements in the broker
sequence must follow alphabetical ordering 2 validate.
On Tuesday, August 17, 2010, Joe Niski <jo...@nwea.org> wrote:
> Greetings again, Dejan:
>
> I tried setting up another Remote broker using the 5.40 release, just dropping my existing configuration files into place.
>
> I'm getting this parsing error on startup:
> ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 86 in XML document from class path resource [activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'amq:destinationPolicy'. One of '{"http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:producerSystemUsage, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:proxyConnectors, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:regionBroker, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:services, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:shutdownHooks, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:sslContext, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:systemUsage, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:taskRunnerFactory, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:tempDataStore, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:transportConnectorURIs, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:transportConnectors, WC[##other:"http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>]}' is expected.
>
>
> The content of my activemq.xml is pasted below. Even though i'm forcing the schemaLocation to http://activemq.apache.org/schema/core/activemq-core-5.3.0.xsd, is AMQ trying to validate teh file against the 5.4.0 schema?
>
> <beans xmlns="http://www.springframework.org/schema/beans"<http://www.springframework.org/schema/beans>
> xmlns:amq="http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<http://www.w3.org/2001/XMLSchema-instance>
> xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> http://activemq.apache.org/schema/core
> http://activemq.apache.org/schema/core/activemq-core-5.3.0.xsd">
>
> <!--
> Allows us to use system properties as variables in this configuration
> file. For more information, see the Javadoc:
>
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html
> -->
> <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> <property name="locations">
> <list>
> <value>file:${activemq.base}/conf/messaging.conf</value>
> <value>file:${activemq.base}/conf/credentials.properties</value>
> </list>
> </property>
> </bean>
>
> <!--
> The <broker> element is used to configure the ActiveMQ broker. Tips: -
> Change the brokerName attribute to something unique
> -->
> <broker xmlns="http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>
> brokerName="${ApplianceID}" useJmx="true" advisorySupport="true" dataDirectory="${activemq.base}/data">
>
> <!-- Define Queue and Topic Names -->
> <destinations>
> <!-- for remote_messaging app -->
> <queue physicalName="org.nwea.queues.local.inbound.notifications_and_alerts"/>
> <queue physicalName="org.nwea.queues.local.internal.invalidmessages"/>
> <queue physicalName="org.nwea.queues.local.internal.updated_entities_to_mto"/>
> <queue physicalName="org.nwea.queues.local.internal.notifications_and_alerts"/>
> <queue physicalName="org.nwea.queues.local.internal.from_central.hold_for_upgrade"/>
> <queue physicalName="org.nwea.queues.local.outbound.data_updates"/>
> <!-- for Reports app -->
> <queue physicalName="inbound.rptreq.q"/>
> <queue physicalName="internal.largerptreq.q"/>
> <queue physicalName="internal.rptreq.q"/>
> <queue physicalName="inbound.tt2etl.q"/>
> <queue physicalName="internal.tt2etl.q"/>
> </destinations>
>
> <plugins>
> <jaasAuthenticationPlugin configuration="activemq-domain"/>
> <authorizationPlugin>
> <map>
> <authorizationMap>
> <authorizationEntries>
> <authorizationEntry topic=">"
> read="admins"
> write="admins"
> admin="admins"/>
> <authorizationEntry topic="ActiveMQ.Advisory.>"
> read="remotepeer"
> write="remotepeer"
> admin="remotepeer"/>
> <authorizationEntry topic="org.nwea.topics.>"
> write="remotepeer"
> admin="remotepeer"/>
> <authorizationEntry queue=">"
> read="admins"
> write="admins"
> admin="admins"/>
> <authorizationEntry queue="org.nwea.queues.central.>"
> read="remotepeer"
> admin="remotepeer"/>
> </authorizationEntries>
> </authorizationMap>
> </map>
> </authorizationPlugin>
> </plugins>
> <!--
> Examples of destination-specific policies using destination names or
> wildcards. For more information, see:
>
> http://activemq.apache.org/per-destination-policies.html
> http://activemq.apache.org/destination-features.html
> http://activemq.apache.org/slow-consumer-handling.html
> http://activemq.apache.org/subscription-recovery-policy.html
> -->
> <destinationPolicy>
> <policyMap>
> <policyEntries>
> <!-- originally set to 5mb -->
> <policyEntry queue=">" producerFlowControl="true"
> memoryLimit="${remote_baseQueueMemory}mb"/>
> <policyEntry topic=">" producerFlowControl="true"
> memoryLimit="${remote_baseTopicMemory}mb">
> <dispatchPolicy>
> <!--
> Use total ordering, see:
> http://activemq.apache.org/total-ordering.html
> -->
> <strictOrderDispatchPolicy/>
> </dispatchPolicy>
> <subscriptionRecoveryPolicy>
> <!--
> Upon subscription, receive the last image sent on the
> destination.
> -->
> <lastImageSubscriptionRecoveryPolicy/>
> </subscriptionRecoveryPolicy>
> </policyEntry>
>
> <!-- nwea dead letter policy -->
> <!--
> http://activemq.apache.org/schema/core/activemq-core-5.2.0.xsd.html
> -->
> <!-- originally set to 100mb -->
> <policyEntry queue="org.nwea.>" memoryLimit="${remote_deadLetterQueueMemory}mb">
> <deadLetterStrategy>
> <individualDeadLetterStrategy processExpired="true"
> processNonPersistent="true"
> queuePrefix="nwea_dlq_queue.">
> </individualDeadLetterStrategy>
> </deadLetterStrategy>
> </policyEntry>
>
> http://activemq.apache.org/networks-of-brokers.html
> -->
> <networkConnectors>
> <networkConnector name="${ApplianceID}"
> userName="${networkConnectorUserName}"
> password="${networkConnectorPassword}"
> uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
> duplex="true"
> dynamicOnly="true">
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> <!--
> Configure message persistence for the broker. The default
> persistence mechanism is the AMQ store (identified by the
> amqPersistenceAdapter). For more information, see:
>
> http://activemq.apache.org/persistence.html
> -->
> <persistenceAdapter>
> <kahaDB directory="${activemq.base}/data/${ApplianceID}/kahadb"
> indexWriteBatchSize="1000" enableIndexWriteAsync="true"
> enableJournalDiskSyncs="false"/>
> </persistenceAdapter>
>
> <!-- ssl configuration -->
> <sslContext>
> <sslContext keyStore="file:${activemq.base}/conf/broker.ks"<file:${activemq.base}/conf/broker.ks>
> keyStorePassword="password"
> trustStore="file:${activemq.base}/conf/broker.ts"<file:${activemq.base}/conf/broker.ts>
> trustStorePassword="password"/>
> </sslContext>
>
>
> <!--
> The systemUsage controls the maximum amount of space the broker will
> use before slowing down producers. For more information, see:
>
> http://activemq.apache.org/producer-flow-control.html
> -->
> <systemUsage>
> <systemUsage>
> <memoryUsage>
> <!-- originally set to 100 mb -->
> <memoryUsage limit="${remote_systemMemoryUsage} mb"/>
> </memoryUsage>
> <storeUsage>
> <!-- originally set to 1 gb -->
> <storeUsage limit="${remote_systemStoreUsage} gb"/>
> </storeUsage>
> <tempUsage>
> <!-- originally set to 200 mb -->
> <tempUsage limit="${remote_systemTempUsage} mb"/>
> </tempUsage>
>
>
>
> Joe Niski
> IS Development | NWEA
>
> PHONE 503.212.3382 | FAX 503.639.7873
>
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
> On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
>
> Hi Joe,
>
> this sounds like a bug. Did you tested it with some newer version of
> ActiveMQ (as there was a lot of work in that area since 5.0.3)
>
> Can you test newly released 5.4.0
> http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
> and see if the problem still exists?
>
> If it's still there, it would be great if you could raise a Jira
> issue, ideally with a test case.
>
> Cheers
> --
> Dejan Bosanac - http://twitter.com/dejanb
>
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
> On Tue, Aug 17, 2010 at 2:00 AM, Joe
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: durable subscription problems
Posted by Joe Niski <jo...@NWEA.org>.
Greetings again, Dejan:
I tried setting up another Remote broker using the 5.40 release, just dropping my existing configuration files into place.
I'm getting this parsing error on startup:
ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 86 in XML document from class path resource [activemq.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'amq:destinationPolicy'. One of '{"http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:producerSystemUsage, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:proxyConnectors, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:regionBroker, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:services, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:shutdownHooks, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:sslContext, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:systemUsage, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:taskRunnerFactory, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:tempDataStore, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:transportConnectorURIs, "http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>:transportConnectors, WC[##other:"http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>]}' is expected.
The content of my activemq.xml is pasted below. Even though i'm forcing the schemaLocation to http://activemq.apache.org/schema/core/activemq-core-5.3.0.xsd, is AMQ trying to validate teh file against the 5.4.0 schema?
<beans xmlns="http://www.springframework.org/schema/beans"<http://www.springframework.org/schema/beans>
xmlns:amq="http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<http://www.w3.org/2001/XMLSchema-instance>
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core-5.3.0.xsd">
<!--
Allows us to use system properties as variables in this configuration
file. For more information, see the Javadoc:
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html
-->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>file:${activemq.base}/conf/messaging.conf</value>
<value>file:${activemq.base}/conf/credentials.properties</value>
</list>
</property>
</bean>
<!--
The <broker> element is used to configure the ActiveMQ broker. Tips: -
Change the brokerName attribute to something unique
-->
<broker xmlns="http://activemq.apache.org/schema/core"<http://activemq.apache.org/schema/core>
brokerName="${ApplianceID}" useJmx="true" advisorySupport="true" dataDirectory="${activemq.base}/data">
<!-- Define Queue and Topic Names -->
<destinations>
<!-- for remote_messaging app -->
<queue physicalName="org.nwea.queues.local.inbound.notifications_and_alerts"/>
<queue physicalName="org.nwea.queues.local.internal.invalidmessages"/>
<queue physicalName="org.nwea.queues.local.internal.updated_entities_to_mto"/>
<queue physicalName="org.nwea.queues.local.internal.notifications_and_alerts"/>
<queue physicalName="org.nwea.queues.local.internal.from_central.hold_for_upgrade"/>
<queue physicalName="org.nwea.queues.local.outbound.data_updates"/>
<!-- for Reports app -->
<queue physicalName="inbound.rptreq.q"/>
<queue physicalName="internal.largerptreq.q"/>
<queue physicalName="internal.rptreq.q"/>
<queue physicalName="inbound.tt2etl.q"/>
<queue physicalName="internal.tt2etl.q"/>
</destinations>
<plugins>
<jaasAuthenticationPlugin configuration="activemq-domain"/>
<authorizationPlugin>
<map>
<authorizationMap>
<authorizationEntries>
<authorizationEntry topic=">"
read="admins"
write="admins"
admin="admins"/>
<authorizationEntry topic="ActiveMQ.Advisory.>"
read="remotepeer"
write="remotepeer"
admin="remotepeer"/>
<authorizationEntry topic="org.nwea.topics.>"
write="remotepeer"
admin="remotepeer"/>
<authorizationEntry queue=">"
read="admins"
write="admins"
admin="admins"/>
<authorizationEntry queue="org.nwea.queues.central.>"
read="remotepeer"
admin="remotepeer"/>
</authorizationEntries>
</authorizationMap>
</map>
</authorizationPlugin>
</plugins>
<!--
Examples of destination-specific policies using destination names or
wildcards. For more information, see:
http://activemq.apache.org/per-destination-policies.html
http://activemq.apache.org/destination-features.html
http://activemq.apache.org/slow-consumer-handling.html
http://activemq.apache.org/subscription-recovery-policy.html
-->
<destinationPolicy>
<policyMap>
<policyEntries>
<!-- originally set to 5mb -->
<policyEntry queue=">" producerFlowControl="true"
memoryLimit="${remote_baseQueueMemory}mb"/>
<policyEntry topic=">" producerFlowControl="true"
memoryLimit="${remote_baseTopicMemory}mb">
<dispatchPolicy>
<!--
Use total ordering, see:
http://activemq.apache.org/total-ordering.html
-->
<strictOrderDispatchPolicy/>
</dispatchPolicy>
<subscriptionRecoveryPolicy>
<!--
Upon subscription, receive the last image sent on the
destination.
-->
<lastImageSubscriptionRecoveryPolicy/>
</subscriptionRecoveryPolicy>
</policyEntry>
<!-- nwea dead letter policy -->
<!--
http://activemq.apache.org/schema/core/activemq-core-5.2.0.xsd.html
-->
<!-- originally set to 100mb -->
<policyEntry queue="org.nwea.>" memoryLimit="${remote_deadLetterQueueMemory}mb">
<deadLetterStrategy>
<individualDeadLetterStrategy processExpired="true"
processNonPersistent="true"
queuePrefix="nwea_dlq_queue.">
</individualDeadLetterStrategy>
</deadLetterStrategy>
</policyEntry>
<!-- originally set to 100mb -->
<policyEntry topic="org.nwea.>" memoryLimit="${remote_deadLetterTopicMemory}mb">
<deadLetterStrategy>
<individualDeadLetterStrategy processExpired="true"
processNonPersistent="true"
topicPrefix="nwea_dlq_topic.">
</individualDeadLetterStrategy>
</deadLetterStrategy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
<!--
The managementContext is used to configure how ActiveMQ is exposed in
JMX. By default, ActiveMQ uses the MBean server that is started by
the JVM. For more information, see:
http://activemq.apache.org/jmx.html
-->
<managementContext>
<!-- originally set to true, port 1199 -->
<managementContext createConnector="${remote_enableJmx}" connectorPort="${remote_jmxConnectorPort}"/>
</managementContext>
<!--
The network connectors are used to create a network of brokers. For
more information, see:
http://activemq.apache.org/networks-of-brokers.html
-->
<networkConnectors>
<networkConnector name="${ApplianceID}"
userName="${networkConnectorUserName}"
password="${networkConnectorPassword}"
uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
duplex="true"
dynamicOnly="true">
<dynamicallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</dynamicallyIncludedDestinations>
<staticallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</staticallyIncludedDestinations>
</networkConnector>
</networkConnectors>
<!--
Configure message persistence for the broker. The default
persistence mechanism is the AMQ store (identified by the
amqPersistenceAdapter). For more information, see:
http://activemq.apache.org/persistence.html
-->
<persistenceAdapter>
<kahaDB directory="${activemq.base}/data/${ApplianceID}/kahadb"
indexWriteBatchSize="1000" enableIndexWriteAsync="true"
enableJournalDiskSyncs="false"/>
</persistenceAdapter>
<!-- ssl configuration -->
<sslContext>
<sslContext keyStore="file:${activemq.base}/conf/broker.ks"<file:${activemq.base}/conf/broker.ks>
keyStorePassword="password"
trustStore="file:${activemq.base}/conf/broker.ts"<file:${activemq.base}/conf/broker.ts>
trustStorePassword="password"/>
</sslContext>
<!--
The systemUsage controls the maximum amount of space the broker will
use before slowing down producers. For more information, see:
http://activemq.apache.org/producer-flow-control.html
-->
<systemUsage>
<systemUsage>
<memoryUsage>
<!-- originally set to 100 mb -->
<memoryUsage limit="${remote_systemMemoryUsage} mb"/>
</memoryUsage>
<storeUsage>
<!-- originally set to 1 gb -->
<storeUsage limit="${remote_systemStoreUsage} gb"/>
</storeUsage>
<tempUsage>
<!-- originally set to 200 mb -->
<tempUsage limit="${remote_systemTempUsage} mb"/>
</tempUsage>
</systemUsage>
</systemUsage>
<!--
The transport connectors expose ActiveMQ over a given protocol to
clients and other brokers. For more information, see:
http://activemq.apache.org/configuring-transports.html
-->
<transportConnectors>
<!-- by convention we use 51616 and 51617 (for ssl) so as not to conflict with Geronimo's embedded ActiveMQ defaults (61616 & 61617) -->
<transportConnector name="openwire" uri="tcp://0.0.0.0:${remote_openwirePortNumber}"/>
<transportConnector name="ssl" uri="ssl://0.0.0.0:${remote_sslPortNumber}"/>
</transportConnectors>
</broker>
<jetty xmlns="http://mortbay.com/schemas/jetty/1.0"<http://mortbay.com/schemas/jetty/1.0>>
<connectors>
<nioConnector port="8161"/>
</connectors>
<handlers>
<webAppContext contextPath="/admin" resourceBase="${activemq.base}/webapps/admin" logUrlOnStart="true"/>
</handlers>
</jetty>
<!-- CAMEL ROUTING CONFIGURATIONS -->
<import resource="camel_remote_messaging.xml"/>
<import resource="camel_reports.xml"/>
</beans>
Joe Niski
IS Development | NWEA
PHONE 503.212.3382 | FAX 503.639.7873
NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
Hi Joe,
this sounds like a bug. Did you tested it with some newer version of
ActiveMQ (as there was a lot of work in that area since 5.0.3)
Can you test newly released 5.4.0
http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
and see if the problem still exists?
If it's still there, it would be great if you could raise a Jira
issue, ideally with a test case.
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Aug 17, 2010 at 2:00 AM, Joe Niski <jo...@nwea.org> wrote:
> i have a network of 2 brokers, let's call them "Remote" and "Central", running on ActiveMQ 5.0.3, in a store-and-forward configuration. i inherited this setup, i did not design it, but it seems like a generally solid configuration.
>
> On the Remote broker, there are topics (e.g. "org.nwea.topics.license") that have durable subscriptions to topics of the same name on the Central broker. Messages that are published to topics on the Central broker find their way to Remote really fast - as long as the Remote is online when the message is published. Messages that are published when Remote is offline are never picked up by the remote.
>
> i have a j2ee application that contains MDBs that are annotated to have durable subscriptions to the topics on the Remote broker.
>
> The NetworkConnector configuration in the Remote broker's activemq.xml looks like this:
>
> <networkConnectors>
> <networkConnector name="${ApplianceID}"
> userName="${networkConnectorUserName}"
> password="${networkConnectorPassword}"
> uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
> duplex="true"
> dynamicOnly="true">
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> In reading through the book "ActiveMQ in Action" and reviewing the online docs at http://activemq.apache.org/networks-of-brokers.html, it seems that we should use the default setting for "dynamicOnly", "false" (the docs say "if true, only forward messages if a consumer is active on the connected broker").
>
> However, when i set "dynamicOnly" to false, i see numerous startup errors and NullPointerExceptions in the Remote activemq.log, and connection errors in Central's logs. The Remote log simply reads:
> [DemandForwardingBridge.serviceLocalException]: Network connection between vm://remotebroker.msg02.nweacolo.pvt#24 and ssl://msg01.se.nweacolo.pvt/192.168.1.94:51617 shutdown due to a local error: java.lang.NullPointerException
>
> With "dynamicOnly" set to true, the log shows that existing durable subscriptions are reconnecting during startup.
>
> Playing with the "prefetchSize" and "networkTTL" attributes for <networkConnector> on Remote (vaguely recommended in the docs) doesn't seem to have any effect.
>
> This seems very similar to this issue from February 2009: http://old.nabble.com/Confusion-about-dynamicOnly-NetworkConnector-property-td22211600.html, which didn't seem to get resolved.
>
> Any insight, recommendations, or help are most appreciated.
> --
>
> Joe Niski
> IS Development | NWEA
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
Re: durable subscription problems
Posted by Joe Niski <jo...@NWEA.org>.
Will do, thanks for the reply.
Two additional bits of information:
- I should have said that I'm using AMQ 5.3.0, not 5.0.3
- here's the NPE stacktrace i'm seeing in my Remote broker activemq.log:
Aug-17 16:43:08,973 DEBUG [DemandForwardingBridge.serviceLocalException]: The local Exception was:java.lang.NullPointerException
java.lang.NullPointerException
at org.apache.activemq.network.DurableConduitBridge.setupStaticDestinations(DurableConduitBridge.java:64)
at org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:297)
at org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:248)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Joe Niski
IS Development | NWEA
PHONE 503.212.3382 | FAX 503.639.7873
NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
On 08/17/2010 03:26 AM, Dejan Bosanac wrote:
Hi Joe,
this sounds like a bug. Did you tested it with some newer version of
ActiveMQ (as there was a lot of work in that area since 5.0.3)
Can you test newly released 5.4.0
http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
and see if the problem still exists?
If it's still there, it would be great if you could raise a Jira
issue, ideally with a test case.
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Aug 17, 2010 at 2:00 AM, Joe Niski <jo...@nwea.org> wrote:
> i have a network of 2 brokers, let's call them "Remote" and "Central", running on ActiveMQ 5.0.3, in a store-and-forward configuration. i inherited this setup, i did not design it, but it seems like a generally solid configuration.
>
> On the Remote broker, there are topics (e.g. "org.nwea.topics.license") that have durable subscriptions to topics of the same name on the Central broker. Messages that are published to topics on the Central broker find their way to Remote really fast - as long as the Remote is online when the message is published. Messages that are published when Remote is offline are never picked up by the remote.
>
> i have a j2ee application that contains MDBs that are annotated to have durable subscriptions to the topics on the Remote broker.
>
> The NetworkConnector configuration in the Remote broker's activemq.xml looks like this:
>
> <networkConnectors>
> <networkConnector name="${ApplianceID}"
> userName="${networkConnectorUserName}"
> password="${networkConnectorPassword}"
> uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
> duplex="true"
> dynamicOnly="true">
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> In reading through the book "ActiveMQ in Action" and reviewing the online docs at http://activemq.apache.org/networks-of-brokers.html, it seems that we should use the default setting for "dynamicOnly", "false" (the docs say "if true, only forward messages if a consumer is active on the connected broker").
>
> However, when i set "dynamicOnly" to false, i see numerous startup errors and NullPointerExceptions in the Remote activemq.log, and connection errors in Central's logs. The Remote log simply reads:
> [DemandForwardingBridge.serviceLocalException]: Network connection between vm://remotebroker.msg02.nweacolo.pvt#24 and ssl://msg01.se.nweacolo.pvt/192.168.1.94:51617 shutdown due to a local error: java.lang.NullPointerException
>
> With "dynamicOnly" set to true, the log shows that existing durable subscriptions are reconnecting during startup.
>
> Playing with the "prefetchSize" and "networkTTL" attributes for <networkConnector> on Remote (vaguely recommended in the docs) doesn't seem to have any effect.
>
> This seems very similar to this issue from February 2009: http://old.nabble.com/Confusion-about-dynamicOnly-NetworkConnector-property-td22211600.html, which didn't seem to get resolved.
>
> Any insight, recommendations, or help are most appreciated.
> --
>
> Joe Niski
> IS Development | NWEA
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
Re: durable subscription problems
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi Joe,
this sounds like a bug. Did you tested it with some newer version of
ActiveMQ (as there was a lot of work in that area since 5.0.3)
Can you test newly released 5.4.0
http://repo1.maven.org/maven2/org/apache/activemq/apache-activemq/5.4.0/
and see if the problem still exists?
If it's still there, it would be great if you could raise a Jira
issue, ideally with a test case.
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Aug 17, 2010 at 2:00 AM, Joe Niski <jo...@nwea.org> wrote:
> i have a network of 2 brokers, let's call them "Remote" and "Central", running on ActiveMQ 5.0.3, in a store-and-forward configuration. i inherited this setup, i did not design it, but it seems like a generally solid configuration.
>
> On the Remote broker, there are topics (e.g. "org.nwea.topics.license") that have durable subscriptions to topics of the same name on the Central broker. Messages that are published to topics on the Central broker find their way to Remote really fast - as long as the Remote is online when the message is published. Messages that are published when Remote is offline are never picked up by the remote.
>
> i have a j2ee application that contains MDBs that are annotated to have durable subscriptions to the topics on the Remote broker.
>
> The NetworkConnector configuration in the Remote broker's activemq.xml looks like this:
>
> <networkConnectors>
> <networkConnector name="${ApplianceID}"
> userName="${networkConnectorUserName}"
> password="${networkConnectorPassword}"
> uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
> duplex="true"
> dynamicOnly="true">
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> In reading through the book "ActiveMQ in Action" and reviewing the online docs at http://activemq.apache.org/networks-of-brokers.html, it seems that we should use the default setting for "dynamicOnly", "false" (the docs say "if true, only forward messages if a consumer is active on the connected broker").
>
> However, when i set "dynamicOnly" to false, i see numerous startup errors and NullPointerExceptions in the Remote activemq.log, and connection errors in Central's logs. The Remote log simply reads:
> [DemandForwardingBridge.serviceLocalException]: Network connection between vm://remotebroker.msg02.nweacolo.pvt#24 and ssl://msg01.se.nweacolo.pvt/192.168.1.94:51617 shutdown due to a local error: java.lang.NullPointerException
>
> With "dynamicOnly" set to true, the log shows that existing durable subscriptions are reconnecting during startup.
>
> Playing with the "prefetchSize" and "networkTTL" attributes for <networkConnector> on Remote (vaguely recommended in the docs) doesn't seem to have any effect.
>
> This seems very similar to this issue from February 2009: http://old.nabble.com/Confusion-about-dynamicOnly-NetworkConnector-property-td22211600.html, which didn't seem to get resolved.
>
> Any insight, recommendations, or help are most appreciated.
> --
>
> Joe Niski
> IS Development | NWEA
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids Learn
>
Re: durable subscription problems
Posted by Joe Niski <jo...@NWEA.org>.
Systematic trial-and-error in configuring the networkConnector lead us
to a solution on this.
either of the following configurations work flawlessly:
<networkConnectors>
<networkConnector name="${ApplianceID}"
userName="${networkConnectorUserName}"
password="${networkConnectorPassword}"
uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
duplex="true"
dynamicOnly="true">
<dynamicallyIncludedDestinations>
<queue physicalName="org.nwea.queues.central.>"/>
<topic physicalName="org.nwea.topics.>"/>
</dynamicallyIncludedDestinations>
</networkConnector>
</networkConnectors>
<networkConnectors>
<networkConnector name="${ApplianceID}"
userName="${networkConnectorUserName}"
password="${networkConnectorPassword}"
uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
duplex="true"
dynamicOnly="true">
</networkConnector>
</networkConnectors>
The <staticallyIncludedDestinations> element in the configuration we
inherited prevented durable subscriptions from getting established
altogether.
Setting dynamicOnly=false lead in any scenario lead to messages sent
from topics on Central to topics on Remote looping back to Central's
topics (doubling the number of enqueued messages).
The combination of dynamicOnly=false and eliminating
<staticallyIncludedDestinations> had the additional effect of creating
additional durable subscriptions on from Central's topics to Remote's.
This was a good learning exercise, but the whole process left me
scratching my head more than ever at the sparse documentation on durable
subs, and the misleadingly ambiguous explanation of the dynamicOnly
attribute - but, it looks like we have a fix, so i'm (cautiously, until
we're in production) happy.
*Joe Niski
*IS Development | NWEA
PHONE 503.212.3382 | FAX 503.639.7873
NWEA.ORG <3D%22http://www.nwea.org/%22> ** | Partnering to Help All Kids
Learn
On 08/16/2010 05:00 PM, Joe Niski wrote:
>
> i have a network of 2 brokers, let's call them "Remote" and "Central",
> running on ActiveMQ 5.0.3, in a store-and-forward configuration. i
> inherited this setup, i did not design it, but it seems like a
> generally solid configuration.
>
> On the Remote broker, there are topics (e.g.
> "org.nwea.topics.license") that have durable subscriptions to topics
> of the same name on the Central broker. Messages that are published to
> topics on the Central broker find their way to Remote really fast - as
> long as the Remote is online when the message is published. Messages
> that are published when Remote is offline are never picked up by the
> remote.
>
> i have a j2ee application that contains MDBs that are annotated to
> have durable subscriptions to the topics on the Remote broker.
>
> The NetworkConnector configuration in the Remote broker's activemq.xml
> looks like this:
>
> <networkConnectors>
> <networkConnector name="${ApplianceID}"
> userName="${networkConnectorUserName}"
> password="${networkConnectorPassword}"
>
> uri="static://(ssl://${Central.ServerHostname}:${central_sslPortNumber})"
> duplex="true"
> dynamicOnly="true">
> <dynamicallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </dynamicallyIncludedDestinations>
> <staticallyIncludedDestinations>
> <queue physicalName="org.nwea.queues.central.>"/>
> <topic physicalName="org.nwea.topics.>"/>
> </staticallyIncludedDestinations>
> </networkConnector>
> </networkConnectors>
>
> In reading through the book "ActiveMQ in Action" and reviewing the
> online docs at http://activemq.apache.org/networks-of-brokers.html, it
> seems that we should use the default setting for "dynamicOnly",
> "false" (the docs say "if true, only forward messages if a consumer is
> active on the connected broker").
>
> However, when i set "dynamicOnly" to false, i see numerous startup
> errors and NullPointerExceptions in the Remote activemq.log, and
> connection errors in Central's logs. The Remote log simply reads:
> [DemandForwardingBridge.serviceLocalException]: Network connection
> between vm://remotebroker.msg02.nweacolo.pvt#24 and
> ssl://msg01.se.nweacolo.pvt/192.168.1.94:51617 shutdown due to a local
> error: java.lang.NullPointerException
>
> With "dynamicOnly" set to true, the log shows that existing durable
> subscriptions are reconnecting during startup.
>
> Playing with the "prefetchSize" and "networkTTL" attributes for
> <networkConnector> on Remote (vaguely recommended in the docs) doesn't
> seem to have any effect.
>
> This seems very similar to this issue from February 2009:
> http://old.nabble.com/Confusion-about-dynamicOnly-NetworkConnector-property-td22211600.html,
> which didn't seem to get resolved.
>
> Any insight, recommendations, or help are most appreciated.
> --
>
> Joe Niski
> IS Development | NWEA
> NWEA.ORG<3D%22http://www.nwea.org/%22> | Partnering to Help All Kids
> Learn
>