yes, pure Go is tempting but the vcabbage development is stopped (there is still some issues ...).
I'm not sure about the future of the fork on Azure: is there active maintainers behind this project ? Le lun. 20 avr. 2020 à 13:04, Robbie Gemmell <[email protected]> a écrit : > 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] > >
