Re: How to observe connection loss via the messenger API
There isn't currently a way to get any notification of connection loss per/se. You might be able to accomplish what you want by checking the status of the incoming message transfers. What is it you would do based on the notification? --Rafael On Sun, Feb 17, 2013 at 6:43 PM, Bozo Dragojevic bo...@digiverse.si wrote: If I kill send.c while it's sending the messages then recv output might look like this: $ ./recv . 1361144306.723531 Address: amqp://0.0.0.0 Subject: Greetings from send 24136 Content: Hello World! ### engine.c:1395 pn_do_error ERROR ### transport-5 ERROR amqp:connection:framing-error connection aborted [0x192a910:0] ERROR[-2] connection aborted CONNECTION ERROR connection aborted So proton internally does detect connection error. Is there a way to get these notifications via pn_messenger_* ? thanks, Bozzo
[jira] [Updated] (PROTON-225) Redesign Transport interface such that Transport owns the in/out buffers rather than its client
[ https://issues.apache.org/jira/browse/PROTON-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-225: - Description: This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. was:This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. Redesign Transport interface such that Transport owns the in/out buffers rather than its client --- Key: PROTON-225 URL: https://issues.apache.org/jira/browse/PROTON-225 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.3 Reporter: Philip Harvey Assignee: Ken Giusti Fix For: 0.5 This issue is intended to cover the Transport API redesign proposed on the mailing list (http://qpid.2158936.n2.nabble.com/transport-interface-changes-td7588099.html) as part of discussions around PROTON-222. The redesign is being tracked under this new because we probably want to implement it on a different timescale to the PROTON-222 bug fix. When refactoring the Java implementation, we should consider if the point when the sent/received protocol logging is done should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: the killer node
This just in. It's a linking issue. When I changed my two fn names from send() to my_send() and from recv() to my_recv() ... no more problem. Different behavior on Fedora 17 and Fedora 18. Gulp. I will post more if I learn something useful. - Original Message - From: Michael Goulish mgoul...@redhat.com To: proton@qpid.apache.org Sent: Tuesday, February 19, 2013 7:40:16 AM Subject: the killer node Well, it looks like one of my nodes can kill the other one by doing a put. No errors reported by either messenger before the fatality. I'd like to see if someone else can confirm this result, and maybe see something that I am not seeing. compile and run scripts are provided in the directory, called node. I am testing this against unpatched 0.4 RC1 code. ( But result was same with Ken's recent patch for infinite credit. ) 1. Two instances of one program are used. Node A only receives, Node B only sends to it. 2. Start node A first, with the script r1. It will go through its main loop, trying to receive and timing out, for as long as you like. 3. Start node B, with script r2. It will pause after formatting it first message, and will then do a dramatic 5-second countdown. Then it calls put ( not send! ) and node *A* dies horribly, its core file spattering the hard disk. Node B is unaware of the carnage it has caused, sedated by a sleep loop, tragically still expecting to call send and start talking to its partner, node A. ( see attached -- if you dare. )
Re: the killer node
Doh! You had me scared there for a while. --Rafael On Tue, Feb 19, 2013 at 8:43 AM, Michael Goulish mgoul...@redhat.comwrote: This just in. It's a linking issue. When I changed my two fn names from send() to my_send() and from recv() to my_recv() ... no more problem. Different behavior on Fedora 17 and Fedora 18. Gulp. I will post more if I learn something useful. - Original Message - From: Michael Goulish mgoul...@redhat.com To: proton@qpid.apache.org Sent: Tuesday, February 19, 2013 7:40:16 AM Subject: the killer node Well, it looks like one of my nodes can kill the other one by doing a put. No errors reported by either messenger before the fatality. I'd like to see if someone else can confirm this result, and maybe see something that I am not seeing. compile and run scripts are provided in the directory, called node. I am testing this against unpatched 0.4 RC1 code. ( But result was same with Ken's recent patch for infinite credit. ) 1. Two instances of one program are used. Node A only receives, Node B only sends to it. 2. Start node A first, with the script r1. It will go through its main loop, trying to receive and timing out, for as long as you like. 3. Start node B, with script r2. It will pause after formatting it first message, and will then do a dramatic 5-second countdown. Then it calls put ( not send! ) and node *A* dies horribly, its core file spattering the hard disk. Node B is unaware of the carnage it has caused, sedated by a sleep loop, tragically still expecting to call send and start talking to its partner, node A. ( see attached -- if you dare. )
Re: the killer node
Oh it has to work then testing ... and it does. But I do get this unusual compiler warning: warning: ISO C90 forbids fools and madmen to program in this language. Go learn Haskell and leave me alone. huh. - Original Message - From: Darryl L. Pierce dpie...@redhat.com To: proton@qpid.apache.org Sent: Tuesday, February 19, 2013 1:37:19 PM Subject: Re: the killer node On Tue, Feb 19, 2013 at 11:43:52AM -0500, Michael Goulish wrote: This just in. It's a linking issue. When I changed my two fn names from send() to my_send() and from recv() to my_recv() ... no more problem. Different behavior on Fedora 17 and Fedora 18. Gulp. I will post more if I learn something useful. Just for grins, what happens if you set the name back and make it static? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
[jira] [Assigned] (PROTON-232) described arrays seem to force the descriptor to be of the same type as the array
[ https://issues.apache.org/jira/browse/PROTON-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned PROTON-232: -- Assignee: Alan Conway (was: Rafael H. Schloming) described arrays seem to force the descriptor to be of the same type as the array - Key: PROTON-232 URL: https://issues.apache.org/jira/browse/PROTON-232 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Alan Conway -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
