Bug 1116763
| Summary: | amqp1.0 receiver doesn't reconnect to jboss amq | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Valiantsina Hubeika <vhubeika> |
| Component: | qpid-cpp | Assignee: | Gordon Sim <gsim> |
| Status: | CLOSED DUPLICATE | QA Contact: | Messaging QE <messaging-qe-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | Development | CC: | esammons, jross, vhubeika |
| Target Milestone: | 3.1 | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-09-16 18:23:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Regarding the reproducer, the qc2_drain program has a 0 timeout by default. This means that it will exit if there are no messages on the queue. If the messages that were sent to newQ were not persisted, they will be lost when the broker is restarted. Thus, when qc2_drain reconnects and resumes its fetching, it will get no message and will exit. If you specify a timeout of say 10 secs and then on restarting the broker send some new messages to newQ, then I believe you will see the receiver receive those after reconnect rather than exiting. Hi Gordon, thank you for the tips. In my case, I am using default configuration(durable queues) and persistent messages (sorry I just assumer it and didn't well described). 1. I believe in this case the reconnect should be successful as the messages are present in the queue. In the actual results above I list another receiver launched just right after the 'reconnecting' receiver quits. The second receiver continues receiving messages fine. What is probably noteworthy is that if in the very same configuration (durable queue, persistent messages) I use receiver with mentioned by you time-out, then the reconnect works as expected. I believe this is odd, as qpid doesn't require any time-out in the receiver in same configuration. 2. In case of non-durable queue and non-persistent messages, reconnect works fine with receiver time-out and sending some more messages. (In reply to vhubeika from comment #2) > 1. I believe in this case the reconnect should be successful as the messages > are present in the queue. In the actual results above I list another > receiver launched just right after the 'reconnecting' receiver quits. The > second receiver continues receiving messages fine. This is likely the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1116769, i.e. the drain not being handled as expected by the server. If you have a protocol trace we can confirm that. (The fact that a small timeout also resolves the problem also supports this theory). *** This bug has been marked as a duplicate of bug 1116769 *** |
Description of problem: amqp1.0 receiver does not reconnect to jboss amq, when server is restarted. Version-Release number of selected component (if applicable): qpid-cpp-0.22-42 How reproducible: 100% Steps to Reproduce: 1. start jboss amq 2. connect to amq with receiver and start receiving messages 3. stop and start amq 4. continue receiving messages Actual results: receiver exits immediately once broker is up again. root @mrg-qe-26 /var/dtests/node_data/clients 05:08:16 $ ./qc2_drain --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1000 --duration 1000 Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:0'}, content='') Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:1'}, content='') Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:2'}, content='') Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:3'}, content='') Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:4'}, content='') 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:12 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:13 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:14 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:16 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:18 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 2014-07-07 05:09:20 [Messaging] notice Failed to connect to tcp:127.0.0.1:5672 root @mrg-qe-26 /var/dtests/node_data/clients 05:09:39 $ ./qc2_drain --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1000 --duration 1000 Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:4', 'x-amqp-delivery-count': '2'}, content='') Message(properties={'spout-id': '814b766d-905c-4268-8103-b329d08777dc:5', 'x-amqp-delivery-count': '2'}, content='') ... Expected results: receiver continues reading once broker is up again Additional info: