Hello Ted, I confirm the fix solved the issue.
Would it be possible to do a 0.6.2 release? We cannot compile newer versions of Proton (We currently use 0.12.2) due to lack of resources from our side and we really need this fix for our tests. Regards, Adel > Subject: Re: Testing failover on dispatcher/java-broker cluster > To: users@qpid.apache.org > From: tr...@redhat.com > Date: Mon, 19 Sep 2016 12:18:23 -0400 > > Hi Adel, > > It's a one-liner and it applies cleanly to the 0.6.x branch. > > https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=41b7407 > > -Ted > > > On 09/19/2016 11:41 AM, Adel Boutros wrote: > > Hello Ted, > > > > Antoine is on vacation so I will be taking over this task. > > > > Does this fix have any dependencies? We would like to apply it on 0.6.1 > > without other fixes because it seems the master branch requires proton > > 0.13.0 minimum whereas we have currently 0.12.2 and we cannot upgrade at > > the time being. > > > > Regards, > > Adel > > > >> Subject: Re: Testing failover on dispatcher/java-broker cluster > >> To: users@qpid.apache.org > >> From: tr...@redhat.com > >> Date: Fri, 16 Sep 2016 16:53:05 -0400 > >> > >> Antoine, > >> > >> I think I know what that problem is. I belileve you've stumbled upon > >> this issue: > >> > >> https://issues.apache.org/jira/browse/DISPATCH-496 > >> > >> Your second delivery, the one resulting in a timeout, is causing the > >> inbound link to be blocked (i.e. it has undelivered messages). When the > >> broker reattaches, the blocked links are supposed to become unblocked > >> but they don't in the case of auto-links. > >> > >> This has been fixed on the master branch if you'd like to try applying > >> the patch. > >> > >> -Ted > >> > >> On 09/15/2016 04:56 AM, Antoine Chevin wrote: > >>> Hi Ted, > >>> > >>> You’re right, the connection close looked strange before stopping of the > >>> broker. I manually added the annotation (# stopping the broker) and was > >>> wrong about the position of this one. I replayed the test and the > >>> connection close happens *after* the broker stop. I assume it is the > >>> broker > >>> that initiates it. > >>> > >>> I found something interesting. In my test, I always sent a message when > >>> the > >>> broker is down, expecting to get a JmsSendTimedOutException (waiting for > >>> the disposition frame). I assumed this was harmless. But it turns out this > >>> is not. When I don’t do that, I can send a message after the broker > >>> restart. So to sum up the experiment I did: > >>> > >>> * I use Wireshark between the JMS client and the dispatcher. * > >>> > >>> 1) Using JMS I establish a connection to the dispatcher and create a > >>> message producer (Wireshark: connection open -> attach) > >>> 2) I’m able to send a message to the broker through the dispatcher ( > >>> Wireshark: transfer -> disposition) > >>> 3) I stop the broker > >>> 4) With the same link, I send a message and I get a > >>> JmsSendTimedOutException (waiting for the disposition frame) (Wireshark: > >>> transfer) > >>> 5) I restart the broker > >>> 6) With the same link, I try to send a message and I get a > >>> JmsSendTimedOutException for the same reason (waiting for the disposition > >>> frame) (Wireshark: transfer) > >>> > >>> If I skip step (4), I cannot reproduce step (6) and my messages arrive > >>> (Wireshark: transfer -> disposition) to the restarted broker. > >>> > >>> I hope it makes it clearer for you. Sorry for my rookie mistakes :-). > >>> > >>> Note: My colleague and I ran a small experiment to identify if the problem > >>> comes from JMS or the AMQP protocol. He changed the code of the java > >>> broker > >>> to not send the disposition frame one time out of two. > >>> > >>> We got these results: > >>> > >>> * I use Wireshark between the JMS client and the patched broker. * > >>> > >>> 1) Using JMS I establish a connection to the patched broker and create a > >>> message producer (Wireshark: connection open -> attach) > >>> 2) I send a message to the broker and it replies with the disposition > >>> frame (Wireshark: transfer -> disposition) > >>> 3) I send a message to the broker which drops the disposition frame. I get > >>> a send timeout in JMS (Wireshark: transfer) > >>> 2) I send a message to the broker and it replies with the disposition > >>> frame > >>> (Wireshark: transfer -> disposition). It works fine. > >>> > >>> We assume that there is something going on in the dispatcher. > >>> > >>> > >>> Thanks, > >>> Antoine > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: users-h...@qpid.apache.org > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org >
