Forward Delay on Uniform Distributed queues with no consumers

Question

Suppose you have a cluster with 2 members, and a uniform distributed queue targeted to the cluster. Messages are produced onto the queue by an application targeted to the cluster, so both distributed members should receive messages. Messages within the queues are consumed by a remote WL server which intermittantly connects ( with t3:// ).
By default, the forward delay is disabled ( set to -1 ) on a queue, so no messages will be forwarded from a queue with no consumers to a queue that does have consumers. A load balancer in front of the cluster should result in the remote cluster's JMS consumer alternating its connection across the cluster.
If the remote server is connecting to only a single node within the cluster, it will only consume messages from one queue, leaving the other queue's messages un-consumed. But if both queues are configured to use forward delay, and there are no consumers to either queue, will the messages be continuously forwarded back and forth between the queues?
Or, once the forward delay has expired, will the queues wait for a consumer to show up and then forward all its messages at once?
I'm wondering how much "sloshing" there's going to be between the nodes of the cluster, as messages are pushed back and forth between the queues.

Answer 1

From the documentation, a distributed queue forward delay is:
The amount of time (in seconds) that a distributed queue member with messages, but no consumers, will wait before forwarding its messages to other queue members that do have consumers.Therefore, messages will not forward if a consumer attaches before the configure idle period passes, or if there are no consumers on other queue members.
I think one case where "Sloshing" would occur if all of the following were true: consumers are transitory and only exist for slightly more than the idle period, message rates are sufficiently high so that the consumer sometimes cannot keep up for significant periods of time, not all destinations are concurrently serviced by consumers, and the limited number of consumers that do exist frequently do not re-attach to the same member.
Obligatory distributed queue best practice note: For the best performance, simplicity, HA, and message ordering support, it's generally a best practice to ensure that every member of a distributed queue is serviced by a consumer. WebLogic MDBs are specifically designed to handle this need simply and automatically.
Tom
Edited by: TomB on Apr 23, 2009 6:27 AM