Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1116769

Summary: amqp1.0 receiver doesn't receive from jboss amq
Product: [JBoss] JBoss Fuse Service Works 6 Reporter: Valiantsina Hubeika <vhubeika>
Component: MessagingAssignee: Jack Britton <jbritton>
Status: CLOSED UPSTREAM QA Contact: Matej Melko <mmelko>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.1.0CC: ganandan, jross, soa-p-jira
Target Milestone: ---   
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:42:28 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:
Attachments:
Description Flags
reproducer log none

Description Valiantsina Hubeika 2014-07-07 09:25:56 UTC
Description of problem:

Sometimes receiver quits returning no messages though the queue is full. Drains needs to run several times to return as expected.  


Version-Release number of selected component (if applicable):
qpid-cpp-0.22-42

How reproducible:
random

Steps to Reproduce:
1. start jboss amq
2. send messages to queue
3. receive messages from queue

Actual results:
Receiver need to be run several times to succeed. 

root @mrg-qe-26 /var/dtests/node_data/clients  05:05:53 $ ./qc2_spout --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1 --log-msgs dict
{'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 0, 'durable': False, 'ttl': 0.000000e+00, 'size': None, 'properties': {'spout-id': '06d746aa-32e1-4a26-83a4-16dd8e548d78:0'}, 'content': None}
root @mrg-qe-26 /var/dtests/node_data/clients  05:05:56 $ ./qc2_drain --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1000 --duration 1000
root @mrg-qe-26 /var/dtests/node_data/clients  05:05:57 $ ./qc2_drain --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1000 --duration 1000
root @mrg-qe-26 /var/dtests/node_data/clients  05:06:42 $ ./qc2_drain --connection-options '{ "protocol" : "amqp1.0", "reconnect": "True"}' newQ --count 1000 --duration 1000
Message(properties={'spout-id': '06d746aa-32e1-4a26-83a4-16dd8e548d78:0', 'x-amqp-delivery-count': '2'}, content='')


Expected results:
receiver receives at first try. 


Additional info:

see also BZ 1116763

Comment 1 Gordon Sim 2014-08-20 20:24:55 UTC
I can't reproduce this. I have built the QA clients against the latest 0.22-mrg tree and am testing against jboss-a-mq-6.1.0:

After qc2_spout with above options (plus some for authentication, I didn't yet configure a-mq for anonymous access), the qc2_drain always returns the message.

Are you still seeing the issue? If you could you give me some more detail to help try and reproduce or identify the issue? E.g. export PN_TRACE_FRM=1 when running the qc2_drain?

Comment 3 Valiantsina Hubeika 2014-08-21 10:36:01 UTC
Created attachment 929158 [details]
reproducer log

Comment 4 Gordon Sim 2014-08-21 11:20:51 UTC
The problem is that the broker is replying to a drain request by the client by saying there are not more messages to send:


root @mrg-qe-26 /var/dtests/node_data/clients  06:25:34 $ ./qc2_drain --connection-options "{protocol: "amqp1.0",  "sasl_mechanisms":"PLAIN" }" "Q" -c 10  -b admin/admin@localhost:5672
[0xbc1300]:  -> AMQP
[0xbc1300]:  <- AMQP
[0xbc1300]:0 -> @open(16) [container-id="4b766fa6-6ffb-4d1d-bbf9-8a8f9cb02dcb", properties={:"qpid.client_process"="qc2_drain", :"qpid.client_pid"=20963, :"qpid.client_ppid"=18967}]
[0xbc1300]:0 <- @open(16) [container-id="", hostname="", max-frame-size=1048576]
[0xbc1300]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
[0xbc1300]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=0, outgoing-window=0, handle-max=1024]
[0xbc1300]:0 -> @attach(18) [name="Q_457ba44f-1f6a-448c-8922-204208e95979", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="Q", durable=0, timeout=0, dynamic=false], target=@target(41) [address="Q", durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0xbc1300]:0 <- @attach(18) [name="Q_457ba44f-1f6a-448c-8922-204208e95979", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="Q"], target=@target(41) [address="Q"], incomplete-unsettled=false, initial-delivery-count=0]
[0xbc1300]:0 -> @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1, drain=true]
[0xbc1300]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"0", message-format=0] (70) "\x00Sp\xc0\x08\x05BP\x00@@R\x03\x00St\xc14\x02\xa1\x08spout-id\xa1'28e4cec9-b679-4495-aa15-507ee5b2f660:10"
Message(properties={'spout-id': '28e4cec9-b679-4495-aa15-507ee5b2f660:10', 'x-amqp-delivery-count': '3'}, content='')
[0xbc1300]:0 -> @flow(19) [next-incoming-id=2, incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=1, link-credit=1, drain=true]
[0xbc1300]:0 -> @disposition(21) [role=true, first=0, last=0, settled=true, state=@accepted(36) []]
[0xbc1300]:0 <- @transfer(20) [handle=0, delivery-id=1, delivery-tag=b"1", message-format=0] (70) "\x00Sp\xc0\x08\x05BP\x00@@R\x03\x00St\xc14\x02\xa1\x08spout-id\xa1'28e4cec9-b679-4495-aa15-507ee5b2f660:11"
Message(properties={'spout-id': '28e4cec9-b679-4495-aa15-507ee5b2f660:11', 'x-amqp-delivery-count': '3'}, content='')
[0xbc1300]:0 -> @flow(19) [next-incoming-id=3, incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=2, link-credit=1, drain=true]

^^^^ The client asks the server to drain the credit, i.e. to reply either with a messgae transfer, or with a flow that sets drain=true and credit=0

[0xbc1300]:0 -> @disposition(21) [role=true, first=1, last=1, settled=true, state=@accepted(36) []]
[0xbc1300]:0 <- @flow(19) [next-incoming-id=0, incoming-window=1, next-outgoing-id=3, outgoing-window=0]
[0xbc1300]:0 <- @flow(19) [next-incoming-id=0, incoming-window=1, next-outgoing-id=3, outgoing-window=0, handle=0, delivery-count=3, link-credit=0, drain=true]

^^^^ Instead of giving a message transfer (and there should be messages on the queue), the broker is replying that the credit has been drained and no messages were available.

[0xbc1300]:0 -> @detach(22) [handle=0, closed=true]
[0xbc1300]:0 <- @detach(22) [handle=0, closed=true]
[0xbc1300]:0 -> @end(23) []
[0xbc1300]:0 -> @close(24) []
[0xbc1300]:  -> EOS
[0xbc1300]:0 <- @end(23) []
[0xbc1300]:0 <- @close(24) []
[0xbc1300]:  <- EOS

Summary: it looks like a broker side issue. The workaround would be to try a non-zero timeout, e.g. --timeout 1

Comment 5 kconner 2014-08-21 18:23:50 UTC
This is not an issue for FSW, it needs to have a JIRA created for the A-MQ product.

Comment 6 Justin Ross 2014-09-16 18:23:19 UTC
*** Bug 1116763 has been marked as a duplicate of this bug. ***

Comment 10 Red Hat Bugzilla 2025-02-10 03:42:28 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.