Hi,
We have a simple single-server ActiveMQ-setup with multiple consumers,
some of which use Java and connect via JMS. As the ActiveMQ-server might
some times need a restart or some other down time we configured it to
use the failover protocol (failover:tcp://localhost:61616), so it will
reconnect as soon as its available again and will also keep the
connection alive when there are long periods of silence.
All this is managed via Spring's normal connection handling.
This works fine, unless the ActiveMQ-server is not available during the
initial start. Rather than just going into the background and waiting
for the availability of a connection it blocks the start-up without any
error message.
In my case its a spring-managed Servlet that will receive some
cache-update messages via jsm-topics. But rather than connecting in the
background to activemq, the entire Tomcat-instance is blocked and
although it will accept new http-connections, it will do absolutely
nothing with them.
My spring-configuration is like this:
<bean id="amqfactory" class="o.a.activemq.ActiveMQConnectionFactory">
<constructor-arg value="" /> <!-- username -->
<constructor-arg value="" /> <!-- password -->
<constructor-arg value="failover:tcp://localhost:61616" /> <!-- broker -->
</bean>
<jms:listener-container connection-factory="amqfactory"
destination-type="topic">
<jms:listener destination="some_topic" ref="someMessageListener" />
</jms:listener-container>
I'm not really sure what the best solution would be, but I'd expect to
get some ERROR-message at the very least. It is the reason my
application won't start indefinitely (or until activemq is started,
whichever comes first). Its something you easily overlook during
debugging and it is very hard to detect when you don't know what you're
looking for (or even if you do, but just forget to check activemq is
running and/or a connection is made).
Logging should be possible, as I do get these kind of messages if it
does work:
2010-07-02 09:36:00,095 [ActiveMQ Task] INFO
o.a.activemq.transport.failover.FailoverTransport - Successfully
connected to tcp://localhost:61616
Perhaps the easiest fix would be to display a ERROR-message the first
time it can't connect and than fall back to DEBUG-messages.
Best regards,
Arjen
