On Fri, 17 Apr 2020 at 11:15, mpup371 <[email protected]> wrote: > > 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.
Not that I know/saw, but again im not familiar with the Go bits. > > 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 ? > Wireshark got AMQP 1.0 support several years ago (though I havent used it some time personally, as many things dont need that level of inspection, just the PN_TRACE_FRM protocol trace tends to be enough). https://github.com/ChugR/Adverb is a tool one of the committers, Chuck, wrote to turn protocol captures into a web page for inspection. It actually uses tshark from wireshark. Qpid Dispatch router has a scraper tool Chuck also wrote for analysing the protocol trace from its log output: https://github.com/apache/qpid-dispatch/tree/1.11.0/tools/scraper > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
