[jira] [Commented] (PROTON-919) make C impl behave like java wrt channel_max error
[ https://issues.apache.org/jira/browse/PROTON-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14631403#comment-14631403 ] ASF subversion and git services commented on PROTON-919: Commit 4ee726002804d7286a8c76b42e0a0717e0798822 in qpid-proton's branch refs/heads/master from mgoulish [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4ee7260 ] PROTON-919: make C behave same as Java wrt channel_max error make C impl behave like java wrt channel_max error -- Key: PROTON-919 URL: https://issues.apache.org/jira/browse/PROTON-919 Project: Qpid Proton Issue Type: Improvement Components: proton-c, python-binding Reporter: michael goulish Assignee: michael goulish Priority: Minor In the Java impl, I made TransportImpl throw an exception if the application tries to change the local channel_max setting after we have already sent the OPEN frame to the remote peer. ( Because at that point we communicate our channel_max limit to the peer -- no fair changing it afterwards.) One reviewer suggested that it would be nice if the C impl worked the same way. That would mean that pn_set_channel_max() would have to return a result code, which the Python binding would detect -- Python binding throws exception, python tests detect it -- so it would work same way as Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-919) make C impl behave like java wrt channel_max error
[ https://issues.apache.org/jira/browse/PROTON-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish closed PROTON-919. -- Resolution: Fixed Fix Version/s: 0.10 commit 4ee726002804d7286a8c76b42e0a0717e0798822 please NOTE that this change also adds #define PN_OK (0) to the list of errors in error.h make C impl behave like java wrt channel_max error -- Key: PROTON-919 URL: https://issues.apache.org/jira/browse/PROTON-919 Project: Qpid Proton Issue Type: Improvement Components: proton-c, python-binding Reporter: michael goulish Assignee: michael goulish Priority: Minor Fix For: 0.10 In the Java impl, I made TransportImpl throw an exception if the application tries to change the local channel_max setting after we have already sent the OPEN frame to the remote peer. ( Because at that point we communicate our channel_max limit to the peer -- no fair changing it afterwards.) One reviewer suggested that it would be nice if the C impl worked the same way. That would mean that pn_set_channel_max() would have to return a result code, which the Python binding would detect -- Python binding throws exception, python tests detect it -- so it would work same way as Java. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: FYI: updated C++ tutorial
Looking nice, good job :) (same goes to Gordon as well for the inspiring material :p) Robbie On 14 July 2015 at 23:31, aconway acon...@redhat.com wrote: C++ tutorial is mostly done, if that interests you http://people.apache.org/~aconway/proton/ or check out cjansen-cpp-client.
Re: 0.10 alpha1
FWIW, I'm currently swapping in enough context to confidently +1 PROTON-905, as well as hopefully answer a few related questions on the list. --Rafael On Fri, Jul 17, 2015 at 3:35 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: The are currently 11 unresolved JIRAs assigned a 0.10 fix-for: http://s.apache.org/ytK Of those, 4 are listed as blockers: https://issues.apache.org/jira/browse/PROTON-905 Long-lived connections leak sessions and links https://issues.apache.org/jira/browse/PROTON-923 [SASL] PN_TRANSPORT_ERROR event not raised https://issues.apache.org/jira/browse/PROTON-943 Bump library (.so) major version for proton-c libraries https://issues.apache.org/jira/browse/PROTON-950 SASL PLAIN over cleartext should be supported It would be good if any others JIRAs could be updated to indicate they are considered blockers so we know what is actually remaining, or to move them to either the 0.11 or no fix version if they won't be tackled in 0.10 (which should be most things now; please lets get it out, I'm starting to wish I did 0.9.2 so I can release the JMS client :P ) Robbie On 7 July 2015 at 13:26, Ken Giusti kgiu...@redhat.com wrote: Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K
Re: 0.10 alpha1
I happened to be attempting the same on PROTON-905, though I stopped short of actually hitting 'ship it' given the starting point of my response ;) On 17 July 2015 at 12:44, Rafael Schloming r...@alum.mit.edu wrote: FWIW, I'm currently swapping in enough context to confidently +1 PROTON-905, as well as hopefully answer a few related questions on the list. --Rafael On Fri, Jul 17, 2015 at 3:35 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: The are currently 11 unresolved JIRAs assigned a 0.10 fix-for: http://s.apache.org/ytK Of those, 4 are listed as blockers: https://issues.apache.org/jira/browse/PROTON-905 Long-lived connections leak sessions and links https://issues.apache.org/jira/browse/PROTON-923 [SASL] PN_TRANSPORT_ERROR event not raised https://issues.apache.org/jira/browse/PROTON-943 Bump library (.so) major version for proton-c libraries https://issues.apache.org/jira/browse/PROTON-950 SASL PLAIN over cleartext should be supported It would be good if any others JIRAs could be updated to indicate they are considered blockers so we know what is actually remaining, or to move them to either the 0.11 or no fix version if they won't be tackled in 0.10 (which should be most things now; please lets get it out, I'm starting to wish I did 0.9.2 so I can release the JMS client :P ) Robbie On 7 July 2015 at 13:26, Ken Giusti kgiu...@redhat.com wrote: Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K
[jira] [Updated] (PROTON-876) python examples installed under share are not executable
[ https://issues.apache.org/jira/browse/PROTON-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-876: -- Fix Version/s: (was: 0.10) 0.11 python examples installed under share are not executable Key: PROTON-876 URL: https://issues.apache.org/jira/browse/PROTON-876 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9, 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.11 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-806) closing a blocking sender hangs if connection has been lost
[ https://issues.apache.org/jira/browse/PROTON-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-806. - Resolution: Cannot Reproduce Closing for now; can reopen if it shows up again. closing a blocking sender hangs if connection has been lost --- Key: PROTON-806 URL: https://issues.apache.org/jira/browse/PROTON-806 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]
On Thu, Jul 16, 2015 at 7:46 AM, Gordon Sim g...@redhat.com wrote: On 07/16/2015 02:40 PM, aconway wrote: Can someone who understand the proton use of refcounts please add some doc comments to explain the semantics? Apologies if this is already there and I missed it, tell me to RTFM. I'm not entirely sure I understand it. However having spent a couple of days reading and puzzling over the code, I'll try and offer some answers where I think I can, and add some questions of my own. For comparison here is what refcount traditionally means (tradition includes CORBA, boost::intrusive_ptr, std::shared_ptr etc.) I'm not saying we have to make proton conform, but we should document how it differs to save confusion. 1. A refcount is a count of the number of references (owning pointers) to an object. Yes, that broadly speaking is the purpose in proton. However this was a recent addition and it is not used uniformly inside the library itself. Not only that but the old api, where the application (generally) owned the pointers it created until it called pn_xxx_free, is still supported alongside the newer mode of use, as e.g. employed in the python binding, where the application uses only incref and decref. 2. Objects are created with refcuont=1, the creator owns the first reference. This is not always the case and was one of the points I found surprising. Though a newly created 'object' does indeed have its ref count set to 1, for pn_session() and pn_link(), which are the functions actually used by the application to created new sessions or links, the implementation of those functions includes an explicit decref, meaning the objects are returned with a ref count of 0. Are they really returned with a ref count of 0? I don't think proton objects can actually exist with a refcount of 0 outside a finalizer. What should actually happen is that the finalizer for the newly created session will run and cause the parent of the session or link (the connection or session) to inspect the child's state. Based on that state it may create a new reference to the child, e.g. if there is outstanding work on the wire to be done for that session or link. In the case of a new session or link this is always the case, so it will always end up creating a new reference to it, but this should never result in a child with a non zero refcount being returned or visible in any way to user code. I suspect this was done to simplify things for the newer mode of use, where a wrapper object can always be instantiated and it simply increments the ref count. Would be good to have that confirmed though, as to me this is the source of confusion and complexity. Yes, this is certainly true, but it is also to accommodate the memory model the C interface exposes. In the C interface sessions and links are owned by their parent objects, e.g. freeing the connection frees all the contained sessions. The way this is accommodated is that the parent object is what owns the reference to the child by default. What is returned from the pn_session()/pn_link() calls is a borrowed reference. (This changes when you do an incref, see below for more details.) However this means that in the old mode of use, e.g. pn_session()/pn_session_free(), the object may have a refcount of 0 even though it has not been freed by the application. As mentioned above, this should never be able to happen outside of a finalizer. Perhaps what is confusing here is that the finalizer can create a new reference to the object that is being finalized thereby causing the pn_decref() to *appear* to be a noop, however what is really happening is an important state change, the last reference is being deleted, and the finalizer has decided to create a new reference for other purposes (e.g. because there is outstanding transport work to be done with that object or because it is going into a pool) and the state of the object (or related objects/state) is being changed in key ways to reflect this. Note that this pattern is not at all unique to proton's refcount system. All GC systems that have finalizers accommodate these sorts of semantics, i.e. finalizers causing objects to become live again. This is fundamental to finalizers since they are just user code and can do whatever they want, including create new references. What is confusing about it here is more to do with how this capability is being used to interact with all the engine data structures that predate both the refcount system and the collection objects that make use of the refcount system. I believe ultimately the engine data structures should be reworked to use the various collection objects now available, at which point a lot of this will become much more centralized, self contained, and understandable and likely won't require so much magic (or at least the magic will be in one place rather than spread around like it is now). 3. If another owning reference is created, the refcount
0.9.1 release
Hello all, when i try to download Proton 0.9.1 from https://qpid.apache.org/releases/qpid-proton-0.9.1/index.html the archive i download seems to contain 0.9.1 RC1 instead of the final version. This seems to happen from multiple mirrors. Is it just the wrong directory name or is this the wrong release? Thanks, Alex This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it. Software AG (UK) Limited Registered in England Wales 1310740 - http://www.softwareag.com/uk
Re: 0.9.1 release
Hi Alex, It is the wrong directory name inside the tar file. The 'rc1' bits were voted as the final 0.9.1 release. There was an issue (since corrected) with some release scripting changes made just before the release, and the dirname issue wasn't noticed until after everything was finished and distributed. Given that the first 0.10 release steps were subsequently suggested to be as little as a week or two away it didn't seem worthwhile spinning another release at the time just to correct that. It has unfortunately turned out to be considerably longer. Robbie On 17 July 2015 at 11:46, Kritikos, Alex alex.kriti...@softwareag.com wrote: Hello all, when i try to download Proton 0.9.1 from https://qpid.apache.org/releases/qpid-proton-0.9.1/index.html the archive i download seems to contain 0.9.1 RC1 instead of the final version. This seems to happen from multiple mirrors. Is it just the wrong directory name or is this the wrong release? Thanks, Alex This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it. Software AG (UK) Limited Registered in England Wales 1310740 - http://www.softwareag.com/uk
Re: 0.10 alpha1
The are currently 11 unresolved JIRAs assigned a 0.10 fix-for: http://s.apache.org/ytK Of those, 4 are listed as blockers: https://issues.apache.org/jira/browse/PROTON-905 Long-lived connections leak sessions and links https://issues.apache.org/jira/browse/PROTON-923 [SASL] PN_TRANSPORT_ERROR event not raised https://issues.apache.org/jira/browse/PROTON-943 Bump library (.so) major version for proton-c libraries https://issues.apache.org/jira/browse/PROTON-950 SASL PLAIN over cleartext should be supported It would be good if any others JIRAs could be updated to indicate they are considered blockers so we know what is actually remaining, or to move them to either the 0.11 or no fix version if they won't be tackled in 0.10 (which should be most things now; please lets get it out, I'm starting to wish I did 0.9.2 so I can release the JMS client :P ) Robbie On 7 July 2015 at 13:26, Ken Giusti kgiu...@redhat.com wrote: Yay Rafi! Thanks! A simple query of currently outstanding blocker JIRAs affecting 0.9+ shows only three: https://issues.apache.org/jira/browse/PROTON-826 (unassigned) https://issues.apache.org/jira/browse/PROTON-923 (asticher) https://issues.apache.org/jira/browse/PROTON-934 (rschloming) The remaining open bugs affecting 0.9+ are: https://issues.apache.org/jira/browse/PROTON-826?jql=project%20%3D%20PROTON%20AND%20status%20in%20%28Open%2C%20%22In%20Progress%22%2C%20Reopened%29%20AND%20affectedVersion%20in%20%280.9%2C%200.9.1%2C%200.10%29%20ORDER%20BY%20priority%20DESC - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Tuesday, July 7, 2015 1:28:17 AM Subject: 0.10 alpha1 As promised, here is the first alpha for 0.10. It's posted in the usual places: Source code is here: http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1036 Please check it out and follow up with any issues. --Rafael -- -K
[jira] [Updated] (PROTON-803) Message codec improvements
[ https://issues.apache.org/jira/browse/PROTON-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-803: -- Fix Version/s: (was: 0.9) 0.11 Message codec improvements -- Key: PROTON-803 URL: https://issues.apache.org/jira/browse/PROTON-803 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.8 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.11 This JIRA covers improvements made to the codec, especially lists and maps. The work is based on https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 The above referenced code, is quite an improvement with respect to writing lists, maps and strings over the existing codec. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a sufficiently large set of strings, the old encorder is about ~2 times slower than the new encorder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
tidying up unresolved JIRAs
Hi folks, There are a bunch of unresolved JIRAs assigned with the 0.9 fix-for (http://s.apache.org/VnH). I resolved or updated a few that were obviously complete or not started in 0.9, but there are 17 remaining that need attention from folks involved with the JIRA or who know something about the code involved. Can folks please take a look? Similarly, there are 11 unresolved JIRAs marked fix-for 0.10 (http://s.apache.org/ytK). Some are listed as blockers, more are not. It would be good to tidy them up before the release. The 0.11 fix-for version is already available if needed. Beyond that, there are 241 unresolved JIRAs with no fix-for (http://s.apache.org/fod). If feels like they could do with being given a look over and updated too, as thats just over 1/4 of the JIRAs ever created for Proton. Robbie
[jira] [Resolved] (PROTON-740) idle timeouts repeat and the transport never closes
[ https://issues.apache.org/jira/browse/PROTON-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-740. --- Resolution: Fixed idle timeouts repeat and the transport never closes --- Key: PROTON-740 URL: https://issues.apache.org/jira/browse/PROTON-740 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.9 If an idle timeout occurs during sasl negotiation, various bad things can happen, for example the error keeps repeating, and the transport never closes. There may be other situations where this or similar things can occur. The easiest way to reproduce this is to establish a connection to a server that has been C-Z'ed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-838) proton-hawtdispatch cannot connect with SSL
[ https://issues.apache.org/jira/browse/PROTON-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-838. --- Resolution: Fixed proton-hawtdispatch cannot connect with SSL --- Key: PROTON-838 URL: https://issues.apache.org/jira/browse/PROTON-838 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.5 Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic Fix For: 0.9 AmqpTransport::createTransport() calls transport.connecting() twice. this is harmless for a TcpTransport but asserts for SslTransport -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: proton 0.10 blocker
Hi Gordon, I did my best to dump some useful info on the refcounting stuff in the other thread. I also posted a comment on the review. As I said there it would be helpful to see the stack trace from the crash in order to figure out if the fix is merely a workaround. --Rafael On Wed, Jul 15, 2015 at 9:30 AM, Gordon Sim g...@redhat.com wrote: The latest proton code is causing crashes in qpid-cpp tests that use it. I've tracked the problem down to the fix for PROTON-905[1] and proposed an enhancement to that fix, https://reviews.apache.org/r/36509/, which avoids the crash. Could someone who understands the logic controlling the lifecycle of pn_session_t and pn_link_t objects in detail review and approve this please? [1] https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=653f4e5
Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]
Still digesting the explanation (thanks!) but one follow up question: On 07/17/2015 04:37 PM, Rafael Schloming wrote: it isn't actually possible to use the object when there refcount is 0. What is the purpose of the incref/decref pattern then, e.g. as used in pn_session_free()? That is designed to trigger the finalizer, right? If so it would seem that can only happen if the reference count is 0 at the point when pn_session_free() is called. (And if it was valid to call pn_session_free for a given session, then that session would have been valid for use before that, no?)
Re: proton 0.10 blocker
On 07/17/2015 05:36 PM, Rafael Schloming wrote: Hi Gordon, I did my best to dump some useful info on the refcounting stuff in the other thread. I also posted a comment on the review. As I said there it would be helpful to see the stack trace from the crash in order to figure out if the fix is merely a workaround. Here is one: #0 0x003d54635935 in raise () from /lib64/libc.so.6 #1 0x003d546370e8 in abort () from /lib64/libc.so.6 #2 0x003d5462e6a2 in __assert_fail_base () from /lib64/libc.so.6 #3 0x003d5462e752 in __assert_fail () from /lib64/libc.so.6 #4 0x7fef7d37a761 in pn_class_free (clazz=0x7fef7d5b4ec0, object=0x3692060) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:120 #5 0x7fef7d37aa12 in pn_free (object=optimized out) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:265 #6 0x7fef7d386000 in pni_free_children (children=0x3690510, freed=0x36905e0) at /home/gordon/projects/proton-git/proton-c/src/engine/engine.c:454 #7 0x7fef7d386d09 in pn_session_finalize (object=0x3690180) at /home/gordon/projects/proton-git/proton-c/src/engine/engine.c:932 #8 0x7fef7d37a64d in pn_class_decref (clazz=clazz@entry=0x7fef7d5b4e40, object=object@entry=0x3690180) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:97 #9 0x7fef7d37a70b in pn_class_free (clazz=0x7fef7d5b4e40, object=0x3690180) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:122 #10 0x7fef7d37aa12 in pn_free (object=optimized out) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:265 #11 0x7fef7d386000 in pni_free_children (children=0x368e9c0, freed=0x368ea90) at /home/gordon/projects/proton-git/proton-c/src/engine/engine.c:454 #12 0x7fef7d3866db in pn_connection_finalize (object=0x368e310) at /home/gordon/projects/proton-git/proton-c/src/engine/engine.c:476 #13 0x7fef7d37a64d in pn_class_decref (clazz=0x7fef7d5b4dc0, object=object@entry=0x368e310) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:97 #14 0x7fef7d37a9d2 in pn_decref (object=object@entry=0x368e310) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:255 #15 0x7fef7d38bd08 in pn_transport_unbind (transport=transport@entry=0x36831e0) at /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:733 #16 0x7fef7d38bd88 in pn_transport_finalize (object=0x36831e0) at /home/gordon/projects/proton-git/proton-c/src/transport/transport.c:602 #17 0x7fef7d37a64d in pn_class_decref (clazz=0x7fef7d5b50c0, object=0x36831e0) at /home/gordon/projects/proton-git/proton-c/src/object/object.c:97
Unknown Settle
I'm having an issue with the pn_messenger_settle API that I'd like to see if
you can clear up. We have a loop that uses non-blocking sends to transmit
messages and attempts to settle them when they come back from the server. The
server replies in non-sequential order and when we attempt to settle we get an
PN_STATUS_UNKNOW. The message have been accepted, but it looks like the output
window was shifted beyond the settle transaction prematurely. Here are the
steps as to what is happening:
* The application is sending 20 messages to the server
* We set the outgoing window to 10
* We send message index 0 through 9
* The server sends disposition frames back in this order 1, 5, 9, 2, 9,
6, 7
* We settle the trackers in this order 1, 3, 5, 7, 9
* We then send message index 10 through 14
* The server sends disposition frames for message 0, 4, 8
* Then we settle frame 0 and get an unknown Status
* ...
It seems that if we try to settle any tracker that is
[OutgoingWindowSize-MaxTrackerSent] then we get an PN_STATUS_UNKNOWN. Is there
any way to remedy this situation?
I've attached the proton trace that illustrates this situation.
Thank you for the help,
Jelani Brandon
Starting the EventHub Client Upper Layer SendAsync Sample
(v0.2.0-29-g82e7a5d-dirty)...
Info: Event Hubs Client SDK for C, version v0.2.0-29-g82e7a5d-dirty
[00A27068]: - SASL
[00A27068]:0 - @sasl-init(65) [mechanism=:PLAIN,
initial-response=b\x00SendRule\x00Ir5oZoZVLM4lO8oNLpLbHInsp3saI/BcqZFMpvyXtbE=]
Info: Calling DoWork
[00A27068]: - SASL
[00A27068]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN,
:EXTERNAL]]
[00A27068]:0 - @sasl-outcome(68) [code=0, additional-data=bWelcome!]
[00A27068]: - AMQP
[00A27068]:0 - @open(16) [container-id=0ece6f0d-097d-40e5-a3c0-a59da761f9d3,
hostname=simplesample.servicebus.windows.net]
[00A27068]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=10]
[00A27068]:0 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=1, rcv-settle-mode=0, source=@source(40) [address=ingress,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=ingress,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
Info: Calling DoWork
[00A27068]: - AMQP
[00A27068]:0 - @open(16) [container-id=941562e4078a4da883069f95565bfaed_G18,
max-frame-size=65536, channel-max=4999, idle-time-out=24]
[00A27068]:0 - @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=10, outgoing-window=5000, handle-max=255]
[00A27068]:0 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=1, rcv-settle-mode=0, source=@source(40) [address=ingress,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=ingress,
durable=0, timeout=0, dynamic=false], max-message-size=262144,
properties={:com.microsoft:tracking-id=941562e4078a4da883069f95565bfaed_G18}]
[00A27068]:0 - @flow(19) [next-incoming-id=0, incoming-window=10,
next-outgoing-id=1, outgoing-window=5000, handle=0, delivery-count=0,
link-credit=300, available=0, echo=false]
[00A27068]:0 - @transfer(20) [handle=0, delivery-id=0,
delivery-tag=b\x00\x00\x00\x00\x00\x00\x00\x00, message-format=2147563264,
settled=false, more=false] (179)
\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00V\x00\x00\x00\x0d@@\xa13amqps://simplesample.servicebus.windows.net/ingress@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Su\xa0=\x00Su\xa08{messageId:1001,
name:SendAsync_UpperLayer_Sample}
[00A27068]:0 - @transfer(20) [handle=0, delivery-id=1,
delivery-tag=b\x01\x00\x00\x00\x00\x00\x00\x00, message-format=2147563264,
settled=false, more=false] (179)
\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00V\x00\x00\x00\x0d@@\xa13amqps://simplesample.servicebus.windows.net/ingress@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Su\xa0=\x00Su\xa08{messageId:1002,
name:SendAsync_UpperLayer_Sample}
[00A27068]:0 - @transfer(20) [handle=0, delivery-id=2,
delivery-tag=b\x02\x00\x00\x00\x00\x00\x00\x00, message-format=2147563264,
settled=false, more=false] (179)
\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00V\x00\x00\x00\x0d@@\xa13amqps://simplesample.servicebus.windows.net/ingress@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Su\xa0=\x00Su\xa08{messageId:1003,
name:SendAsync_UpperLayer_Sample}
[00A27068]:0 - @transfer(20) [handle=0, delivery-id=3,
delivery-tag=b\x03\x00\x00\x00\x00\x00\x00\x00, message-format=2147563264,
settled=false, more=false] (179)
Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]
On Fri, Jul 17, 2015 at 10:45 AM, Gordon Sim g...@redhat.com wrote: Still digesting the explanation (thanks!) but one follow up question: On 07/17/2015 04:37 PM, Rafael Schloming wrote: it isn't actually possible to use the object when there refcount is 0. What is the purpose of the incref/decref pattern then, e.g. as used in pn_session_free()? That is designed to trigger the finalizer, right? If so it would seem that can only happen if the reference count is 0 at the point when pn_session_free() is called. (And if it was valid to call pn_session_free for a given session, then that session would have been valid for use before that, no?) The refcount should never be zero going into pn_session_free. The situation where it triggers the finalizer is when the refcount is 1 upon entering pn_session_free, but the referenced boolean is false meaning that the one remaining reference that exists is the parent - child pointer (in this case the connection - session pointer). The incref triggers the pn_session_incref hook which flips the reference around so that the session - connection pointer is now the reference and the connection - session pointer is the borrowed reference. Logically this momentarily increases the refcount from 1 to 2 and then the hook decreases it back to 1 and the decref triggers the finalizer. Now if pn_session_free is called when the refcount is 1, or if pn_ep_decref ends up posting events (events create references to endpoint objects and thereby increase the refcount), then the pn_incref/decref ends up being a noop and the session is simply marked as free but finalized when the last reference to it is decref'ed. --Rafael
[jira] [Closed] (PROTON-864) don't crash when channel number goes high
[ https://issues.apache.org/jira/browse/PROTON-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish closed PROTON-864. -- Resolution: Fixed Fix Version/s: 0.10 This is a duplicate of PROTON-842 don't crash when channel number goes high - Key: PROTON-864 URL: https://issues.apache.org/jira/browse/PROTON-864 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: michael goulish Assignee: michael goulish Fix For: 0.10 Code in transport.c, and a little in engine.c, looks at the topmost bit in channel numbers to decide if the channels are in use. This causes crashes when the number of channels in a single connection goes beyond 32767. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]
On 07/17/2015 08:11 PM, Rafael Schloming wrote: On Fri, Jul 17, 2015 at 10:45 AM, Gordon Sim g...@redhat.com wrote: Still digesting the explanation (thanks!) but one follow up question: On 07/17/2015 04:37 PM, Rafael Schloming wrote: it isn't actually possible to use the object when there refcount is 0. What is the purpose of the incref/decref pattern then, e.g. as used in pn_session_free()? That is designed to trigger the finalizer, right? If so it would seem that can only happen if the reference count is 0 at the point when pn_session_free() is called. (And if it was valid to call pn_session_free for a given session, then that session would have been valid for use before that, no?) The refcount should never be zero going into pn_session_free. The situation where it triggers the finalizer is when the refcount is 1 upon entering pn_session_free, but the referenced boolean is false meaning that the one remaining reference that exists is the parent - child pointer (in this case the connection - session pointer). The incref triggers the pn_session_incref hook which flips the reference around so that the session - connection pointer is now the reference and the connection - session pointer is the borrowed reference. Ah, I see, I'd missed that hook. So the pn_incref(session) call actually increments the reference of the *connection*, not the session in this case. The pn_decref(session) then reduces the refcount of the session from 1 to 0 which triggers the finalizer. Thanks! I'm slowly understanding how it works a little more.
Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]
On 07/17/2015 04:37 PM, Rafael Schloming wrote: Are they really returned with a ref count of 0? No, indeed they are not. I missed the fact that the finalizer will run before the object is returned to the application.
[GitHub] qpid-proton pull request: NO-JIRA: Change travis configuration to ...
Github user astitcher commented on the pull request: https://github.com/apache/qpid-proton/pull/47#issuecomment-122435378 It looks to me that the appveyor failure is due to some incidental issue with the service. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: NO-JIRA: Change travis configuration to ...
GitHub user astitcher opened a pull request: https://github.com/apache/qpid-proton/pull/47 NO-JIRA: Change travis configuration to use container based builds This is specifically for comment from @dnwe - I'm proposing to change the travis build config to use containers, but I've stopped using the existng jenkins build script. This does make the travis CI builds start almost immediately for me, so is a big win in my experience. You can merge this pull request into a Git repository by running: $ git pull https://github.com/astitcher/qpid-proton travis-container Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/47.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #47 commit 4476e97527f4a3b6ae8e85f0bd82cb660270eb16 Author: Andrew Stitcher astitc...@apache.org Date: 2015-07-09T20:43:20Z NO-JIRA: Change travis configuration to use container based builds --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: NO-JIRA: Change travis configuration to ...
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/47#issuecomment-122437243 Ok. :+1. Ship it! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: NO-JIRA: Change travis configuration to ...
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/47#issuecomment-122435936 Changes look reasonable to me. Faster sudoless docker builds would be cool. You dropped the PYTHON_DIRS bit which was for tox to locate the various Python interps. With the new format do we still get coverage on all the pythons? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: NO-JIRA: Change travis configuration to ...
Github user astitcher commented on the pull request: https://github.com/apache/qpid-proton/pull/47#issuecomment-122436754 The tox thing is the bit I'm shakiest about - it seems to find 3 out of the 4 pythons (not 2.6 I think) for some reason. I experimented with a matrix test which also builds under python 3.4 and think that would be a better way to cover multiple pythons using travis. However proton didn't build with python 3.4 like that! On Fri, Jul 17, 2015, at 06:29 PM, Dominic Evans wrote: Changes look reasonable to me. Faster sudoless docker builds would be cool. You dropped the PYTHON_DIRS bit which was for tox to locate the various Python interps. With the new format do we still get coverage on all the pythons? â Reply to this email directly or view it on GitHub[1]. Andrew Links: 1. https://github.com/apache/qpid-proton/pull/47#issuecomment-122435936 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
