hello again, yes PN_TRACE_FRM is very nice to understand what happens.
is there a dedicated list for general discussions about electron, or should I write directly to the author ? thx jf Le ven. 17 avr. 2020 à 13:17, Robbie Gemmell <[email protected]> a écrit : > 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] > >
