Re: Testing failover on dispatcher/java-broker cluster
Hi Ted, Do you have any insights into that problem? Thanks, Antoine > 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
Qpid proton C++ supports failover url?
Hello, Does the Proton C++ API support the failover url just like JMS does? If no, what workarounds could I use? Regards, Adel Get Outlook for Android
Re: Qpid proton C++ supports failover url?
We may be able to use load balancer like HAProxy (level 4) But retry has to be handled; maybe proton-c provide something. On Friday, 16 September 2016,wrote: > > > Hello, > > > Does the Proton C++ API support the failover url just like JMS does? > > If no, what workarounds could I use? > > > Regards, > > Adel > > > Get Outlook for Android > > >
Re: [QPID C++][Java JMS client] Data gets corrupted when sent to the server over SSL
On 16/09/16 12:39, Morgan Lindqvist wrote: Hi all, I have an issue that data gets corrupted if the size is 66068 but not if it is 65068 or smaller when using the JavaJMS client. The server is QPIC C++ and SSL encryption is used. If I instead use a Node JS based client I have no issues with the size of the messages. I have sent a 1MB large message and it came through as it should. Is there a setting in a client that changes how it behaves when it comes to large messages? I guess there could be a bug in the QPID C++ server implementation that is triggered by the JMS client. Any opinions on this? I have been searching for related issues and I only found this one, https://issues.apache.org/jira/browse/PROTON-537, but it is solved. Any pointer what could be the issue and how I could solve it? (I can not use the Node JS client, I need a Java client) Could you try with the AMQP 1.0 JMS client? (Latest version is 0.11.0) - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[QPID C++][Java JMS client] Data gets corrupted when sent to the server over SSL
Hi all, I have an issue that data gets corrupted if the size is 66068 but not if it is 65068 or smaller when using the JavaJMS client. The server is QPIC C++ and SSL encryption is used. If I instead use a Node JS based client I have no issues with the size of the messages. I have sent a 1MB large message and it came through as it should. Is there a setting in a client that changes how it behaves when it comes to large messages? I guess there could be a bug in the QPID C++ server implementation that is triggered by the JMS client. Any opinions on this? I have been searching for related issues and I only found this one, https://issues.apache.org/jira/browse/PROTON-537, but it is solved. Any pointer what could be the issue and how I could solve it? (I can not use the Node JS client, I need a Java client) Best Regards, Morgan Environment information: Server: QPID C++ server version 1.35.0 (from PPA Testing https://launchpad.net/~qpid/+archive/ubuntu/testing) OS: Ubuntu 14.04 AMQP version: 1.0 Client with issue: QPID Java JMS client Version 6.0.4 Java version: 1.8.0_101 Client that works: Node JS AMQP10: https://www.npmjs.com/package/amqp10 Version: 3.2.5 Node version: 4.5.0 -- View this message in context: http://qpid.2158936.n2.nabble.com/QPID-C-Java-JMS-client-Data-gets-corrupted-when-sent-to-the-server-over-SSL-tp7650810.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Testing failover on dispatcher/java-broker cluster
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