hot deployment of queues at runtime problem 3.2.6

[rikko]

Hi,

We have a system over here which consists of multiple queues with senders and receivers. Just the other day we noticed a problem during some maintenance.
This problem starts when we change the xml file in which the queues are defined, JBoss sees that the file is changed and will automticaly discard its current queues and restart the queues defined in the newly saved file. At this point all seems well, all queues are there and any sender or receiver is able to find them.
However, the receivers who had already found the (old) queues (before the file was changed) are NOT notified of the 'broken connection'. Despite the fact that they have registerd them selves as an exceptionlistener.
This results in receivers 'listening' to old (non-existent) queues and senders filling the new queues. As one can imange the new queues won't have any listeners so the messages won't be read by any receiver at all.

Does anyone have a solution to this problem?

As mentioned in the subject we are working with 3.2.6


Rikko

[adrian.brock]

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.