We are indeed in favor of a minor release as long as the latest version is still 0.6.x and we are willing to re-launch our tests and give feedback on the release candidate once provided (It shouldn't take us more than a day to compile and test). Do you have a list of fixes in mind? Regards,Adel
> Subject: Re: Testing failover on dispatcher/java-broker cluster > To: users@qpid.apache.org > From: tr...@redhat.com > Date: Fri, 23 Sep 2016 17:23:57 -0400 > > Hi Adel, > > A minor release is always possible. It's up to us, the community, to > decide whether and when to produce one. I'm in favor of releasing an > 0.6.2 with some small backports to fix bugs for users that want to stay > on Proton 0.12. > > -Ted > > On 09/23/2016 09:44 AM, Adel Boutros wrote: > > Hello Ted, > > Did you happen to have the time to check if a minor release is possible? > > Regards,Adel > > > >> From: adelbout...@live.com > >> To: users@qpid.apache.org > >> 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: 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 > >>> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org >
