It's possible. Although, I didn't see any prefetch=0 use in your configs (could be I didn't look hard enough since I didn't suspect it). Prefetch=0 uses different code paths for delivery of messages to clients - clients must poll the server, and the server synchronously returns a message, with prefetch=0. Without prefetch=0, the server pushes a number of messages asynchronously to the client, up the the prefetch value, and then waits until acknowledgements bring down the prefetch queue size before pushing more.
One more question for you - when the solution works, does that include or exclude the outbound bridge? I'm confused on that front because of the statement that the outbound bridge never worked together with the statement that the solution works with the change in network configuration. In order to diagnose an issue like this, some clarity in terms of "what does ActiveMQ do that is unexpected?" or "what doesn't ActiveMQ do that is expected" is needed - at the level of the API interactions. Since the bridge is "in a way" internal to ActiveMQ, it may seem tricky, but it is possible to think of the bridge as separate - and even run it in a separate JVM. At this point, it sounds like your efforts to track down the problem are moving in the right direction. If I were working on it, I would be looking to enable debug logging, add log statements, grab stack traces at the time the problem is observed, and other means of getting more details which explain the lack of expected message flow. Also consider that the exact same broker topology working with only a change to the network sounds like an issue outside of ActiveMQ rather than one inside, although there are possibilities inside the broker - especially race conditions. Hope this helps. -- View this message in context: http://activemq.2283324.n4.nabble.com/JMS-to-JMS-Bridge-Connection-tp4684129p4684280.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
