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
> 
                                          

Reply via email to