Hello, thx for taking time to answer. I used the examples for experiencing with the protocol. I try different things to understand what happens. For example it seems that even when setting credit to 200, the sender seems to be blocked at 80 messages. I wonder if this limit is "hard-coded" somewhere.
thx for the tip PN_TRACE_FRM. I tried to examine the packets with wireshark, but apparently AMQP 1.0 is not supported. It there another tool that can examine TCP/AMQP communication ? have a good day, jf Le ven. 17 avr. 2020 à 11:43, Robbie Gemmell <[email protected]> a écrit : > On Wed, 15 Apr 2020 at 15:07, mpup371 <[email protected]> wrote: > > > > Hello, I am still experiencing with electron examples codes, and there > is a > > strange behavior that I don't understand. > > Probably I don't understand well the protocol. > > If anyone has an idea ... > > regards, > > jf > > > > sender : > > go build; ./send -debug -count 100 amqp://localhost:5672/topic > > 2020/04/15 15:52:50 Started senders, expect 100 acknowledgements > > ... > > Received all 100 acknowledgements > > > > broker: > > go build; ./broker -debug > > Listening on [::]:5672 > > 2020/04/15 15:52:50 Accepted [0x7f7760000ec0][::1]:5672-[::1]:60138 > > 2020/04/15 15:52:50 incoming connection: (Connection)(0x7f7760000ec0) > > 2020/04/15 15:52:50 incoming session: (Session)(0x7f7758000a50) > > 2020/04/15 15:52:50 incoming receiver-link: send[431]@1(topic<-) > > 2020/04/15 15:52:50 send[431]@1(topic<-): received topic0 > > ..... > > 2020/04/15 15:52:50 incoming closed: > [0x7f7760000ec0][::1]:5672-[::1]:60138 > > 2020/04/15 15:52:50 send[431]@1(topic<-) error: EOF > > > > receiver: > > > > go build; ./receive -debug -count 1 amqp://localhost:5672/topic > > 2020/04/15 15:53:15 Connecting to amqp://localhost:5672/topic > > Listening on 1 connections > > 2020/04/15 15:53:15 topic0 > > Received 1 messages > > 2020/04/15 15:53:15 close [0xa3e220][::1]:60140-[::1]:5672 > > > > *why the receiver hangs after closing the connection ?* > > > > borker : > > 2020/04/15 15:53:15 Accepted [0x1ebfef0][::1]:5672-[::1]:60140 > > 2020/04/15 15:53:15 incoming connection: (Connection)(0x1ebfef0) > > 2020/04/15 15:53:15 incoming session: (Session)(0x7f7758000a50) > > 2020/04/15 15:53:15 incoming sender-link: receive[531]@1(topic->) > > 2020/04/15 15:53:15 receive[531]@1(topic->): sent topic0 > > 2020/04/15 15:53:15 receive[531]@1(topic->): sent topic1 > > 2020/04/15 15:53:15 receive[531]@1(topic->): sent topic2 > > 2020/04/15 15:53:15 incoming closed: [0x1ebfef0][::1]:5672-[::1]:60140 > > 2020/04/15 15:53:15 message topic1 put back, status unacknowledged, error > > EOF > > 2020/04/15 15:53:15 receive[531]@1(topic->) closed: EOF > > > > *the server send 3 messages while the receiver only asked 1, before it > sees > > that the connection is closed. * > > I'm not at all familiar with the Go bits for proton-c, but I dont see > where the broker example would limit what it tries to send based on > the amount of credit actually granted by the receiver. If it doesnt > actually limit based on credit then it perhaps 'sends' things in the > queue and the message is really just buffered for send and doesnt > actually go out unless there is sufficient credit given. Its also > possible the receiver actually gave more credit than the 'count' it > desires and so more were sent by the example broker but not > accepted(/other) by the receiver since it was already done. > > The underlying proton-c bits print protocol trace to stdout if you run > with environment variable PN_TRACE_FRM=1 , you could try enabling that > to better see what it is happening at the protocol level. I'd also > remember that these are simple examples and it isnt a full blown > broker, so unless you are actually trying to write a server with the > bits you may be better off experimenting against something else. > > > > > is there a better way to pop up only x messages from a queue and then > close > > the connection ? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
