You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by rk <rk...@roke.co.uk> on 2018/10/19 11:13:47 UTC
Go Electron: Large Messages Fail To Send
Hi
When using the Go electron bindings I am unable to send a message larger
than 16k in size to the qpidd broker. The broker seems to receive the data
but never responds with an appropriate message causing the electron client
to hang indefinitely. I have the following debug output from the broker
showing the broker receiving 2 messages 1 smaller than 16k and 1 larger than
16k. As you can see from the output the 'received delivery' line never
appears in the larger message output.
*Message <16k*
2018-10-18 15:08:20 [Broker] debug Incoming link attached
2018-10-18 15:08:20 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.5:45908
link 0x7f304c002b30 attached on 0x7f304c00e360
2018-10-18 15:08:20 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45908
encoded 353 bytes from 65536
2018-10-18 15:08:20 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45908
decoded 7240 bytes from 7240
2018-10-18 15:08:20 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45908
decoded 2830 bytes from 2830
2018-10-18 15:08:20 [Broker] debug received delivery: 1
*Message >16k*
2018-10-18 15:06:32 [Broker] debug Incoming link attached
2018-10-18 15:06:32 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.5:45896
link 0x7f22d4003770 attached on 0x7f22d400efe0
2018-10-18 15:06:32 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45896
encoded 353 bytes from 65536
2018-10-18 15:06:32 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45896
decoded 7240 bytes from 7240
2018-10-18 15:06:32 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45896
decoded 9144 bytes from 9144
2018-10-18 15:06:32 [Network] debug qpid.172.18.0.2:5672-172.18.0.5:45896
decoded 43686 bytes from 43686
Using the python client I can send much larger messages than 16k to the same
broker so it appears to be an issue with the Go bindings.
The issue can be recreated by editing the example send.go file in the
electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
I am using version 1.38.0 of qpidd running on Centos 7 and the Go is bring
compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
library.
My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
why qpidd thinks it hasn't got the delivery so any help much appreciated.
Thanks
Rob
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by Jiri Daněk <jd...@redhat.com>.
On Fri, Oct 19, 2018 at 2:10 PM Gordon Sim <gs...@redhat.com> wrote:
> On 19/10/18 12:13, rk wrote:
> > Using the python client I can send much larger messages than 16k to the
> same
> > broker so it appears to be an issue with the Go bindings.
> >
> > The issue can be recreated by editing the example send.go file in the
> > electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
> >
> > I am using version 1.38.0 of qpidd running on Centos 7 and the Go is
> bring
> > compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
> > library.
> >
> > My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
> > why qpidd thinks it hasn't got the delivery so any help much appreciated.
>
I got a similar issue with ActiveMQ Artemis a while back.
https://issues.jboss.org/browse/ENTMQCL-458
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: Go Electron: Large Messages Fail To Send
Posted by rk <rk...@roke.co.uk>.
aconway.rh wrote
> Can you try your case with the latest source on the master branch? This
> may
> be a symptom of a recently fixed bug:
>
> PROTON-1953: [go] occasional client/server hang with high volume of
> messages
>
> Although the bug was observed with many small messages, I think it could
> also cause problems with large messages.
>
> If that doesn't resolve the problem, please raise a new JIRA with your
> observations and reproducer code attached.
>
>
> On Wed, Oct 24, 2018 at 11:11 AM Gordon Sim <
> gsim@
> > wrote:
>
>> On 24/10/18 11:35, rk wrote:
>> > OK thanks. I can get a capture of the wire output is there anything in
>> > particular I should be looking for that might cause this behaviour?
>>
>> More than one thread trying to operate on the same underlying proton
>> connection would certainly cause problems. It could be in the library
>> implementation though that the problem lies, not in your code.
>>
>> Alan, any thoughts or comments?
>>
I have been using the latest version for all of this testing so it hasn't
been fixed by that unfortunately. I have opened this issue PROTON-1960
<https://issues.apache.org/jira/projects/PROTON/issues/PROTON-1960?filter=allopenissues>
. I will continue to investigate as could really do with it fixing so will
update the issue if I get any where. Thanks.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by Alan Conway <ac...@redhat.com>.
Can you try your case with the latest source on the master branch? This may
be a symptom of a recently fixed bug:
PROTON-1953: [go] occasional client/server hang with high volume of messages
Although the bug was observed with many small messages, I think it could
also cause problems with large messages.
If that doesn't resolve the problem, please raise a new JIRA with your
observations and reproducer code attached.
On Wed, Oct 24, 2018 at 11:11 AM Gordon Sim <gs...@redhat.com> wrote:
> On 24/10/18 11:35, rk wrote:
> > OK thanks. I can get a capture of the wire output is there anything in
> > particular I should be looking for that might cause this behaviour?
>
> More than one thread trying to operate on the same underlying proton
> connection would certainly cause problems. It could be in the library
> implementation though that the problem lies, not in your code.
>
> Alan, any thoughts or comments?
>
Re: Go Electron: Large Messages Fail To Send
Posted by Gordon Sim <gs...@redhat.com>.
On 24/10/18 11:35, rk wrote:
> OK thanks. I can get a capture of the wire output is there anything in
> particular I should be looking for that might cause this behaviour?
More than one thread trying to operate on the same underlying proton
connection would certainly cause problems. It could be in the library
implementation though that the problem lies, not in your code.
Alan, any thoughts or comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by rk <rk...@roke.co.uk>.
Gordon Sim wrote
> On 22/10/18 08:27, rk wrote:
>> [0x7f80ec001c20]:0 -> @transfer(20) [handle=0, delivery-id=0,
>> delivery-tag=b"1", message-format=0] (20016)
>> "\x00SpE\x00SsE\x00Sw\xb0\x00\x00N xxxxxxxxxxxxxxxxxxxxxxxxxxx...
>> (truncated)
>>
>> [0x7f80ec001c20]:RAW:
>> "\x00\x00NM\x02\x00\x00\x00\x00S\x14\xd0\x00\x00\x00\x0d\x00\x00\x00\x04R\x00R\x00\xa0\x011R\x00\x00SpE\x00SsE\x00Sw\xb0\x00\x00N
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> ...."
>
> That looks ok to me. The only thing I can think is that what is written
> to the wire does not match the logged output.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
OK thanks. I can get a capture of the wire output is there anything in
particular I should be looking for that might cause this behaviour?
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by Gordon Sim <gs...@redhat.com>.
On 22/10/18 08:27, rk wrote:
> [0x7f80ec001c20]:0 -> @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"1", message-format=0] (20016)
> "\x00SpE\x00SsE\x00Sw\xb0\x00\x00N xxxxxxxxxxxxxxxxxxxxxxxxxxx...
> (truncated)
>
> [0x7f80ec001c20]:RAW:
> "\x00\x00NM\x02\x00\x00\x00\x00S\x14\xd0\x00\x00\x00\x0d\x00\x00\x00\x04R\x00R\x00\xa0\x011R\x00\x00SpE\x00SsE\x00Sw\xb0\x00\x00N
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> ...."
That looks ok to me. The only thing I can think is that what is written
to the wire does not match the logged output.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by rk <rk...@roke.co.uk>.
Gordon Sim wrote
> On 19/10/18 13:32, rk wrote:
>> Gordon Sim wrote
>>> On 19/10/18 12:13, rk wrote:
>>>> Using the python client I can send much larger messages than 16k to the
>>>> same
>>>> broker so it appears to be an issue with the Go bindings.
>>>>
>>>> The issue can be recreated by editing the example send.go file in the
>>>> electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
>>>>
>>>> I am using version 1.38.0 of qpidd running on Centos 7 and the Go is
>>>> bring
>>>> compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
>>>> library.
>>>>
>>>> My knowledge of AMQP and the qpidd internals isn't great so I'm unsure
>>>> of
>>>> why qpidd thinks it hasn't got the delivery so any help much
>>>> appreciated.
>>>
>>>
>>> If you can get a protocol trace, that would be helpful. --log-enable
>>> trace+:Protocol as an argument to qpidd should do it.
>>>
>>> For additional commands, e-mail:
>>
>>> users-help@.apache
>>
>>
>> Protocol output below
>>
>> 2018-10-19 12:27:22 [Protocol] debug
>> qpid.172.18.0.2:5672-172.18.0.4:50426
>> Sent SASL-MECHANISMS(ANONYMOUS PLAIN) 40
>> 2018-10-19 12:27:22 [Protocol] debug
>> qpid.172.18.0.2:5672-172.18.0.4:50426
>> writing protocol header: 1-0
>> 2018-10-19 12:27:22 [Protocol] debug
>> qpid.172.18.0.2:5672-172.18.0.4:50426
>> Received SASL-INIT(ANONYMOUS, anonymous@a9ac779f4434, )
>> 2018-10-19 12:27:22 [Protocol] debug
>> qpid.172.18.0.2:5672-172.18.0.4:50426
>> Sent SASL-OUTCOME(0) 16
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: -> AMQP
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: <- AMQP
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @open(16)
>> [container-id="send[1]", channel-max=32767]
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @begin(17)
>> [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @attach(18)
>> [name="send[1]@1",
>> handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
>> source=@source(40) [address="", durable=0, expiry-policy=:"link-detach",
>> timeout=0, dynamic=false], target=@target(41) [address="test_exchange",
>> durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
>> initial-delivery-count=0, max-message-size=0]
>> 2018-10-19 12:27:22 [Protocol] debug
>> qpid.172.18.0.2:5672-172.18.0.4:50426
>> link 0x7f2728001900 attached on 0x7f272801a540
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @open(16)
>> [container-id="dd6b88fa-8a0e-4437-9aca-22e4626abddc", channel-max=32767,
>> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
>> properties={:product="qpid-cpp", :version="1.38.0", :platform="Linux",
>> :host="af00d45580a7"}]
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @begin(17)
>> [remote-channel=0,
>> next-outgoing-id=0, incoming-window=2147483647,
>> outgoing-window=2147483647]
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @attach(18)
>> [name="send[1]@1",
>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [durable=0, timeout=0, dynamic=false],
>> target=@target(41)
>> [address="test_exchange", durable=0, timeout=0, dynamic=false],
>> initial-delivery-count=0, max-message-size=0]
>> 2018-10-19 12:27:22 [Protocol] trace
>> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @flow(19)
>> [next-incoming-id=0,
>> incoming-window=2147483647, next-outgoing-id=0,
>> outgoing-window=2147483647,
>> handle=0, delivery-count=0, link-credit=500, drain=false]
>
> Was there no more to that trace? Assuming similar debug logging to what
> you originally reported, that would suggest the client is sending an
> incomplete frame, e.g. possibly the frame size is wrong.
>
> One more request if you don't mind, could you run with env var
> PN_TRACE_RAW=1 and PN_TRACE_FRM=1 on the client side?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
Yes that's all there was I'm afraid. Setting those env vars I have the
following output from the client
[0x7f80ec001c20]: -> SASL
[0x7f80ec001c20]: <- SASL
[0x7f80ec001c20]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7f80ec001c20]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"anonymous@559a9935bd94"]
[0x7f80ec001c20]:RAW:
"\x00\x00\x007\x02\x01\x00\x00\x00SA\xd0\x00\x00\x00'\x00\x00\x00\x02\xa3\x09ANONYMOUS\xa0\x16anonymous@559a9935bd94"
[0x7f80ec001c20]:0 <- @sasl-outcome(68) [code=0]
[0x7f80ec001c20]: -> AMQP
[0x7f80ec001c20]:0 -> @open(16) [container-id="send[1]", channel-max=32767]
[0x7f80ec001c20]:RAW:
"\x00\x00\x00"\x02\x00\x00\x00\x00S\x10\xd0\x00\x00\x00\x12\x00\x00\x00\x04\xa1\x07send[1]@@`\x7f\xff"
[0x7f80ec001c20]:0 -> @begin(17) [next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x7f80ec001c20]:RAW:
"\x00\x00\x00"\x02\x00\x00\x00\x00S\x10\xd0\x00\x00\x00\x12\x00\x00\x00\x04\xa1\x07send[1]@"
[0x7f80ec001c20]:0 -> @attach(18) [name="send[1]@1", handle=0, role=false,
snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) [address="",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
target=@target(41) [address="test_exchange", durable=0,
expiry-policy=:"link-detach", timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
[0x7f80ec001c20]:RAW:
"\x00\x00\x00"\x02\x00\x00\x00\x00S\x10\xd0\x00\x00\x00\x12\x00\x00\x00\x04\xa1\x07send[1]@@`\x7f\xff\x00\x00\x00\x1e\x02\x00\x00\x00\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00p\x7f\xff\xff\xffR\x00\x00\x00\x00y\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00i\x00\x00\x00\x0b\xa1\x09send[1]@1R\x00BP\x00P\x00\x00S(\xd0\x00\x00\x00\x18\x00\x00\x00\x05\xa1\x00R\x00\xa3\x0bl"
[0x7f80ec001c20]: <- AMQP
[0x7f80ec001c20]:0 <- @open(16)
[container-id="0f8573b1-318b-4757-93f5-b7d95cbddf9f", channel-max=32767,
offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
properties={:product="qpid-cpp", :version="1.38.0", :platform="Linux",
:host="6349573fc1ec"}]
[0x7f80ec001c20]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=2147483647]
[0x7f80ec001c20]:0 <- @attach(18) [name="send[1]@1", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
timeout=0, dynamic=false], target=@target(41) [address="test_exchange",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x7f80ec001c20]:0 <- @flow(19) [next-incoming-id=0,
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
handle=0, delivery-count=0, link-credit=500, drain=false]
[0x7f80ec001c20]:0 -> @transfer(20) [handle=0, delivery-id=0,
delivery-tag=b"1", message-format=0] (20016)
"\x00SpE\x00SsE\x00Sw\xb0\x00\x00N xxxxxxxxxxxxxxxxxxxxxxxxxxx...
(truncated)
[0x7f80ec001c20]:RAW:
"\x00\x00NM\x02\x00\x00\x00\x00S\x14\xd0\x00\x00\x00\x0d\x00\x00\x00\x04R\x00R\x00\xa0\x011R\x00\x00SpE\x00SsE\x00Sw\xb0\x00\x00N
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...."
I've pasted in everything except the data in the message as I'm sure no one
wants 20k of 'x' in an email.
thanks
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by Gordon Sim <gs...@redhat.com>.
On 19/10/18 13:32, rk wrote:
> Gordon Sim wrote
>> On 19/10/18 12:13, rk wrote:
>>> Using the python client I can send much larger messages than 16k to the
>>> same
>>> broker so it appears to be an issue with the Go bindings.
>>>
>>> The issue can be recreated by editing the example send.go file in the
>>> electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
>>>
>>> I am using version 1.38.0 of qpidd running on Centos 7 and the Go is
>>> bring
>>> compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
>>> library.
>>>
>>> My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
>>> why qpidd thinks it hasn't got the delivery so any help much appreciated.
>>
>>
>> If you can get a protocol trace, that would be helpful. --log-enable
>> trace+:Protocol as an argument to qpidd should do it.
>>
>> For additional commands, e-mail:
>
>> users-help@.apache
>
>
> Protocol output below
>
> 2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
> Sent SASL-MECHANISMS(ANONYMOUS PLAIN) 40
> 2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
> writing protocol header: 1-0
> 2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
> Received SASL-INIT(ANONYMOUS, anonymous@a9ac779f4434, )
> 2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
> Sent SASL-OUTCOME(0) 16
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: -> AMQP
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: <- AMQP
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @open(16)
> [container-id="send[1]", channel-max=32767]
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @begin(17)
> [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @attach(18) [name="send[1]@1",
> handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
> source=@source(40) [address="", durable=0, expiry-policy=:"link-detach",
> timeout=0, dynamic=false], target=@target(41) [address="test_exchange",
> durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
> initial-delivery-count=0, max-message-size=0]
> 2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
> link 0x7f2728001900 attached on 0x7f272801a540
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @open(16)
> [container-id="dd6b88fa-8a0e-4437-9aca-22e4626abddc", channel-max=32767,
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="1.38.0", :platform="Linux",
> :host="af00d45580a7"}]
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @begin(17) [remote-channel=0,
> next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @attach(18) [name="send[1]@1",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="test_exchange", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0, max-message-size=0]
> 2018-10-19 12:27:22 [Protocol] trace
> [qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @flow(19) [next-incoming-id=0,
> incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
> handle=0, delivery-count=0, link-credit=500, drain=false]
Was there no more to that trace? Assuming similar debug logging to what
you originally reported, that would suggest the client is sending an
incomplete frame, e.g. possibly the frame size is wrong.
One more request if you don't mind, could you run with env var
PN_TRACE_RAW=1 and PN_TRACE_FRM=1 on the client side?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by rk <rk...@roke.co.uk>.
Gordon Sim wrote
> On 19/10/18 12:13, rk wrote:
>> Using the python client I can send much larger messages than 16k to the
>> same
>> broker so it appears to be an issue with the Go bindings.
>>
>> The issue can be recreated by editing the example send.go file in the
>> electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
>>
>> I am using version 1.38.0 of qpidd running on Centos 7 and the Go is
>> bring
>> compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
>> library.
>>
>> My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
>> why qpidd thinks it hasn't got the delivery so any help much appreciated.
>
>
> If you can get a protocol trace, that would be helpful. --log-enable
> trace+:Protocol as an argument to qpidd should do it.
>
> For additional commands, e-mail:
> users-help@.apache
Protocol output below
2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
Sent SASL-MECHANISMS(ANONYMOUS PLAIN) 40
2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
writing protocol header: 1-0
2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
Received SASL-INIT(ANONYMOUS, anonymous@a9ac779f4434, )
2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
Sent SASL-OUTCOME(0) 16
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: -> AMQP
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: <- AMQP
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @open(16)
[container-id="send[1]", channel-max=32767]
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @begin(17)
[next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0]
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 <- @attach(18) [name="send[1]@1",
handle=0, role=false, snd-settle-mode=0, rcv-settle-mode=0,
source=@source(40) [address="", durable=0, expiry-policy=:"link-detach",
timeout=0, dynamic=false], target=@target(41) [address="test_exchange",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
2018-10-19 12:27:22 [Protocol] debug qpid.172.18.0.2:5672-172.18.0.4:50426
link 0x7f2728001900 attached on 0x7f272801a540
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @open(16)
[container-id="dd6b88fa-8a0e-4437-9aca-22e4626abddc", channel-max=32767,
offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
properties={:product="qpid-cpp", :version="1.38.0", :platform="Linux",
:host="af00d45580a7"}]
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @begin(17) [remote-channel=0,
next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @attach(18) [name="send[1]@1",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41)
[address="test_exchange", durable=0, timeout=0, dynamic=false],
initial-delivery-count=0, max-message-size=0]
2018-10-19 12:27:22 [Protocol] trace
[qpid.172.18.0.2:5672-172.18.0.4:50426]: 0 -> @flow(19) [next-incoming-id=0,
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
handle=0, delivery-count=0, link-credit=500, drain=false]
It does look like the ActiveMQ issue is probably the same thing. The problem
is not always consistent and sometimes the larger messages will get through.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Go Electron: Large Messages Fail To Send
Posted by Gordon Sim <gs...@redhat.com>.
On 19/10/18 12:13, rk wrote:
> Using the python client I can send much larger messages than 16k to the same
> broker so it appears to be an issue with the Go bindings.
>
> The issue can be recreated by editing the example send.go file in the
> electron repo to look like https://play.golang.org/p/2dQ4jdlKHKi
>
> I am using version 1.38.0 of qpidd running on Centos 7 and the Go is bring
> compiled with the latest electron bindings and 0.24.0-1 qpid-proton-c
> library.
>
> My knowledge of AMQP and the qpidd internals isn't great so I'm unsure of
> why qpidd thinks it hasn't got the delivery so any help much appreciated.
If you can get a protocol trace, that would be helpful. --log-enable
trace+:Protocol as an argument to qpidd should do it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org