can you try with Trunk, this sounds very familiar and may be fixed
thanks for the fast response.
I will try with trunk today.
If it sounds familiar, is there by any chance a workaround without resorting to a JMS-Bridge?
try setting the confirmation-window-size on the bridge to >0
I tried on trunk with the same result. Sending a large message (9MB) results in DeliveringCount=1 continuously on the source queue. Setting confirmation-window-size > 0 (I tried 102400) doesn't help. Stopping and starting the bridge via JMX-Console gets the successfully consumed message being redelivered.
For our production problem I now configured a JMS-Bridge which doesn't show the same behaviour (after setting cache-large-message-client=true for the connection factory - without there is a exception already documented somewhere here in the forum).
ok, i see, its specific to large messages, could you raise a jira please with instructions on how to recreate
I created JIRA HORNETQ-638 and attached a patch for the core-bridge-example to reproduce.
Thanks for your help!
Can you try with this branch please?
Build it and test it.. we have made several changes on it. It would help us if you could verify it for us.
I tried with Branch_2_2_EAP revision 10185 but I got the same result
You can apply the patch in the JIRA.