Hi Felix,
I did try 'reliable:tcp://...' but that didn't work, the url wasn't
accepted. I didn't think to use failover on a single connection.
But I did resolve the issue for now by altering the spring-configuration
to only cache connections rather than also cache the entire consumer.
Spring's container already should reconnect if the connection doesn't
work, but somehow it didn't get that knowledge in the default
configuration from the connection. There was an exception thrown inside
the Transport, but somewhere along the line it got caught.
With the adjusted caching approach it apparently now does get that
knowledge, probably because it does more checks. And now I do get new
connections when ActiveMQ goes away, so probably also for any other
reason the library might loose its connection.
In case anyone wants to reproduce this, its relatively easy to do; just
use some configuration similar to the one I sent earlier and enable
debug/trace logging for activemq in the client. You'll see a flow of
keep-alive messages sent back and forth. If you then disable the
activemq-server, the flow will obviously stop.
But with the cache at connection level you'll see reconnection-attempts
from spring and as soon as the server is available again a new
connection is made. With the cache at 'auto' (consumer) no new messages
appear once the connection is gone.
Best regards,
Arjen
On 5-10-2009 8:11, fehm wrote:
Hi Arjen,
did you try to enable failover transport mechanism :
http://activemq.apache.org/failover-transport-reference.html
This will enable the client to reconnect in case of disconnection. the
default transport url you use will NOT automatically reconnect.
Cheers,
Felix
Arjen van der Meijden wrote:
Noone with an idea? Do I need to supply more information and/or do more
testing?
Best regards,
Arjen
On 25-9-2009 9:09, Arjen van der Meijden wrote:
Hi List,
I have some topics with very few messages (it can be days or weeks
before a message arrives) on it. The consumers to those topics
disconnect after some time and don't reconnect afterwards.
I have no idea where to put the blame (activemq-server,
activemq-consumer, spring?), but I'd like those consumers to just sit
and wait rather than decide to leave after a while (or get booted from
the server).
The disconnect-behaviour doesn't seem to be too consistent as I've
connected a test-consumer to a test-activemq where I'm pretty sure there
was no traffic on any of the topics last night and of the 8 topics only
3 have disconnected so far according to the webbased admin.
I'm using ActiveMQ 5.2 where the topic-consumption is handled via
Spring's default jms-handling:
<bean id="amqFact" class="org.apache.activemq.ActiveMQConnectionFactory">
<constructor-arg value="${jms.username}" />
<constructor-arg value="${jms.password}" />
<constructor-arg value="${jms.url}" />
</bean>
<jms:listener-container connection-factory="amqFact"
destination-type="topic">
<jms:listener destination="topicname" ref="someMessageListenerImpl" />
<!-- and seven more topics -->
</jms:listener-container>
The configured url is tcp://hostname:61616 with no added parameters.
ActiveMQ itself is mostly left to its defaults, although openWire is
configured like (i.e. with the added transport.closeAsync):
<transportConnector name="openwire"
uri="tcp://localhost:61616?transport.closeAsync=false"
discoveryUri="multicast://default"/>
Which flag/configuration on which side is responsible for this
behaviour? And how do I change it?
Best regards,
Arjen
