-
1. Re: hot deployment of queues at runtime problem 3.2.6
adrian.brock Nov 29, 2004 1:00 PM (in response to rikko)This has never been supported by JBossMQ.
If you want to force clients to reconnect, you can reploy the connection factorys
e.g.
> touch uil2-service.xml
The ExceptionListener is only invoked for a communication exception
(as per spec).
There is no automatic reconnect of client subscriptions if you redeploy destinations.
The JMS spec has no mechanism to notify a client of a redeployed destination
or any non communication problem for a MessageListener
(it defines nothing WRT administered objects except that they must bindable into jndi).
The current jbossmq implementation simplying reports a warning (via log4j) when
the destination, to which a MessageListener is connected, is undeployed.
If you don't have log4j configured, you won't see the message.
I would accept a patch that allowed these warnings
to be sent to the ExceptionListener if this were made optional through
some sort of configuration (system property?).
I would also be interested if somebody provided a patch to automatically relink
clients to redeploy destinations. But the implementation is non-trivial.
It would require the org.jboss.mq.server.ClientConsumer to hold requests from the
client until the destination is available again (relinking the subscription to the
new BasicQueue when it is redeployed).
It would also need to somehow know what the client is doing and fail
things like transactions commits or client message acknowledgements
if they were linked to the previous deployment of the destination.
At undeployment of the destination, all unacknowledged messages (including
those in transactions) are nacked.
Additionally messages for non-durable subscriptions are deleted.