activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Niski <>
Subject Re: durable subscription problems
Date Tue, 17 Aug 2010 22:12:25 GMT
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 '{""<>:producerSystemUsage,
is expected.

The content of my activemq.xml is pasted below. Even though i'm forcing the schemaLocation
to, is AMQ trying to validate
teh file against the 5.4.0 schema?

<beans xmlns=""<>

        Allows us to use system properties as variables in this configuration
        file. For more information, see the Javadoc:
    <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">

        The <broker> element is used to configure the ActiveMQ broker. Tips: -
        Change the brokerName attribute to something unique
    <broker xmlns=""<>
            brokerName="${ApplianceID}" useJmx="true" advisorySupport="true"  dataDirectory="${activemq.base}/data">

        <!--  Define Queue and Topic Names -->
            <!-- 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"/>

            <jaasAuthenticationPlugin configuration="activemq-domain"/>
                            <authorizationEntry topic=">"
                            <authorizationEntry topic="ActiveMQ.Advisory.>"
                            <authorizationEntry topic="org.nwea.topics.>"
                            <authorizationEntry queue=">"
                            <authorizationEntry queue="org.nwea.queues.central.>"
            Examples of destination-specific policies using destination names or
            wildcards. For more information, see:

                    <!-- originally set to 5mb -->
                    <policyEntry queue=">" producerFlowControl="true"
                    <policyEntry topic=">" producerFlowControl="true"
                                Use total ordering, see:
                                Upon subscription, receive the last image sent on the

                    <!-- nwea dead letter policy -->
                    <!-- originally set to 100mb -->
                    <policyEntry queue="org.nwea.>" memoryLimit="${remote_deadLetterQueueMemory}mb">
                            <individualDeadLetterStrategy processExpired="true"
                    <!-- originally set to 100mb -->
                    <policyEntry topic="org.nwea.>" memoryLimit="${remote_deadLetterTopicMemory}mb">
                            <individualDeadLetterStrategy processExpired="true"


            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:

            <!-- originally set to true, port 1199 -->
            <managementContext createConnector="${remote_enableJmx}" connectorPort="${remote_jmxConnectorPort}"/>

            The network connectors are used to create a network of brokers. For
            more information, see:

            <networkConnector name="${ApplianceID}"
                    <queue physicalName="org.nwea.queues.central.>"/>
                    <topic physicalName="org.nwea.topics.>"/>
                    <queue physicalName="org.nwea.queues.central.>"/>
                    <topic physicalName="org.nwea.topics.>"/>

            Configure message persistence for the broker. The default
            persistence mechanism is the AMQ store (identified by the
            amqPersistenceAdapter).  For more information, see:

            <kahaDB directory="${activemq.base}/data/${ApplianceID}/kahadb"
                    indexWriteBatchSize="1000" enableIndexWriteAsync="true"

        <!-- ssl configuration -->
            <sslContext keyStore="file:${activemq.base}/conf/broker.ks"<file:${activemq.base}/conf/broker.ks>

            The systemUsage controls the maximum amount of space the broker will
            use before slowing down producers. For more information, see:

                    <!-- originally set to 100 mb -->
                    <memoryUsage limit="${remote_systemMemoryUsage} mb"/>
                    <!-- originally set to 1 gb -->
                    <storeUsage limit="${remote_systemStoreUsage} gb"/>
                    <!-- originally set to 200 mb -->
                    <tempUsage limit="${remote_systemTempUsage} mb"/>

            The transport connectors expose ActiveMQ over a given protocol to
            clients and other brokers. For more information, see:

            <!-- 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://${remote_openwirePortNumber}"/>
            <transportConnector name="ssl" uri="ssl://${remote_sslPortNumber}"/>


    <jetty xmlns=""<>>
            <nioConnector port="8161"/>

            <webAppContext contextPath="/admin" resourceBase="${activemq.base}/webapps/admin"

    <import resource="camel_remote_messaging.xml"/>
    <import resource="camel_reports.xml"/>


Joe Niski
IS Development |  NWEA

PHONE 503.212.3382  |  FAX 503.639.7873

NWEA.ORG<3D%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
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.

Dejan Bosanac -

Open Source Integration -
ActiveMQ in Action -
Blog -

On Tue, Aug 17, 2010 at 2:00 AM, Joe Niski <><>
> 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,
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
> [DemandForwardingBridge.serviceLocalException]:  Network connection between vm://remotebroker.msg02.nweacolo.pvt#24
and ssl:// 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:,
which didn't seem to get resolved.
> Any insight, recommendations, or help are most appreciated.
> --
> Joe Niski
> IS Development |  NWEA
> NWEA.ORG<3D%22>  |  Partnering to Help All Kids Learn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message