This is dated from earlier discussions - but should still apply.

JMS (webtier) / MQ (webtier & etier) - In webtier, the JMS and MQ listener operates by polling the queue (or topic) for new messages.  The same is true for MQ etier.  When a message is found, it is popped and processed.  When a node quiesces, the JMS listener stops and the queue will accumulate messages unless another node is configured to process messages from the queue (is this possible in webtier?).

 

JMS (etier) - In an etier deployment, JMS messages are processed by message driven beans.  These MDBs are invoked by the container as messages arrive into the queue.  In this respect, the container controls the listener and the PRPC engine is externally invoked.  For this reason, the messaging engine must be stopped in the container before the node is put into quiesce mode.  In fact, not only does the messaging engine need to be stopped, but you must ensure the queue is empty.  Once the listener stops, any delivered messages will generate an exception.  If this invocation is container managed, the container will retry that message for some number of tries before putting it in the dead queue.  If the invocation is not container managed, the message is lost (this is part of the contract of bean managed JMS queues).