Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Missing destination queue after broker restarted
Date: Fri, 3 Nov 2006 12:30:24 -0800
Message-ID: <68B9548ED9F8A341B21CDB320655D613026FE3D8@mercury.nmwco.com>
In-Reply-To: <005f01c6fe2e$fdd037f0$6df1a8c0@vlavilla>
Thread-Topic: Missing destination queue after broker restarted
Thread-Index: Acb+LxBcZ51IG9SjTNCR/cmD2CRgHgBT2FAg
From: "Chris Hofstaedter" <chrish@nmwco.com>
To: <activemq-users@geronimo.apache.org>

The following applies to 4.0.1, 4.0.2, and head.

My topology is pretty simple in that I'm trying to set up a queue in
which the producers all use embedded brokers and the consumer does not.


I've done my test both collocated on the same machine and across the
net.  My test only includes a single producer at this point.
"Log4Mobility" is the queue name.

Upon initial startup, everything works well.  Specifically, on initial
startup, the debug log on the broker indicates (I've replaced what I
believe to be non pertinent info with "..." for readability):

INFO  TransportConnector - Connector default Started
INFO  BrokerService - ActiveMQ JMS Message Broker (...) started
DEBUG TcpTransport - TCP consumer thread starting
DEBUG WireFormatNegotiator - Sending: WireFormatInfo ...
DEBUG WireFormatNegotiator - Received WireFormat: ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1142 ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1142 ...
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Connection
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Topic
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Consumer.Queue.Log4Mobility
DEBUG WireFormatNegotiator - Sending: WireFormatInfo ...
DEBUG TcpTransport - TCP consumer thread starting
DEBUG WireFormatNegotiator - Received WireFormat: ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1144 ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1144 ...
DEBUG AbstractRegion - Adding destination: queue://Log4Mobility

Then, while leaving the consumer and producer running, I shut down the
broker.  Upon subsequent startup of the broker, the debug log on the
broker indicates:

INFO  TransportConnector - Connector default Started
INFO  BrokerService - ActiveMQ JMS Message Broker (...) started
DEBUG TcpTransport - TCP consumer thread starting
DEBUG WireFormatNegotiator - Sending: WireFormatInfo ...
DEBUG WireFormatNegotiator - Received WireFormat: ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1165 ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1165 ...
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Connection
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Topic
DEBUG AbstractRegion - Adding destination:
topic://ActiveMQ.Advisory.Consumer.Queue.Log4Mobility
DEBUG WireFormatNegotiator - Sending: WireFormatInfo ...
DEBUG TcpTransport - TCP consumer thread starting
DEBUG WireFormatNegotiator - Received WireFormat: ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1166 ...
DEBUG WireFormatNegotiator - tcp:///10.47.20.123:1166 ...

It's virtually the same except that the message about actually adding
the queue is notably missing.  I've also confirmed through bstat that
the queue is present before the restart but not present after the
restart.

At this point, no messages flow.  Oddly, the producer thinks it's
forwarding the messages over the bridge as indicated by its debug log
from the point at which it reestablishes its connection:

DEBUG FailoverTransport - Connection established
INFO  DemandForwardingBridge - Outbound transport to Log4Mobility
resumed
INFO  DemandForwardingBridge - Network connection between
vm://localhost#0 and tcp://10.47.20.123:61616(Log4Mobility) has been
established.
DEBUG DemandForwardingBridge - Ignoring sub ConsumerInfo {commandId =3D =
4,
responseRequired =3D true, consumerId =3D
ID:Hofstaedter-1141-1162581700794-1:6:1:1, destination =3D
queue://Log4Mobility, prefetchSize =3D 1, maximumPendingMessageLimit =3D =
0,
browser =3D false, dispatchAsync =3D false, selector =3D null, =
subcriptionName
=3D null, noLocal =3D false, exclusive =3D false, retroactive =3D false,
priority =3D 0, brokerPath =3D [ID:Hofstaedter-1158-1162581728012-1:0],
optimizedAcknowledge =3D false, noRangeAcks =3D false, =
additionalPredicate =3D
null} already subscribed to matching destination
DEBUG PrefetchSubscription - Prefetch limit.
DEBUG DemandForwardingBridge - Forwarding messages for static
destination: queue://Log4Mobility

The fourth log message in the set immediately above is interesting and
I'm unsure if it is related to the problem.  I think it may related to
that message b/c everything picks back up again if I restart the
producer. =20

I've seen messages from others on this list about failures on reconnect
- but they are always accompanied by specific exceptions and stack
traces and I see none of those - so I don't think it's the same thing.
In fact, I'm fairly new to AMQ, so it could be as simple as my config or
client code.  The config I'm using is:

<beans xmlns=3D"http://www.springframework.org/schema/beans"
       xmlns:util=3D"http://www.springframework.org/schema/util">
      =20
  <bean
class=3D"org.springframework.beans.factory.config.PropertyPlaceholderConf=
i
gurer"/>
  =20
   <broker brokerName=3D"Log4Mobility"=20
           persistent=3D"true"=20
           useShutdownHook=3D"false"=20
           useJmx=3D"true"
           xmlns=3D"http://activemq.org/config/1.0">

      <managementContext>
         <managementContext connectorPort=3D"1099"
jmxDomainName=3D"org.apache.activemq"/>
      </managementContext>

      <persistenceAdapter>
         <journaledJDBC journalLogFiles=3D"5"
dataDirectory=3D"${activemq.home}/activemq-data"/>
      </persistenceAdapter>

      <transportConnectors>
         <transportConnector name=3D"default"
uri=3D""tcp://10.47.20.123:61616"/>
      </transportConnectors>

   </broker>

</beans>

And finally, in case I'm performing some stupid code tricks, following
is my producer and consumer code to establish my connections:

Producer:
   m_broker =3D new BrokerService();
   m_broker.addConnector("vm://localhost");
   m_broker.setUseLoggingForShutdownErrors(false);
   m_broker.setUseShutdownHook(true);
   m_broker.setUseJmx(false);
   m_broker.setPersistent(m_persistent);
   DiscoveryNetworkConnector nc =3D new DiscoveryNetworkConnector();
   nc.setUri(new URI("static:" + m_url));
   nc.setFailover(true);
   nc.addStaticallyIncludedDestination(new ActiveMQQueue(m_queueName));
   nc.setUserName(m_userName);
   nc.setPassword(m_password);
   m_broker.addNetworkConnector(nc);
   m_broker.start();
   ActiveMQConnectionFactory factory =3D new
ActiveMQConnectionFactory(m_user, m_password, "vm://localhost");
   m_connection =3D factory.createConnection();
   m_connection.start();
   m_session =3D m_connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
   m_destination =3D m_session.createQueue(m_queueName);
   m_producer =3D m_session.createProducer(m_destination);
   if (m_persistent)
      m_producer.setDeliveryMode(DeliveryMode.PERSISTENT);
   else
      m_producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

Consumer:
   ActiveMQConnectionFactory factory =3D new =
ActiveMQConnectionFactory();
   factory.setBrokerURL(m_url);
   factory.setUserName(m_userName);
   factory.setPassword(m_password);
   m_connection =3D factory.createConnection();
   m_session =3D m_connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
   m_destination =3D m_session.createQueue(m_queueName +
"?consumer.prefetchSize=3D1");
   m_consumer =3D m_session.createConsumer(m_destination);
   m_connection.setExceptionListener(this);
   m_connection.start();
   m_consumer.setMessageListener(this);

Thanks in advance for any help or insight anyone can provide.