This is the discussion list to use. The person who wrote the Go bits is subscribed, but is involved more on other bits these days.
Given the limited traction around the Go bindings currently, you may be better trying e.g. https://github.com/Azure/go-amqp (originally from https://github.com/vcabbage/amqp) which has the benefit of also being pure Go rather than relying on another C component. Robbie On Mon, 20 Apr 2020 at 10:54, mpup371 <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
