Hello Ted, Did you happen to have the time to check if a minor release is possible? Regards,Adel
> From: [email protected] > To: [email protected] > Subject: RE: Testing failover on dispatcher/java-broker cluster > Date: Tue, 20 Sep 2016 15:13:03 +0200 > > 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: [email protected] > > From: [email protected] > > 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: [email protected] > > >> From: [email protected] > > >> 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: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > >
