[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591650#comment-14591650 ] Rafael H. Schloming commented on PROTON-915: FWIW, the intent of the spec was to allow both the client *and* the server to send things after the header. Obviously for the server this is only feasible if it only speaks one version, but it is allowed by the spec and should be handled by clients. Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9, 0.9.1 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Blocker Fix For: 0.10 Attachments: 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-882) it should be possible to override logging from python
[ https://issues.apache.org/jira/browse/PROTON-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-882. Resolution: Fixed it should be possible to override logging from python - Key: PROTON-882 URL: https://issues.apache.org/jira/browse/PROTON-882 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-882) it should be possible to override logging from python
Rafael H. Schloming created PROTON-882: -- Summary: it should be possible to override logging from python Key: PROTON-882 URL: https://issues.apache.org/jira/browse/PROTON-882 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-879) null initial response makes cyrus challenge when it probably shouldn't
[ https://issues.apache.org/jira/browse/PROTON-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-879: --- Attachment: initial-response.patch null initial response makes cyrus challenge when it probably shouldn't -- Key: PROTON-879 URL: https://issues.apache.org/jira/browse/PROTON-879 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 Attachments: initial-response.patch See attached fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-877) proton-c sasl client hangs on server pipeline
[ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-877: --- Attachment: pipeline-workaround.patch This patch works around both the fact that java doesn't autodetect sasl vs pure amqp, as well as the fact that proton-c's sasl doesn't deal with server pipeline. proton-c sasl client hangs on server pipeline - Key: PROTON-877 URL: https://issues.apache.org/jira/browse/PROTON-877 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 Attachments: pipeline-workaround.patch, tests.patch [rhs@localhost build]$ ~/proton/examples/python/reactor/send.py [0x1d350c0]: - SASL [0x1d350c0]: - SASL [0x1d350c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x1d350c0]:0 - @sasl-outcome(68) [code=0] [0x1d350c0]: - AMQP [0x1d350c0]:0 - @open(16) [container-id=, hostname=localhost] [0x1d350c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x1d350c0]:0 - @attach(18) [name=sender, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x1d350c0]: - AMQP ^CTraceback (most recent call last): File /home/rhs/proton/examples/python/reactor/send.py, line 90, in module r.run() File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 120, in run while self.process(): pass File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 142, in process result = pn_reactor_process(self._impl) KeyboardInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-879) null initial response makes cyrus challenge when it probably shouldn't
Rafael H. Schloming created PROTON-879:
--
Summary: null initial response makes cyrus challenge when it
probably shouldn't
Key: PROTON-879
URL: https://issues.apache.org/jira/browse/PROTON-879
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Rafael H. Schloming
Assignee: Andrew Stitcher
Fix For: 0.10
diff --git a/proton-c/src/sasl/cyrus_sasl.c b/proton-c/src/sasl/cyrus_sasl.c
index 58d6c9b..a990d61 100644
--- a/proton-c/src/sasl/cyrus_sasl.c
+++ b/proton-c/src/sasl/cyrus_sasl.c
@@ -738,6 +738,7 @@ int pn_do_init(pn_transport_t *transport, uint8_t
frame_type, uint16_
int err = pn_data_scan(args, D.[sz], mech, recv);
if (err) return err;
sasl-selected_mechanism = pn_strndup(mech.start, mech.size);
+ if (!recv.start) { recv.start = ; }
pni_process_init(transport, sasl-selected_mechanism, recv);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-879) null initial response makes cyrus challenge when it probably shouldn't
[
https://issues.apache.org/jira/browse/PROTON-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-879:
---
Description:
See attached fix.
was:
diff --git a/proton-c/src/sasl/cyrus_sasl.c b/proton-c/src/sasl/cyrus_sasl.c
index 58d6c9b..a990d61 100644
--- a/proton-c/src/sasl/cyrus_sasl.c
+++ b/proton-c/src/sasl/cyrus_sasl.c
@@ -738,6 +738,7 @@ int pn_do_init(pn_transport_t *transport, uint8_t
frame_type, uint16_
int err = pn_data_scan(args, D.[sz], mech, recv);
if (err) return err;
sasl-selected_mechanism = pn_strndup(mech.start, mech.size);
+ if (!recv.start) { recv.start = ; }
pni_process_init(transport, sasl-selected_mechanism, recv);
null initial response makes cyrus challenge when it probably shouldn't
--
Key: PROTON-879
URL: https://issues.apache.org/jira/browse/PROTON-879
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Rafael H. Schloming
Assignee: Andrew Stitcher
Fix For: 0.10
See attached fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-877) proton-c sasl client hangs on server pipeline
Rafael H. Schloming created PROTON-877: -- Summary: proton-c sasl client hangs on server pipeline Key: PROTON-877 URL: https://issues.apache.org/jira/browse/PROTON-877 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 [rhs@localhost build]$ ~/proton/examples/python/reactor/send.py [0x1d350c0]: - SASL [0x1d350c0]: - SASL [0x1d350c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x1d350c0]:0 - @sasl-outcome(68) [code=0] [0x1d350c0]: - AMQP [0x1d350c0]:0 - @open(16) [container-id=, hostname=localhost] [0x1d350c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x1d350c0]:0 - @attach(18) [name=sender, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x1d350c0]: - AMQP ^CTraceback (most recent call last): File /home/rhs/proton/examples/python/reactor/send.py, line 90, in module r.run() File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 120, in run while self.process(): pass File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 142, in process result = pn_reactor_process(self._impl) KeyboardInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-877) proton-c sasl client hangs on server pipeline
[ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-877: --- Attachment: tests.patch Here are some tests illustrating various issues with this scenario. proton-c sasl client hangs on server pipeline - Key: PROTON-877 URL: https://issues.apache.org/jira/browse/PROTON-877 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 Attachments: tests.patch [rhs@localhost build]$ ~/proton/examples/python/reactor/send.py [0x1d350c0]: - SASL [0x1d350c0]: - SASL [0x1d350c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x1d350c0]:0 - @sasl-outcome(68) [code=0] [0x1d350c0]: - AMQP [0x1d350c0]:0 - @open(16) [container-id=, hostname=localhost] [0x1d350c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x1d350c0]:0 - @attach(18) [name=sender, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x1d350c0]: - AMQP ^CTraceback (most recent call last): File /home/rhs/proton/examples/python/reactor/send.py, line 90, in module r.run() File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 120, in run while self.process(): pass File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 142, in process result = pn_reactor_process(self._impl) KeyboardInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-874) PN_VERSION only supports major and minor versions
[ https://issues.apache.org/jira/browse/PROTON-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-874. Resolution: Fixed Fix Version/s: 0.10 PN_VERSION only supports major and minor versions - Key: PROTON-874 URL: https://issues.apache.org/jira/browse/PROTON-874 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Robbie Gemmell Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.10 The cmake build reads in PN_VERSION from the version file, but it only supports major and minor versions. It seems to be used in the file name for the cmake-built jar, and within code to make the version available to C/Python code. This should be updated to support micro/patch version info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-790) Use git tag for release (rather than branch)
[ https://issues.apache.org/jira/browse/PROTON-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-790. Resolution: Fixed Use git tag for release (rather than branch) Key: PROTON-790 URL: https://issues.apache.org/jira/browse/PROTON-790 Project: Qpid Proton Issue Type: Improvement Components: release Affects Versions: 0.9 Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor I think it would make sense to use git tags to indicate the versions of releases including alphas and betas. So instead of having branch with a single change on it we should use a tag to indicate a release. This would also allow the branching structure and the releases to be independent. As an example the recent 0.9-alpha-1 could be a tag on a 0.9-release branch. Or it could just be a tag on a one change branch (to change the version). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-790) Use git tag for release (rather than branch)
[ https://issues.apache.org/jira/browse/PROTON-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-790: --- Fix Version/s: 0.9 Use git tag for release (rather than branch) Key: PROTON-790 URL: https://issues.apache.org/jira/browse/PROTON-790 Project: Qpid Proton Issue Type: Improvement Components: release Affects Versions: 0.9 Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.9 I think it would make sense to use git tags to indicate the versions of releases including alphas and betas. So instead of having branch with a single change on it we should use a tag to indicate a release. This would also allow the branching structure and the releases to be independent. As an example the recent 0.9-alpha-1 could be a tag on a 0.9-release branch. Or it could just be a tag on a one change branch (to change the version). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-858: --- Fix Version/s: 0.9.1 unbalanced maps can get corrupted - Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical Fix For: 0.9.1 I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-862) Proton using Cyrus SASL library is problematic because the library has global state
[ https://issues.apache.org/jira/browse/PROTON-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511864#comment-14511864 ] Rafael H. Schloming commented on PROTON-862: It strikes me that we could probably structure things such that the initialization problem is punted to the application. For example, we could by default use the same fallback code that is currently used when cyrus is not available. We can then provide an API for the application to tell us to start using cyrus instead of the fallback. This way the application can do the cyrus initialization however it chooses and then if/when the application has initialized cyrus, it can tell us to start using it. Proton using Cyrus SASL library is problematic because the library has global state --- Key: PROTON-862 URL: https://issues.apache.org/jira/browse/PROTON-862 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher The Cyrus SASL library is not 100% suitable for use in other libraries because it has global state and needs to be globally initialised before use as either a SASL client or SASL server. One requirement for this global initialisation seems to be to load the mechanism plugins. This global state is problematic because we cannot dictate what the linked in application and other libraries may do with Cyrus SASL themselves. In particular we currently use the sasl_server_init() call to set the basename for the config file that is used for the SASL settings. It is possible to work around this by passing in NULL instead of a name and so not changing whatever the application may have set. However we will then need to set the Cyrus SASL options manually by implementing the SASL_CB_GETOPT callback which returns the options set in the config file, so that we don't need Cyrus to do it for us. Even so we would still have to be setting the global callbacks to NULL in our initialisation, as there is no way to make Cyrus ignore the global callback initialisation - this implies that for correct interop no library (and probably no application either) can ever set these global callbacks, as they will have no way to ensure that some random library loaded in doesn't reset them! Another (perhaps better) alternative would be to port Proton to use another SASL library, which better respects being used in a library and has no global state. A good example of this would be libgsasl. However its API is significantly more complex to use, largely because it doesn't do the user authentication part itself and requires the application or dependant library to do it. So at this point this route would involve significant extra work, although might be long term more maintainable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-829) Possible reference counting bug in pn_clear_tpwork
[
https://issues.apache.org/jira/browse/PROTON-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338658#comment-14338658
]
Rafael H. Schloming commented on PROTON-829:
What really motivates the current scheme is not the pooling, but the need to
avoid circular references. The object graph simply has circular references and
there is no reasonable way to avoid this in the current design, yet all these
objects need to be wrappable into python, which means you need to be able to
present an incref/decref style memory management interface. As far as I can
tell, that pretty much demands that you have a hybrid refcount/incremental gc
scheme of some sort. I fully agree that pn_incref(...)/pn_decref(...) is an
incredibly obscure way to trigger an incremental garbage collect though and the
code needs to be better factored to make the design more transparent.
Possible reference counting bug in pn_clear_tpwork
--
Key: PROTON-829
URL: https://issues.apache.org/jira/browse/PROTON-829
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: 0.9
See QPID-6415 which describes a core dump in the qpid tests that appears when
using the current 0.9 proton master. The qpid tests pass OK with proton 0.8.
The valgrind output in QPID-6415 shows that a connection is deleted while it
is being finalized by a call from pn_connection_unbound to pn_clear_tpwork.
I do not yet understand the details, but removing the following strange code
fixes the problem and passes the proton test suite without valgrind errors:
{noformat}
--- a/proton-c/src/engine/engine.c
+++ b/proton-c/src/engine/engine.c
@@ -690,10 +690,10 @@ void pn_clear_tpwork(pn_delivery_t *delivery)
{
LL_REMOVE(connection, tpwork, delivery);
delivery-tpwork = false;
-if (pn_refcount(delivery) 0) {
- pn_incref(delivery);
- pn_decref(delivery);
-}
}
}
{noformat}
The code is strange because
a) you should never examine a refcount except for debugging purposes
b) under normal refcounting semantics incref+decref is a no-op.
Is removing this code OK?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-829) Possible reference counting bug in pn_clear_tpwork
[ https://issues.apache.org/jira/browse/PROTON-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14338377#comment-14338377 ] Rafael H. Schloming commented on PROTON-829: I added that code to get the python tests to pass without valgrind errors, so I'm surprised that removing it doesn't cause issues. I'll try to explain a little bit about what's going on. (I've commented this elsewhere in the code, but I missed this spot. I think andrew pointed out that this might be clearer with a helper function instead of/in addition to a comment.) There are definitely non-debug cases where it is useful to examine the refcount. In particular, a finalizer gets fired when the refcount hits zero, but the finalizer can sometimes run code that creates a new reference to the object that is being finalized. There are a few places where this pattern is very useful: - The finalizer can run some logic that decides whether or not the object should be pooled and if so sticking it in the pool adds a reference. - The finalizer might run some code that posts an event, thereby creating a reference from the collector to the object. - The connection/session/link/delivery/transport objects all have pointers to each other, and to just naively refcount all those pointers would result in circular references and memory leaks. In order to avoid circular references, we don't refcount internal pointers, e.g. the parent-child pointers, instead the finalizers of all the children have logic that runs and figures out if it is safe for the child to go away (basically does a tiny amount of incremental garbage collection). If the finalizer's garbage collection finds an internal reference, the parent of that object takes over the last external reference. In the latter case an external pointer to a child may be created again, and to account for this, the incref of all the child objects is overriden to remove the reference that the parent took over. In all these cases, the logic that may/may not create a new reference is run at the beginning of the finalizer. The finalizer then needs to check if a new reference has actually been created in order to figure out whether or not to actually free the resources used by the object or to return. This pattern could perhaps be formalized by distinguishing between finalizers (the part that runs application logic which can create new references) and destructors (the part that actually frees anything malloced in the initializer) in the object code. This should also explain why incref/decref is not necessarily a noop, it is basically retriggering the gc portion of the code in the finalizer that decides whether or not an object should really go away or not, and in the rare case that you toggle some state that might influence that gc logic, you need to get it to run again. Clearing the tp work queue is one such case. The reason it is guarded by a check on the refcount is that we also call that function from inside the delivery finalizer, and in that case if the refcount is zero we've already decided that the object should go away. Again, this gc part of the pattern could probably be formalized a bit, e.g. possibly having some sort of mark/sweep style thing that is in fact triggered by external references reaching zero, but probably not a good idea to attempt anytime soon since what complicates this picture is not so much the fact that it isn't formalized, but rather that the engine uses ad-hoc data structures that predate the development of the collections that are part of the object library and therefore has to manually account and search for references in a type specific way rather than using the automatic ref counting and/or search routines available in the collections. This manual/type specific accounting is what makes the gc logic a bit brittle, and could possibly be the source of the bug you are seeing. At some point relatively soon (probably after 0.9 but before the next release) I expect to have to update a significant chunk of those data structures to properly use the collections, but until then if you manage to pare this down to a minimal reproducer in terms of proton API calls, that would definitely suggest the bug is in proton and I can probably help debug more from there. As it is, it looks like it could possibly just be a plain old double free style bug in messaging, and removing the above code just masks it by introducing a memory leak. Possible reference counting bug in pn_clear_tpwork -- Key: PROTON-829 URL: https://issues.apache.org/jira/browse/PROTON-829 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9
[jira] [Commented] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition
[
https://issues.apache.org/jira/browse/PROTON-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14330136#comment-14330136
]
Rafael H. Schloming commented on PROTON-824:
PN_TRACE_FRM will log to stderr by default. Python's print statements are going
to stdout. You can send the print statements to stderr and see if that helps.
Windows fails testIdleTimeout with assert p.conn.remote_condition
-
Key: PROTON-824
URL: https://issues.apache.org/jira/browse/PROTON-824
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Environment: Windows Server 2008 or 2012
Visual studio 2010, x86
Reporter: Chuck Rolke
{noformat}
1: proton_tests.engine.ServerTest.testIdleTimeout .
fail
1: Error during test: Traceback (most recent call last):
1: File D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py,
line 1919 (or so), in testIdleTimeout
1: assert p.conn.remote_condition
1: AssertionError
{noformat}
Playing with Program explicit timeout (trying 10 instead of 3) gets the test
to pass sometimes. It passes sometimes with 3 as well but normally fails.
In debugging this it looks like there as no synchronization between what a
test will show through print statements and what the proton library shows
through PN_TRACE_FRM statements. Are there any hints to lining these up?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318826#comment-14318826 ] Rafael H. Schloming commented on PROTON-808: I found a more comprehensible link about cmake and RPATH here: http://www.cmake.org/Wiki/CMake_RPATH_handling I'm not quite sure what the right thing to do is. Based on the cmake documentation, I don't think the stack overflow suggestion will actually fix the problem since it controls the RPATH for stuff in the build tree which is not the same as the RPATH for stuff that is actually installed. Note that the stack overflow question is actually about how to be able to run stuff out of the *build* tree without using LD_LIBRARY_PATH. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318675#comment-14318675 ] Rafael H. Schloming commented on PROTON-804: Ok, I take your point about the tests being clear. In the future when I modify them I'll endeavor to clarify which assertions are implementation specific and which aren't. In this case I don't know that I see the need for the implementation to change all that much so II'd probably personally test for the exact behavior but comment it as implementation-specific, however I'm not particularly fussed if you prefer to leave the test more open than that. the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: 0001-This-may-be-a-fix-for-PROTON-804-on-error-in-server-.patch, transport-test.patch I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318876#comment-14318876 ] Rafael H. Schloming commented on PROTON-808: I didn't mean to suggest BUILD_WITH_INSTALL_RPATH is wrong in a philosophical sense, I was just questioning whether it would actually fix the issue. I haven't tried it, but this is what the cmake docs say: BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link the target in the build tree with the INSTALL_RPATH. This takes precedence over SKIP_BUILD_RPATH and avoids the need for relinking before installation. My interpretation of that is that it wouldn't have any impact on the RPATH of the binaries once installed, but will instead make the binaries in the build tree identical to those that get installed. There seem to be a bunch of other options that control the RPATH of installed binaries. The link I posted has a section called Always full RPATH which describes a set of cmake options that may solve the issue. I don't know much about the security implications, but my bias would be to make it just work if possible. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14319151#comment-14319151 ] Rafael H. Schloming commented on PROTON-808: On the good idea topic, what are the security issues associated with this stuff? I'm aware that using LD_LIBRARY_PATH has risks, but I don't know how setting rpaths can lead to issues. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross Attachments: cmake.patch 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-808: --- Attachment: cmake.patch Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross Attachments: cmake.patch 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318927#comment-14318927 ] Rafael H. Schloming commented on PROTON-808: I just tried it and it doesn't seem to work. What makes you think it will have any impact on the installed RPATH at all? Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14319010#comment-14319010 ] Rafael H. Schloming commented on PROTON-808: Ok, I'm kinda at my wits end on this one. Everything I've read would suggest that SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) should fix the problem, however no matter what I try cmake always strips the path out of the installed binaries. I even tried with the latest version of cmake, and it's the same story. The only thing I've found that puts in any kind of rpath is to explicitly set CMAKE_INSTALL_RPATH. This results in objdump showing that an RPATH is set, but I still get the same loading error. I'm gonna give up on this for now as I'm getting nowhere with it. If anyone else wants to try, I'd appreciate the help. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[ https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14319223#comment-14319223 ] Rafael H. Schloming commented on PROTON-808: I was just observing that it would be unlikely for there to be an exploit if you just run make install and then don't mess with the resulting tree. As you point out though, if you copy stuff around, there is still the potential for an exploit. If we don't want to change what the build does by default, we could just document the appropriate options for the user to configure the RPATH manually, although I suppose that would constitute giving people insecure advice. If we do go that route there is kind of an annoying gotcha with the whole lib vs lib64 thing. Binaries have their library locations stripped -- Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross Attachments: cmake.patch 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14318611#comment-14318611 ] Rafael H. Schloming commented on PROTON-804: I checked the fix and it does indeed avoid the busy loop. Regarding your comments on the test, it does assume an implementation behavior, but I'm not sure why that is a problem. It's not a general purpose interop test, it only ever runs (or could possibly be run) against either the proton-c or proton-j implementation. If what you're saying is that you want to choose a different behavior, that's fine, but I would still expect that we test for whatever we decide the appropriate choice is, i.e. modify the test to check that the server sends back EOS immediately instead of sending back an error. the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: 0001-This-may-be-a-fix-for-PROTON-804-on-error-in-server-.patch, transport-test.patch I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-811. Resolution: Fixed Fix Version/s: 0.9 [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Fix For: 0.9 Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout-mk3.patch, 0001-proton-j-updates-for-idle-timeout-mk4.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301326#comment-14301326 ] Rafael H. Schloming commented on PROTON-811: Hi Adrian, Thanks for reworking this. I tried applying this and ran into a few more issues. Minor nitpick, I noticed after applying the patch that git diff shows up extra whitespace in the files. We try not to have extraneous whitespace. Your editor probably has a setting that will clean that sort of thing up for you automatically. It might be worth looking into. Beyond that, I had some trouble compiling. I think maybe your java version is newer, because my compiler barfed on the diamond operator () used in the tests. I fixed that easily enough, but then there were a bunch of missing imports. I'm not sure how this worked for you unless maybe you're compiling against an older/alternate version of the code? Once I added the missing imports, I noticed a few failures in the jython test suite. FYI, there are a number of tests written in python that get run against both the proton-c and proton-j implementations. These tests help us keep things consistent between the two and give us better/shared coverage. There are a set of shims in proton-j/src/main/resources that adapt between the Java and C APIs. There's actually already test coverage for idle timeouts in the python test suite, those tests currently just skip for the Java impl because those parts of the shim raise the Skipped() exception. I attempted to enable those pieces of the shim to give some better coverage, however this showed up a difference in the APIs. The C API stores the idle timeout on the transport object, whereas you have it in the Connection object. If we could resolve this difference then it would be pretty straightforward to enable the portion of the shim that deals with idle timeouts and get added test coverage from the python test suite. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout-mk3.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298501#comment-14298501 ] Rafael H. Schloming commented on PROTON-811: Looks good! One further tweak possibly worth considering... in the C version of this, the tick method doesn't compute the current time itself, but rather is passed the current time by the caller. The idea there being that a) the embedding code might have multiple clock APIs to choose from, and b) if the embedding code is servicing multiple transports, it can access the time once, and pass it into all of them rather than accessing the clock each time. I think (a) is not much of a factor given this is Java, but I wonder if it may still make sense for (b). What do you think? Also, this is a bit arbitrary, but the Java tick is returning a timeout, whereas the same version in C returns an absolute value (a deadline). Given the methods are named exactly the same thing, it might be worth being consistent with the design here assumig it's just an arbitrary choice. Do you think there's an advantage to returning a timeout over an absolute value? (If there is, I'd say keep it as is.) [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch, 0001-proton-j-updates-for-idle-timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-811) [PATCH] proton-j: no way to implement idle timeout of a connection
[ https://issues.apache.org/jira/browse/PROTON-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14297430#comment-14297430 ] Rafael H. Schloming commented on PROTON-811: Hi Adrian, thanks for the patch. One comment on the approach... rather than directly exposing a call to write an empty frame, it would be better to add a general purpose interface to the transport for timer integration, e.g. have a Transport.deadline() or Transport.timeout() that returns a time in the future that the transport needs to be called, and then have a Transport.tick() or Transport.expired() that is invoked at that point. This is because there are actually other timing related things required by the spec, not just sending empty frames. Also it isn't always necessary to send an empty frame if other activity has happened, so providing a slightly more abstract interface and letting the Transport implementation decide when it needs to do something and what exactly it needs to do would be preferred. [PATCH] proton-j: no way to implement idle timeout of a connection -- Key: PROTON-811 URL: https://issues.apache.org/jira/browse/PROTON-811 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Adrian Preston Attachments: 0001-idle_timeout.patch Proton-J does not provide access to idle timeout values and there appears to be no way to send a empty frame (as per section 2.4.5 of the AMQP 1.0 standard) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-802.
Resolution: Fixed
Unicode strings passed in through python binding cause exceptions
-
Key: PROTON-802
URL: https://issues.apache.org/jira/browse/PROTON-802
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.9
Environment: Ubuntu 14.04.1 64-bit
Reporter: Ken Leidal
Priority: Minor
Labels: encoding, string
The following traceback was thrown when passing in a python unicode string
for a host name. Ensuring the string is a python binary string (UTF-8) is a
work around.
{code:title=Traceback|borderStyle=solid}
Traceback (most recent call last):
File ./arc, line 246, in module
curses.wrapper(main)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File ./arc, line 244, in main
drv.run()
File /home/kkleidal/datawire/server/common.py, line 270, in run
self.process_events()
File /home/kkleidal/datawire/server/common.py, line 315, in process_events
ev.dispatch(h)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3365, in
dispatch
return dispatch(handler, self.type.method, self)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3311, in
dispatch
return m(*args)
File /home/kkleidal/datawire/server/common.py, line 723, in
on_link_remote_close
self.connect(network)
File /home/kkleidal/datawire/server/common.py, line 709, in connect
self.conn.hostname = network.host
File /usr/lib/python2.7/dist-packages/proton/wrapper.py, line 54, in
__setattr__
object.__setattr__(self, name, value)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 2319, in
_set_hostname
return pn_connection_set_hostname(self._impl, name)
TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
const *'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming reassigned PROTON-802:
--
Assignee: Rafael H. Schloming
Unicode strings passed in through python binding cause exceptions
-
Key: PROTON-802
URL: https://issues.apache.org/jira/browse/PROTON-802
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.9
Environment: Ubuntu 14.04.1 64-bit
Reporter: Ken Leidal
Assignee: Rafael H. Schloming
Priority: Minor
Labels: encoding, string
The following traceback was thrown when passing in a python unicode string
for a host name. Ensuring the string is a python binary string (UTF-8) is a
work around.
{code:title=Traceback|borderStyle=solid}
Traceback (most recent call last):
File ./arc, line 246, in module
curses.wrapper(main)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File ./arc, line 244, in main
drv.run()
File /home/kkleidal/datawire/server/common.py, line 270, in run
self.process_events()
File /home/kkleidal/datawire/server/common.py, line 315, in process_events
ev.dispatch(h)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3365, in
dispatch
return dispatch(handler, self.type.method, self)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3311, in
dispatch
return m(*args)
File /home/kkleidal/datawire/server/common.py, line 723, in
on_link_remote_close
self.connect(network)
File /home/kkleidal/datawire/server/common.py, line 709, in connect
self.conn.hostname = network.host
File /usr/lib/python2.7/dist-packages/proton/wrapper.py, line 54, in
__setattr__
object.__setattr__(self, name, value)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 2319, in
_set_hostname
return pn_connection_set_hostname(self._impl, name)
TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
const *'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287347#comment-14287347 ] Rafael H. Schloming commented on PROTON-804: I believe this is a release blocker since if my understanding of the bug is correct, then any select loop that uses the transport can be trivially put into a busy loop using this bug. In fact it seems to be fairly easily triggered in a non malicious way if the connecting client dies at the right moment. (That is how I discovered it.) the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: transport-test.patch I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287893#comment-14287893 ] Rafael H. Schloming commented on PROTON-804: rschloming: basically what happens is the triggering connection sends a sasl-init frame and the dies rschloming: and the server side of the connection reports a No valid protocol header found rschloming: from line 212 of transport.c rschloming: and then the output gets stuck in pn_io_layer_output_null rschloming: which just always returns 0 stitchedup: I doubt that would have worked before the autodetect code either (but the symptom would have been different) stitchedup: because the sasl code has no way to deal with premature failure rschloming: it's possible that your changes have simply made it more likely to occur if the eliminate pipelining on the client side rschloming: but I'm pretty sure it's a recent thing because it gets triggered very easily by a client that has a simple typo in it rschloming: i.e. just firing up and dying stitchedup: hmm, you should never get into the null layer after failure rschloming: yeah, I didn't think that looked right stitchedup: you will get there though rschloming: it doesn't seem to do that if you just connect and then die without sending any data at all stitchedup: because if the server tries to do output before autodetect has happened it can't know what to output rschloming: sure, but it seems like failure should force a given response rschloming: failure should basically force it to assume AMQP on the output side I woudl think rschloming: since it is sending an amqp close frame to indicate the error stitchedup: ok It would really help it you pasted the above info into the bug itself the nuget about pn_io_..._null would have actually been useful the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: transport-test.patch I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-804: --- Description: I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: transport-test.patch I believe the issue is related to the autodetect code andrew added not too long ago. I've attached a patch that has a test case with a relatively minimal reproducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-804: --- Assignee: Andrew Stitcher the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Attachments: transport-test.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-804) the transport doesn't always shutdown its output properly
[ https://issues.apache.org/jira/browse/PROTON-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-804: --- Attachment: transport-test.patch This patch has a test case that illustrates the problem. the transport doesn't always shutdown its output properly - Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Attachments: transport-test.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-804) the transport doesn't always shutdown its output properly
Rafael H. Schloming created PROTON-804: -- Summary: the transport doesn't always shutdown its output properly Key: PROTON-804 URL: https://issues.apache.org/jira/browse/PROTON-804 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-800) [Windows C] Reactor test times out
[
https://issues.apache.org/jira/browse/PROTON-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278562#comment-14278562
]
Rafael H. Schloming commented on PROTON-800:
I believe there are two relevant cases to consider when answering your
question. If you assume you have a parent object (the pn_io_t) and a child
object (the pn_socket_t) we actually follow two different patterns depending on
the circumstances. In the case where the child object is a full fledged object,
e.g. the parent is a pn_connection_t and the child is a pn_session_t, we have
the parent keep a pointer to the child and keep it alive, so that the order of
decref of the parent relative to the child doesn't matter.
The second case to consider is when the child is not actually an independent
object, e.g. it might be a pn_handle_t rather than an actual pointer. (We use
this pattern in the map API for example.) In these cases the life of the child
is scoped to the parent and the order of decref is important.
In your case I think we have to assume the latter unless we turn pn_socket_t
into a full-on pointer rather than just an alias for a file descriptor. I think
this is fine so long as we are clear about the semantics.
[Windows C] Reactor test times out
--
Key: PROTON-800
URL: https://issues.apache.org/jira/browse/PROTON-800
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Environment: Windows Server 2012 R2, Visual Studio 2010 x64
Reporter: Chuck Rolke
ctest -VV times out on the reactor test.
Instrumenting and debugging shows the failure in test_reactor_acceptor
Running Debug instead of RelWithDebInfo crashes with an AccVio
{noformat}
qpid-protond.dll!pni_iocpdesc_map_get(iocp_t * iocp, unsigned __int64
s) Line 773 + 0xa bytes C++
qpid-protond.dll!pn_close(pn_io_t * io, unsigned __int64 socket) Line
350 + 0x16 bytes C++
qpid-protond.dll!pni_acceptor_finalize(pn_selectable_t * sel) Line 56
C++
qpid-protond.dll!pn_selectable_finalize(void * obj) Line 81C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_list_finalize(void * object) Line 205 C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_finalize(pn_reactor_t * reactor) Line 77
C++
qpid-protond.dll!pn_reactor_finalize_cast(void * object) Line 113 +
0x28 bytes C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_free(pn_reactor_t * reactor) Line 132
C++
c-reactor-tests.exe!test_reactor_acceptor() Line 171 C++
c-reactor-tests.exe!main(int argc, char * * argv) Line 446 C++
c-reactor-tests.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
c-reactor-tests.exe!mainCRTStartup() Line 371 C
kernel32.dll!7ff90cc913d2()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!7ff90e1003c4()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-800) [Windows C] Reactor test times out
[
https://issues.apache.org/jira/browse/PROTON-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277569#comment-14277569
]
Rafael H. Schloming commented on PROTON-800:
I wold take a look at commit 363ea5031d26bc19cd12e113e8b365d398120dea. I
suspect the same bug exists in the windows selector. The two selectors really
have a lot of duplicate code between them. Something should be done to allow
them to share more code.
[Windows C] Reactor test times out
--
Key: PROTON-800
URL: https://issues.apache.org/jira/browse/PROTON-800
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Environment: Windows Server 2012 R2, Visual Studio 2010 x64
Reporter: Chuck Rolke
ctest -VV times out on the reactor test.
Instrumenting and debugging shows the failure in test_reactor_acceptor
Running Debug instead of RelWithDebInfo crashes with an AccVio
{noformat}
qpid-protond.dll!pni_iocpdesc_map_get(iocp_t * iocp, unsigned __int64
s) Line 773 + 0xa bytes C++
qpid-protond.dll!pn_close(pn_io_t * io, unsigned __int64 socket) Line
350 + 0x16 bytes C++
qpid-protond.dll!pni_acceptor_finalize(pn_selectable_t * sel) Line 56
C++
qpid-protond.dll!pn_selectable_finalize(void * obj) Line 81C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_list_finalize(void * object) Line 205 C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_finalize(pn_reactor_t * reactor) Line 77
C++
qpid-protond.dll!pn_reactor_finalize_cast(void * object) Line 113 +
0x28 bytes C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_free(pn_reactor_t * reactor) Line 132
C++
c-reactor-tests.exe!test_reactor_acceptor() Line 171 C++
c-reactor-tests.exe!main(int argc, char * * argv) Line 446 C++
c-reactor-tests.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
c-reactor-tests.exe!mainCRTStartup() Line 371 C
kernel32.dll!7ff90cc913d2()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!7ff90e1003c4()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14269270#comment-14269270
]
Rafael H. Schloming commented on PROTON-784:
No worries, thanks for looking into it!
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-784.
Resolution: Fixed
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266036#comment-14266036
]
Rafael H. Schloming commented on PROTON-784:
I don't mean to suggest there isn't an issue. I just want to confirm whether or
not the change I made above actually fixed the problem you were seeing but for
linux only.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-791) c-reactor-tests fails because it listens to an IPv4 socket but connects to an IPv6 socket
[
https://issues.apache.org/jira/browse/PROTON-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266053#comment-14266053
]
Rafael H. Schloming commented on PROTON-791:
The reactor code is just delegating to the existing API provided by
proton/io.h. It passes 0.0.0.0 into the bind and uses localhost on the
connect. It looks like somehow localhost is getting turned into ::1.
I'm not sure exactly how to fix this or even where the bug is exactly. I would
naively expect binding to 0.0.0.0 and connecting to localhost to just work,
but I'm not super up to date on IPv6 stuff.
c-reactor-tests fails because it listens to an IPv4 socket but connects to an
IPv6 socket
-
Key: PROTON-791
URL: https://issues.apache.org/jira/browse/PROTON-791
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Andrew Stitcher
Assignee: Rafael H. Schloming
strace of relevant bits of failing run.
{noformat}
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(5672),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
listen(3, 50) = 0
...
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(5672), inet_pton(AF_INET6,
::1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS
(Operation now in progress)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 1000) = 1
([{fd=4, revents=POLLIN|POLLOUT|POLLERR|POLLHUP}])
recvfrom(4, 0x1b19200, 16384, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
...
sendto(4, AMQP\3\1\0\0\0\0\0!\2\1\0\0\0SA\320\0\0\0\21\0\0\0\2\243\tAN...,
224, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-791) c-reactor-tests fails because it listens to an IPv4 socket but connects to an IPv6 socket
[
https://issues.apache.org/jira/browse/PROTON-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266237#comment-14266237
]
Rafael H. Schloming commented on PROTON-791:
Do you know offhand which option is likely to be more portable?
c-reactor-tests fails because it listens to an IPv4 socket but connects to an
IPv6 socket
-
Key: PROTON-791
URL: https://issues.apache.org/jira/browse/PROTON-791
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Andrew Stitcher
Assignee: Rafael H. Schloming
strace of relevant bits of failing run.
{noformat}
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(5672),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
listen(3, 50) = 0
...
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(5672), inet_pton(AF_INET6,
::1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS
(Operation now in progress)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 1000) = 1
([{fd=4, revents=POLLIN|POLLOUT|POLLERR|POLLHUP}])
recvfrom(4, 0x1b19200, 16384, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
...
sendto(4, AMQP\3\1\0\0\0\0\0!\2\1\0\0\0SA\320\0\0\0\21\0\0\0\2\243\tAN...,
224, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-791) c-reactor-tests fails because it listens to an IPv4 socket but connects to an IPv6 socket
[
https://issues.apache.org/jira/browse/PROTON-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-791.
Resolution: Fixed
c-reactor-tests fails because it listens to an IPv4 socket but connects to an
IPv6 socket
-
Key: PROTON-791
URL: https://issues.apache.org/jira/browse/PROTON-791
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Andrew Stitcher
Assignee: Rafael H. Schloming
strace of relevant bits of failing run.
{noformat}
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(5672),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
listen(3, 50) = 0
...
socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK)= 0
setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
connect(4, {sa_family=AF_INET6, sin6_port=htons(5672), inet_pton(AF_INET6,
::1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS
(Operation now in progress)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN|POLLOUT}], 2, 1000) = 1
([{fd=4, revents=POLLIN|POLLOUT|POLLERR|POLLHUP}])
recvfrom(4, 0x1b19200, 16384, 0, 0, 0) = -1 ECONNREFUSED (Connection refused)
...
sendto(4, AMQP\3\1\0\0\0\0\0!\2\1\0\0\0SA\320\0\0\0\21\0\0\0\2\243\tAN...,
224, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264501#comment-14264501
]
Rafael H. Schloming commented on PROTON-784:
Any chance you can come up with a minimal reproducer in terms of the proton
API? I have no clue how messaging is using proton internally, so a minimal
reproducer in terms of the messaging API doesn't tell me a lot.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265176#comment-14265176
]
Rafael H. Schloming commented on PROTON-784:
I'm a bit confused as to how the fix could be platform specific. Are you sure
the issue was there on linux prior to my fix?
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14259646#comment-14259646
]
Rafael H. Schloming commented on PROTON-784:
I ran into what I believe is likely to be the same issue during my own testing.
I committed a fix that solves the issue I ran into and hopefully both the
issues you are seeing as well. It would be great if you guys could verify that
it does in fact fix your issues also.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-790) Use git tag for release (rather than branch)
[ https://issues.apache.org/jira/browse/PROTON-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257836#comment-14257836 ] Rafael H. Schloming commented on PROTON-790: I'll update the release script to use tags for the next alpha. Use git tag for release (rather than branch) Key: PROTON-790 URL: https://issues.apache.org/jira/browse/PROTON-790 Project: Qpid Proton Issue Type: Improvement Components: release Affects Versions: 0.9 Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor I think it would make sense to use git tags to indicate the versions of releases including alphas and betas. So instead of having branch with a single change on it we should use a tag to indicate a release. This would also allow the branching structure and the releases to be independent. As an example the recent 0.9-alpha-1 could be a tag on a 0.9-release branch. Or it could just be a tag on a one change branch (to change the version). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14254691#comment-14254691
]
Rafael H. Schloming commented on PROTON-784:
This sounds like a bug somewhere. The refcounting changes you mention shouldn't
change the observable behaviour of the APIs you are using. They are for the
benefit of the language bindings which directly incref/decref proton objects.
Can you provide a small test case that reproduces the behaviour you are seeing?
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
dispositions on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}
{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}
{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}
{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (PROTON-755) Update Ruby unit tests to use Minitest
[ https://issues.apache.org/jira/browse/PROTON-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reopened PROTON-755: This breaks the build for me, I get this: /usr/share/gems/gems/minitest-4.7.0/lib/minitest/unit.rb:19:in `const_missing': uninitialized constant MiniTest::Test (NameError) from /home/rhs/proton/tests/ruby/proton_tests/interop.rb:15:in `top (required)' from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require' from /home/rhs/proton/tests/ruby/proton-test:4:in `main' end of output Update Ruby unit tests to use Minitest -- Key: PROTON-755 URL: https://issues.apache.org/jira/browse/PROTON-755 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.9 The old Test::Unit module names have been collapsed down to Minitest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-755) Update Ruby unit tests to use Minitest
[ https://issues.apache.org/jira/browse/PROTON-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221905#comment-14221905 ] Rafael H. Schloming commented on PROTON-755: Oh, and I do have minitest installed: rpm -q rubygem-minitest rubygem-minitest-4.7.0-2.fc20.noarch Update Ruby unit tests to use Minitest -- Key: PROTON-755 URL: https://issues.apache.org/jira/browse/PROTON-755 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.9 The old Test::Unit module names have been collapsed down to Minitest. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-630) [python] Add a setup.py for installing the python bindings via PyPi
[ https://issues.apache.org/jira/browse/PROTON-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reopened PROTON-630: I've rolled back this change because it somewhat complicated the renaming/refactoring of the proton.py module into a package hierarchy. Also as I was looking into what it would take to get it working again I noticed that distutils is actually capable of invoking swig and generating the C wrapper source code on its own. I think all you need to do is define your extension to include cproton.i in the source rather than trying to pregenerate and bundle in the swig source code. I believe doing this would radically simplify a number of issues and possibly allow for a fairly vanilla setup.py that could be written outside of cmake as opposed to being generated by and intimately entangled with the cmake build. [python] Add a setup.py for installing the python bindings via PyPi --- Key: PROTON-630 URL: https://issues.apache.org/jira/browse/PROTON-630 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.8 Include a setup.py that can be used to upload/download the python bindings from PyPi. Rational: This feature would allow our python bindings to properly integrate with python virtual environments such as virtualenv. virtualenv allows a developer to override the python packages installed on their system. virtualenv works with pip to fetch python packages from repositories such as PyPi, allowing a developer to create a custom python environment that can be used for developing and testing python applications. Since we currently lack an easy method for providing the python bindings via PyPi, virtual environments cannot include proton python bindings, as the site-packages installed on the 'real' system are not available in the virtual environment by default. However, system libraries, such as libproton, *are* able to be referenced by the virtual environment by default. Given that, this new setup.py should only need to install the python files that live under site-packages. Specifically, only the proton.py, cproton.py, and the _cproton.so files need to be provided. The setup.py should be written to actually include the swig-generated C source, and build _cproton.so from it as part of the install into the target environment. Since only the python-specific files are provided, and the swig-generated C code must be built on the target machine, the setup.py will assume that the developer has already installed the proton libraries and header files on the target machine. To be clear: this feature will still *require* proton to be installed on the developer's machine - it merely allows the python bindings to then be installed into a virtual python site-packages via pip/PyPi. See https://virtualenv.pypa.io/en/latest/index.html for more details regarding virtual environments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-756) add a new/simpler setup.py for python bindings
Rafael H. Schloming created PROTON-756: -- Summary: add a new/simpler setup.py for python bindings Key: PROTON-756 URL: https://issues.apache.org/jira/browse/PROTON-756 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Rafael H. Schloming Assignee: Ken Giusti Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-756) add a new/simpler setup.py for python bindings
[ https://issues.apache.org/jira/browse/PROTON-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14221945#comment-14221945 ] Rafael H. Schloming commented on PROTON-756: See comments on PROTON-630. add a new/simpler setup.py for python bindings -- Key: PROTON-756 URL: https://issues.apache.org/jira/browse/PROTON-756 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Rafael H. Schloming Assignee: Ken Giusti Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-752) Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations
[ https://issues.apache.org/jira/browse/PROTON-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219373#comment-14219373 ] Rafael H. Schloming commented on PROTON-752: Isn't that something the swig generated code is in control of? I know for python at least it's a matter of configuring swig to tell it whether you want to release the GIL or not, and not something we actually do anything about in our code. Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations --- Key: PROTON-752 URL: https://issues.apache.org/jira/browse/PROTON-752 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Priority: Minor Currently the I/O-style calls to the Cproton methods don't unlock the Ruby GIL, impacting performance as other Threads could be given time on the interpreter whilst the extension code is running. Depending on Ruby version this is simply a matter of wrapping the calls in rb_thread_call_without_gvl (Ruby 2.x +) or rb_thread_blocking_region (Ruby 1.9.x). On Ruby 1.8 I'm not sure if you can enable this, but its my understanding that RHEL requires continued support for 1.8, so some #define work would be needed to perform a no-op on that version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-740) idle timeouts repeat and the transport never closes
Rafael H. Schloming created PROTON-740: -- Summary: 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] [Reopened] (PROTON-736) ruby: unable to send binary data?
[
https://issues.apache.org/jira/browse/PROTON-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming reopened PROTON-736:
The semantics described in the commit are going to result in interop issues
with lots of other clients.
Choosing whether to encode as string(utf8) vs binary based on the values passed
in is fundamentally broken. To understand why, imagine if I write a ruby client
that reads a bunch of binary files from a directory and sends them in the body
of a message to a Java client. Now let's say all of these files contain binary
data, say some sort of gzipped thing. Now let's further say that some of these
files coincidentally happen to contain bytes that are only in the range 0-127.
The semantics you have described will result in some of these files getting
sent as text messages and some of these files getting sent as data. This will
come out as different message types to a Java client, or if the values appear
in a map or list, they will be deseriaized as Strings rather than byte[].
Basically, the upshot is by choosing based on the content of the string, every
other AMQP client will need to check and deal with the possibility of both
string and binary values wherever they expect a binary value, and since nobody
expects to have to do this (and indeed even if they did it is incredibly
cumbersome to have to do so), you will get lots of really terrible interop bugs.
ruby: unable to send binary data?
-
Key: PROTON-736
URL: https://issues.apache.org/jira/browse/PROTON-736
Project: Qpid Proton
Issue Type: Bug
Components: ruby-binding
Affects Versions: 0.8
Reporter: Dominic Evans
Assignee: Darryl L. Pierce
Fix For: 0.9
Attachments:
0001-PROTON-736-Ruby-Message-does-not-return-all-content.patch,
0002-PROTON-736-Only-encode-Ruby-strings-as-UTF-8-if-it-s.patch
As discussed on irc with [~mcpierce]
I've not been able to determine how I can correctly send binary data using
the ruby gem.
From proton-c I can do this by (e.g.,)
{{
char* msgdata = Buffer::Data(buffer);
size_t msglen = Buffer::Length(buffer);
pn_message_set_format(msg-message, PN_DATA);
pn_message_load_data(msg-message, msgdata, msglen);
}}
and I assumed I might be able to do similar from Ruby by (e.g.,)
{{
data = File.binread(filename)
msg.format = Qpid::Proton::MessageFormat::DATA
msg.content = data
}}
But Ruby is reading the data into a string and the SWIG binding is still
expecting a byte* array here.
After our discussions on IRC I also investigated doing:
{{
filedata = File.binread(filename)
data = Qpid::Proton::Data.new
data.binary = filedata
msg.body = data
}}
but didn't have any luck with this approach either.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-707) Valgrind 'invalid read' errors in proton_tests.message.LoadSaveTest tests
[ https://issues.apache.org/jira/browse/PROTON-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-707: --- Fix Version/s: (was: 0.8) 0.9 Valgrind 'invalid read' errors in proton_tests.message.LoadSaveTest tests - Key: PROTON-707 URL: https://issues.apache.org/jira/browse/PROTON-707 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Ken Giusti Fix For: 0.9 Valgrind detects an invalid memory reference during these tests. To reproduce: $ valgrind -q --trace-children=yes --suppressions=./proton_tests/valgrind.supp ./proton-test proton_tests.message.LoadSaveTest.* proton_tests.message.LoadSaveTest.testData .. ==18459== Invalid read of size 1 ==18459==at 0x4A0A534: memcpy@@GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18459==by 0x30F0A8F1B7: PyString_FromStringAndSize (string3.h:51) ==18459==by 0xF24F5C7: _wrap_pn_message_save (cprotonPYTHON_wrap.c:3303) ==18459==by 0x30F0ADDC2D: PyEval_EvalFrameEx (ceval.c:4098) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADEBBC: PyEval_EvalCodeEx (ceval.c:3330) ==18459==by 0x30F0ADD6A8: PyEval_EvalFrameEx (ceval.c:4194) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADEBBC: PyEval_EvalCodeEx (ceval.c:3330) ==18459==by 0x30F0ADD6A8: PyEval_EvalFrameEx (ceval.c:4194) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459== Address 0x1055bb08 is 7 bytes after a block of size 17 alloc'd ==18459==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18459==by 0xF24F500: _wrap_pn_message_save (cprotonPYTHON_wrap.c:4029) ==18459==by 0x30F0ADDC2D: PyEval_EvalFrameEx (ceval.c:4098) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADEBBC: PyEval_EvalCodeEx (ceval.c:3330) ==18459==by 0x30F0ADD6A8: PyEval_EvalFrameEx (ceval.c:4194) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADEBBC: PyEval_EvalCodeEx (ceval.c:3330) ==18459==by 0x30F0ADD6A8: PyEval_EvalFrameEx (ceval.c:4194) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459==by 0x30F0ADD74B: PyEval_EvalFrameEx (ceval.c:4184) ==18459== pass -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-635) PN_TRANSPORT events not generated in enough places
[ https://issues.apache.org/jira/browse/PROTON-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-635: --- Fix Version/s: (was: 0.8) 0.9 PN_TRANSPORT events not generated in enough places -- Key: PROTON-635 URL: https://issues.apache.org/jira/browse/PROTON-635 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.8 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.9 In writing a custom driver for Proton I noticed thatthe new events code does not raise a PN_TRANSPORT event after it receives the incoming AMQP protocol header. So a purely event driven driver is not going to send the outgoing protocol header immediately, but is going to wait until it replies to the next frame (open). Also in error scenarios no PN_TRANSPORT is generated after the open/close frames are generated. This is going to end badly if the peer is waiting for the protocol header before sending the open. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-462) Documentation: Add doxygen overview file for Proton C API
[ https://issues.apache.org/jira/browse/PROTON-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-462: --- Fix Version/s: (was: 0.8) 0.9 Documentation: Add doxygen overview file for Proton C API - Key: PROTON-462 URL: https://issues.apache.org/jira/browse/PROTON-462 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.9 If possible, have the web page link to the *public header files* as the start page - that's were the meat of the API documentation exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-634) Packages are needed for Ubuntu Precise (12 LTS)
[ https://issues.apache.org/jira/browse/PROTON-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-634: --- Fix Version/s: (was: 0.8) 0.9 Packages are needed for Ubuntu Precise (12 LTS) --- Key: PROTON-634 URL: https://issues.apache.org/jira/browse/PROTON-634 Project: Qpid Proton Issue Type: Task Components: proton-c Affects Versions: 0.7 Reporter: Ken Giusti Priority: Minor Fix For: 0.9 Our PPA (ppa:qpid/released) only has proton packages for Ubuntu Trusty (14 LTS). Ubuntu Precise (12 LTS) is still supported by upstream - we should have packages for that also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora
[ https://issues.apache.org/jira/browse/PROTON-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-287: --- Fix Version/s: (was: 0.8) 0.9 Fix Qpid Proton-C build with MinGW on Fedora Key: PROTON-287 URL: https://issues.apache.org/jira/browse/PROTON-287 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.4 Environment: mingw32-gcc-4.7.2-7.fc18.x86_64 Reporter: Robin Lee Assignee: Cliff Jansen Labels: build, patch Fix For: 0.9 This is my first submit on ASF JIRA. Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided: Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff Description: %z format specifier is not provided by MSVCRT, use MinGW version of *printf to get it. Otherwise build failed with: proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character 'z' in format [-Werror=format] Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff Description: Libraries and header files should be written in small cases, otherwise build failed in cross build environment of Unix-like platforms: proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file or directory Patch 3: http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build failed with: proton-c/src/windows/driver.c:785:11: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Patch 4: http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff Description: Commented unimplemented functions. Otherwise build failed with proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared 'static' but never defined [-Werror=unused-function] Patch 5: http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff Description: 1. ID is not used, build failed with ../wincompat/internal/getopt.c:43:20: error: 'ID' defined but not used [-Werror=unused-variable] 2. Corrected getopt signiture, otherwise build failed with proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' but argument is of type 'const char *' 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so #include wincompat/getopt.h in .c files instead of .h, otherwise build failed with multiple definitions. Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff Description: WIN32 macro is not defined with -std=c99 but defined with -std=gnu99. Use _WIN32 macro in all places. Built on Fedora and examples of recv and send are tested on Windows 7. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-724) pn_transport_close_head doesn't generate the expected PN_TRANSPORT_HEAD_CLOSED event
[ https://issues.apache.org/jira/browse/PROTON-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-724. Resolution: Fixed Fix Version/s: 0.8 pn_transport_close_head doesn't generate the expected PN_TRANSPORT_HEAD_CLOSED event Key: PROTON-724 URL: https://issues.apache.org/jira/browse/PROTON-724 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-729) library assers in pn_full_settle
[ https://issues.apache.org/jira/browse/PROTON-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-729. Resolution: Fixed library assers in pn_full_settle Key: PROTON-729 URL: https://issues.apache.org/jira/browse/PROTON-729 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7, 0.8 Reporter: Michael Attachments: qpidd.trace.bz2 qProton library asserts in pn_full_settled function in qpidd. I had to create this issue on advise from Chuck Rolke since it turned out that attachements are blocked by email list -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-723. Resolution: Fixed Fix Version/s: 0.9 Proton-c does not support attaching to the transaction coordinator -- Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Hiram Chirino Assignee: Rafael H. Schloming Priority: Critical Labels: api, transactions Fix For: 0.9 Attachments: PROTON-723_part2_quick_and_dirty.patch, quick_and_dirty.patch Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-728) transport aborts when delivery ids are out of sequence
Rafael H. Schloming created PROTON-728: -- Summary: transport aborts when delivery ids are out of sequence Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-728) transport aborts when delivery ids are out of sequence
[ https://issues.apache.org/jira/browse/PROTON-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-728. Resolution: Fixed transport aborts when delivery ids are out of sequence -- Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-728) transport aborts when delivery ids are out of sequence
[ https://issues.apache.org/jira/browse/PROTON-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-728: --- Fix Version/s: 0.8 transport aborts when delivery ids are out of sequence -- Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-724) pn_transport_close_head doesn't generate the expected PN_TRANSPORT_HEAD_CLOSED event
Rafael H. Schloming created PROTON-724: -- Summary: pn_transport_close_head doesn't generate the expected PN_TRANSPORT_HEAD_CLOSED event Key: PROTON-724 URL: https://issues.apache.org/jira/browse/PROTON-724 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-718) disable SSL v3 for proton-j
Rafael H. Schloming created PROTON-718: -- Summary: disable SSL v3 for proton-j Key: PROTON-718 URL: https://issues.apache.org/jira/browse/PROTON-718 Project: Qpid Proton Issue Type: Bug Components: ton-j, proton-j Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-718) disable SSL v3 for proton-j
[ https://issues.apache.org/jira/browse/PROTON-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-718. Resolution: Fixed Fix Version/s: 0.8 disable SSL v3 for proton-j --- Key: PROTON-718 URL: https://issues.apache.org/jira/browse/PROTON-718 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-718) disable SSL v3 for proton-j
[ https://issues.apache.org/jira/browse/PROTON-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-718: --- Component/s: (was: ton-j) disable SSL v3 for proton-j --- Key: PROTON-718 URL: https://issues.apache.org/jira/browse/PROTON-718 Project: Qpid Proton Issue Type: Bug Components: proton-j Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-714) SSL buffer overflow with large frames
Rafael H. Schloming created PROTON-714: -- Summary: SSL buffer overflow with large frames Key: PROTON-714 URL: https://issues.apache.org/jira/browse/PROTON-714 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-714) SSL buffer overflow with large frames
[ https://issues.apache.org/jira/browse/PROTON-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14172322#comment-14172322 ] Rafael H. Schloming commented on PROTON-714: From an email thread: I am developing an application that acts as an AMQP Client, using an SSL connection on a topic. The messages received on this topic are quite large and for each message I catch the following Exception: java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(Unknown Source) at org.apache.qpid.proton.engine.impl.ssl.SimpleSslTransportWrapper.unwrapInput (SimpleSslTransportWrapper.java:128) at org.apache.qpid.proton.engine.impl.ssl.SimpleSslTransportWrapper.process(Sim pleSslTransportWrapper.java:344) at org.apache.qpid.proton.engine.impl.ssl.SslImpl$UnsecureClientAwareTransportW rapper.process(SslImpl.java:132) at org.apache.qpid.proton.engine.impl.TransportImpl.process(TransportImpl.java: 1265) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:136 ) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java: 95) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerI mpl.java:743) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl. java:895) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl. java:853) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java: 451) at org.apache.qpid.proton.messenger.impl.MessengerImpl.recv(MessengerImpl.java: 456) at com.oraise.Receiver.run(Receiver.java:30) SSL buffer overflow with large frames - Key: PROTON-714 URL: https://issues.apache.org/jira/browse/PROTON-714 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-712) Seg fault due to missing NULL return value check of getprotobyname
[ https://issues.apache.org/jira/browse/PROTON-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-712: -- Assignee: Rafael H. Schloming Seg fault due to missing NULL return value check of getprotobyname -- Key: PROTON-712 URL: https://issues.apache.org/jira/browse/PROTON-712 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Sahir Hoda Assignee: Rafael H. Schloming Labels: easyfix, patch Attachments: getprotobyname-err-check.patch There are several places proton-c makes calls to getprotobyname and dereferences the return value without checking for NULL first. Documentation for getprotobyname indicates it can return NULL if there was an error. We have seen seg faults in testing where getprotobyname returned NULL. Attached is a patch that adds some simple error checking to the getprotobyname call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-712) Seg fault due to missing NULL return value check of getprotobyname
[ https://issues.apache.org/jira/browse/PROTON-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-712. Resolution: Fixed Fix Version/s: 0.8 Seg fault due to missing NULL return value check of getprotobyname -- Key: PROTON-712 URL: https://issues.apache.org/jira/browse/PROTON-712 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Sahir Hoda Assignee: Rafael H. Schloming Labels: easyfix, patch Fix For: 0.8 Attachments: getprotobyname-err-check.patch There are several places proton-c makes calls to getprotobyname and dereferences the return value without checking for NULL first. Documentation for getprotobyname indicates it can return NULL if there was an error. We have seen seg faults in testing where getprotobyname returned NULL. Attached is a patch that adds some simple error checking to the getprotobyname call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-708) C proton driver needs a getter function to access the pn_error so it can be cleared
[
https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming reassigned PROTON-708:
--
Assignee: Rafael H. Schloming
C proton driver needs a getter function to access the pn_error so it can be
cleared
---
Key: PROTON-708
URL: https://issues.apache.org/jira/browse/PROTON-708
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Reporter: Jesse Fugitt
Assignee: Rafael H. Schloming
Our team is currently using Proton 0.7 and ran into an issue on Windows while
testing where we could not successfully reconnect to a broker once it was
taken down and brought back up (we are using a pn_driver_t in C). It appears
that having the ability to clear the pn_error_t stored in the driver struct
would have solved the issue for us. I'll include some of the details below
that were also sent to the mailing list but the solution is probably a pretty
easy fix that just involves adding a function to the driver that simply
returns its pn_error_t field.
Details
The Proton library's Driver Module (both Posix and Windows) does not supply a
mechanism to clear an error that was detected. In contrast, other modules
such as Connection supply a method to obtain the pn_error_t structure (see
pn_connection_error()). This method can be used in combination with
pn_error_clear() to clear an error.
It was observed that when establishing a connection from Windows to a
potential broker on Linux that a WSAECONNREFUSED can be returned from the
connect() call if the broker is not running. This results in a call to
select() with a -1 file descriptor. The select() returns a socket error which
is recorded in the Error Module. The error number can be obtained using the
pn_driver_errno() call. Deleting the Connection and therefore removing the
erroneous -1 file description results in subsequent successful select()
calls. However, querying the Driver module for an error will perpetually
return the last error. There is no mechanism to clear that error.
A small patch to the driver.c below is working for us currently but we wanted
input on what the best or more general solution to the problem should be:
return d ? pn_error_code(d-error) : PN_ARG_ERR;
---
int rtn = PN_ARG_ERR;
if (d) {
rtn = pn_error_code(d-error);
pn_error_clear(d-error);
}
return rtn;
On the mailing list, Rafael said his preference would be to expose the
driver's pn_error_t as the other modules do so it can be cleared rather than
auto-clearing it as we do in the sample patch above. However, the
pn_driver_error function already exists so either we need to break convention
with the other modules in terms of the function name or break compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-708) C proton driver needs a getter function to access the pn_error so it can be cleared
[
https://issues.apache.org/jira/browse/PROTON-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-708.
Resolution: Fixed
Fix Version/s: 0.8
C proton driver needs a getter function to access the pn_error so it can be
cleared
---
Key: PROTON-708
URL: https://issues.apache.org/jira/browse/PROTON-708
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Reporter: Jesse Fugitt
Assignee: Rafael H. Schloming
Fix For: 0.8
Our team is currently using Proton 0.7 and ran into an issue on Windows while
testing where we could not successfully reconnect to a broker once it was
taken down and brought back up (we are using a pn_driver_t in C). It appears
that having the ability to clear the pn_error_t stored in the driver struct
would have solved the issue for us. I'll include some of the details below
that were also sent to the mailing list but the solution is probably a pretty
easy fix that just involves adding a function to the driver that simply
returns its pn_error_t field.
Details
The Proton library's Driver Module (both Posix and Windows) does not supply a
mechanism to clear an error that was detected. In contrast, other modules
such as Connection supply a method to obtain the pn_error_t structure (see
pn_connection_error()). This method can be used in combination with
pn_error_clear() to clear an error.
It was observed that when establishing a connection from Windows to a
potential broker on Linux that a WSAECONNREFUSED can be returned from the
connect() call if the broker is not running. This results in a call to
select() with a -1 file descriptor. The select() returns a socket error which
is recorded in the Error Module. The error number can be obtained using the
pn_driver_errno() call. Deleting the Connection and therefore removing the
erroneous -1 file description results in subsequent successful select()
calls. However, querying the Driver module for an error will perpetually
return the last error. There is no mechanism to clear that error.
A small patch to the driver.c below is working for us currently but we wanted
input on what the best or more general solution to the problem should be:
return d ? pn_error_code(d-error) : PN_ARG_ERR;
---
int rtn = PN_ARG_ERR;
if (d) {
rtn = pn_error_code(d-error);
pn_error_clear(d-error);
}
return rtn;
On the mailing list, Rafael said his preference would be to expose the
driver's pn_error_t as the other modules do so it can be cleared rather than
auto-clearing it as we do in the sample patch above. However, the
pn_driver_error function already exists so either we need to break convention
with the other modules in terms of the function name or break compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-676) proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable
[ https://issues.apache.org/jira/browse/PROTON-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-676. Resolution: Fixed proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable -- Key: PROTON-676 URL: https://issues.apache.org/jira/browse/PROTON-676 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 24_ssl_transport_failure_fix_messenger.c.patch When an ssl failure occurs during connection at the transport layer the error is not propagated back to messenger (it is ignored). Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
[ https://issues.apache.org/jira/browse/PROTON-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reopened PROTON-465: The latest commit on this JIRA seems to have broken the build on certain versions of whatever they run on ec2. Details to follow... FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Assignee: Darryl L. Pierce Priority: Minor Fix For: 0.8 With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-465) FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection
[ https://issues.apache.org/jira/browse/PROTON-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14165076#comment-14165076 ] Rafael H. Schloming commented on PROTON-465: -- Build type is RelWithDebInfo (has debug symbols) -- The C compiler identification is GNU 4.8.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- PN_VERSION: 0.8 -- Found Java: /usr/lib/jvm/java/bin/java -- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version 1.0.1i) -- Found PythonInterp: /usr/bin/python (found version 2.6.9) -- Looking for clock_gettime -- Looking for clock_gettime - found -- Looking for uuid_generate -- Looking for uuid_generate - not found -- Looking for uuid_generate in uuid -- Looking for uuid_generate in uuid - found -- Looking for strerror_r -- Looking for strerror_r - found -- Looking for atoll -- Looking for atoll - found -- Found SWIG: /usr/bin/swig (found version 2.0.10) -- Found PythonLibs: /usr/lib64/libpython2.6.so (found version 2.6.9) -- Could NOT find Ruby (missing: RUBY_INCLUDE_DIR RUBY_LIBRARY RUBY_CONFIG_INCLUDE_DIR) (found version 2.0.0) -- Found Perl: /usr/bin/perl (found version 5.16.3) -- Trying alternative search for Perl -- Looking for libperl.so -- Found PerlLibs: /usr/lib64/perl5/CORE/libperl.so -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Can't locate the valgrind command; no run-time error detection -- Skipping Ruby tests: missing dependencies -- Cannot find both Java and Maven: testing disabled for Proton-J CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PERL_INCLUDE_PATH used as include directory in directory /home/ec2-user/proton/proton-c/bindings/perl -- Configuring incomplete, errors occurred! See also /home/ec2-user/proton/build2/CMakeFiles/CMakeOutput.log. See also /home/ec2-user/proton/build2/CMakeFiles/CMakeError.log. FindPerlLibs.cmake module in Proton behaves differently to Qpid's Perl detection Key: PROTON-465 URL: https://issues.apache.org/jira/browse/PROTON-465 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Environment: Ubuntu 11.10 (at least) Reporter: Fraser Adams Assignee: Darryl L. Pierce Priority: Minor Fix For: 0.8 With Proton when I do cmake .. it barfs with -- Trying alternative search for Perl -- PerlLibs Not Found Though I can get it to play nicely by doing cmake .. -DPERL_LIBRARY=`locate -n 1 libperl.so` This might not be so unreasonable as I'm using a fairly old version of Ubuntu that needs upgrading, however the Perl detection on Qpid works perfectly well for me (and I'd assume for others too) which suggests that it's possibly more thorough. At the very least it would seem sensible to maintain consistency with the cmake modules across various Qpid components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-648) Memory leaks on aborted connections.
[
https://issues.apache.org/jira/browse/PROTON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-648.
Resolution: Duplicate
Fix Version/s: 0.8
Memory leaks on aborted connections.
Key: PROTON-648
URL: https://issues.apache.org/jira/browse/PROTON-648
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7, 0.8
Reporter: Marcel Meulemans
Assignee: Rafael H. Schloming
Fix For: 0.8
Attachments: leak.c
When a connection is aborted, open sessions can not be ended and attached
links can not be not detached properly. Because of this there are some
references to connection/sessions/links that are not released properly:
# The session state does not release references to links in the
{{local_handles/remote_handles}} hash map. This causes a leak because the
session references links and the links reference the session but the engine
does have a reference to any of these objects anymore.
# The transport does not release references to sessions in the
{{local_channels/remote_channels}} hash map. This is not really a leak
because the references are released in {{pn_transport_free}}, but i.m.o. they
should be release when the connection is unbound from the transport, i.e.
{{pn_unbind_transport()}}.
The leak can be observed by using the attached test program with ActiveMQ.
When ActiveMQ is shutdown with CTRL-C it just kills the connection causing a
transport error (connection aborted) on the client side. When this happens
the program leaks. See below for the program/valgrind output of the program
with and without the patch.
The patch can be found here:
https://github.com/marcelmeulemans/qpid-proton/commit/e5300da7be015ea874248b6593040d1bd50ac0e3
- The removed commented code in {{pn_session_finalize}} is the right idea in
the wrong place; {{pn_session_finalize}} is never called because the
references that this code releases still exist. The code has been moved to a
new function {{pn_cleanup_session}} in the transport class.
- The {{pn_cleanup_session}} call from {{pn_remove_session}} is needed in the
case the session is freed ({{pn_session_free}}) manually from application
code.
- The {{pn_cleanup_session}} call from {{pn_transport_unbind}} is needed in
the case the session is automatically freed via the connection.
- The changes in {{pn_session_close}} solve the real leak describe in *1*
above.
*Valgrind output without patch*:
{noformat}
==5607== Memcheck, a memory error detector
==5607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5607== Command: ./leak.symbols
==5607==
Connected to 127.0.0.1:5672
[0x6671b80]: - SASL
[0x6671b80]: - SASL
[0x6671b80]:0 - @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x6671b80]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b]
[0x6671b80]:0 - @sasl-outcome(68) [code=0]
[0x6671b80]: - AMQP
[0x6671b80]: - AMQP
[0x6671b80]:0 - @open(16) [container-id=leak, hostname=leak]
[0x6671b80]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x6671b80]:0 - @attach(18) [name=leak, handle=0, role=true,
snd-settle-mode=0, rcv-settle-mode=1, source=@source(40)
[address=queue://leak, durable=0, timeout=0, dynamic=false],
target=@target(41) [address=queue://leak, durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x6671b80]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=8, drain=false]
[0x6671b80]:0 - @open(16) [container-id=, hostname=,
max-frame-size=1048576]
[0x6671b80]:0 - @begin(17) [remote-channel=0, next-outgoing-id=1,
incoming-window=0, outgoing-window=0, handle-max=1024]
[0x6671b80]:0 - @attach(18) [name=leak, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address=queue://leak], target=@target(41) [address=queue://leak],
incomplete-unsettled=false, initial-delivery-count=0]
[0x6671b80]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error]]
[0x6671b80]:ERROR amqp:connection:framing-error connection aborted
[0x6671b80]:ERROR[-2] connection aborted
[0x6671b80]: - EOS
[0x6671b80]: - EOS (-2) connection aborted
Closed 127.0.0.1:5672
close: Bad file descriptor
==5607==
==5607== HEAP SUMMARY:
==5607== in use at exit: 14,904 bytes in 306 blocks
==5607== total heap usage: 508 allocs, 202 frees, 1,151,697 bytes allocated
==5607==
==5607== 14,904 (256 direct, 14,648 indirect) bytes in 1 blocks are
definitely lost in loss record 306 of 306
==5607==at 0x4C2935B: malloc
[jira] [Updated] (PROTON-660) Fix openssl.c build on windows
[ https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-660: --- Assignee: Andrew Stitcher Fix openssl.c build on windows -- Key: PROTON-660 URL: https://issues.apache.org/jira/browse/PROTON-660 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Environment: Windows 7, VS2013 Reporter: Bozo Dragojevic Assignee: Andrew Stitcher Attachments: 0001-PROTON-660-Fix-openssl.c-build-on-windows.patch, 25_openssl_fix_for_windows_CMakeLists.patch, 25_openssl_fix_for_windows_data.h.patch, 25_openssl_fix_for_windows_platform.h.patch Compiled openssl-1.0.1i from source Proton finds it, but openssl.c does not compile without small adjustments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-660) Fix openssl.c build on windows
[ https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-660: --- Fix Version/s: 0.8 Fix openssl.c build on windows -- Key: PROTON-660 URL: https://issues.apache.org/jira/browse/PROTON-660 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Environment: Windows 7, VS2013 Reporter: Bozo Dragojevic Assignee: Andrew Stitcher Fix For: 0.8 Attachments: 0001-PROTON-660-Fix-openssl.c-build-on-windows.patch, 25_openssl_fix_for_windows_CMakeLists.patch, 25_openssl_fix_for_windows_data.h.patch, 25_openssl_fix_for_windows_platform.h.patch Compiled openssl-1.0.1i from source Proton finds it, but openssl.c does not compile without small adjustments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-661) pn_message_save_* do not return correct message size when PN_OVERFLOW
[ https://issues.apache.org/jira/browse/PROTON-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-661: -- Assignee: Rafael H. Schloming pn_message_save_* do not return correct message size when PN_OVERFLOW - Key: PROTON-661 URL: https://issues.apache.org/jira/browse/PROTON-661 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4, 0.5, 0.7 Environment: All plataforms Reporter: Miguel da Rocha Correia Lima Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.8 Attachments: landix-ret-size-message-save.patch Expected behavior: When you use pn_message_save* functions API, you pass char *data and size_t *size. If the size IS NOT enough to save mesage body text, this functions return in size_t *size variable, the necessary buffer size and return PN_OVERFLOW status. Behavior observed: The pn_message_save* functions API return PN_OVERFLOW status and DO NOT return a correct value of necessary buffer. Patch to fix expected behavior is attached: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-565) Modify the Messenger to use the Collector API.
[ https://issues.apache.org/jira/browse/PROTON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-565: --- Fix Version/s: (was: 0.8) Modify the Messenger to use the Collector API. -- Key: PROTON-565 URL: https://issues.apache.org/jira/browse/PROTON-565 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Attachments: PROTON-565.part1.patch Modify the Messenger to use the Collector API instead of querying the for state changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-594) In tree builds with cmake causes issues when running python based tests
[ https://issues.apache.org/jira/browse/PROTON-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-594: --- Fix Version/s: (was: 0.8) In tree builds with cmake causes issues when running python based tests --- Key: PROTON-594 URL: https://issues.apache.org/jira/browse/PROTON-594 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rajith Attapattu Assignee: Rafael H. Schloming If we do an in-tree build it causes path issues when trying to run the python based tests against the java code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-343) Add a pluggable Proton logging layer
[ https://issues.apache.org/jira/browse/PROTON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-343: --- Fix Version/s: (was: 0.8) Add a pluggable Proton logging layer Key: PROTON-343 URL: https://issues.apache.org/jira/browse/PROTON-343 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-343-sketched-out-the-Java-parts-of-the-propos.patch Applications that use Proton sometimes want Proton to produce logging. Goals * Proton should provide a default logging implementation. * It should be easy for Proton client code to provide custom logging implementation, e.g. one that uses the same third party logging framework as their application code. * Proton should not have a compile-time dependency on a third party logging framework * Proton's log output is considered to be part of its public interface. Therefore, in the spirit of Proton's cross-language consistency goals, this output should be consistent between proton-c and proton-j. * The goals that general-purpose logging frameworks try to meet - performance, ease of use etc - also apply. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-643) Malloc result used without testing for null
[
https://issues.apache.org/jira/browse/PROTON-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-643:
---
Fix Version/s: (was: 0.8)
Malloc result used without testing for null
---
Key: PROTON-643
URL: https://issues.apache.org/jira/browse/PROTON-643
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Reporter: Chuck Rolke
{noformat}
pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t));
buf-capacity = capacity;
{noformat}
Many calls to malloc are properly checked but not all.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-589) Implement passive mode for proton-j messenger
[ https://issues.apache.org/jira/browse/PROTON-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-589: --- Fix Version/s: (was: 0.8) Implement passive mode for proton-j messenger - Key: PROTON-589 URL: https://issues.apache.org/jira/browse/PROTON-589 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Rajith Attapattu Assignee: Rajith Attapattu Passive mode allows the file descriptors for messenger to be serviced by an external loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-515: --- Fix Version/s: (was: 0.8) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Attachments: codec.c.patch, driver.c.patch, message.c.patch There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-632) [python] Add user context handle for all objects provided by the binding
[ https://issues.apache.org/jira/browse/PROTON-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-632: --- Fix Version/s: (was: 0.8) [python] Add user context handle for all objects provided by the binding Key: PROTON-632 URL: https://issues.apache.org/jira/browse/PROTON-632 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Ken Giusti Purely syntactic sugar, but we should add a 'context' field to the API of all of the singleton objects (connection, link, session, delivery, etc) provided by the binding. This context field would be available for the user application - exactly like the get/set context methods in the C engine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-689) Python binding does not expose transport error details
[ https://issues.apache.org/jira/browse/PROTON-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147264#comment-14147264 ] Rafael H. Schloming commented on PROTON-689: I added a Transport.condition property to access error details. The pn_condition_t object is very similar to pn_error_t except rather than a numeric code it has a symbolic name and it can also carry a map with additional parameters. In python it seems kind of confusing and pointless to have both concepts (we should possibly merge them in C also), so I opted to expose the error details as a condition rather than an error since pn_condition_t can carry the full range of protocol errors and info, whereas pn_error_t cannot. I don't really know why Connection has an error property. Pretty much anything that generates an error should be exposed to the binding via exceptions. I commented out the error property and none of the tests failed, so I'm thinking we should deprecate the error property on connection and use the Connection's condition property instead. Let me know if what I have added works for you. Python binding does not expose transport error details -- Key: PROTON-689 URL: https://issues.apache.org/jira/browse/PROTON-689 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Reporter: Ken Giusti Fix For: 0.8 The proton event model defines a TRANSPORT_ERROR event, but when the event occurs there is no way to extract the error code nor the error text from the transport when using the python binding. The connection class exports the error code via the 'error' property. I'd like to see an 'error' property added to the Transport class, and an 'error_text' property to both the Transport and the Connection for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-689) Python binding does not expose transport error details
[ https://issues.apache.org/jira/browse/PROTON-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-689. Resolution: Fixed Python binding does not expose transport error details -- Key: PROTON-689 URL: https://issues.apache.org/jira/browse/PROTON-689 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.8 Reporter: Ken Giusti Assignee: Rafael H. Schloming Fix For: 0.8 The proton event model defines a TRANSPORT_ERROR event, but when the event occurs there is no way to extract the error code nor the error text from the transport when using the python binding. The connection class exports the error code via the 'error' property. I'd like to see an 'error' property added to the Transport class, and an 'error_text' property to both the Transport and the Connection for completeness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-675) proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode
[ https://issues.apache.org/jira/browse/PROTON-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-675: -- Assignee: Rafael H. Schloming proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode - Key: PROTON-675 URL: https://issues.apache.org/jira/browse/PROTON-675 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.c.patch, 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.h.patch Messenger doesn't provide a way of setting the SSL peer authentication mode when a trust certificate is being used (it is hardcoded to: PN_SSL_VERIFY_PEER_NAME). We want the option to be able to optionally specify PN_SSL_VERIFY_PEER instead. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-677) proton-c: transport incorrectly detaches all links with closed=true by default
[ https://issues.apache.org/jira/browse/PROTON-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-677: -- Assignee: Rafael H. Schloming proton-c: transport incorrectly detaches all links with closed=true by default -- Key: PROTON-677 URL: https://issues.apache.org/jira/browse/PROTON-677 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Attachments: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch qpid-proton detaches all links with closed=true by default. If a subscription has a time-to-live and is not expected to be destroyed on detach then we shouldn't be setting closed=true on the detach call. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-677) proton-c: transport incorrectly detaches all links with closed=true by default
[ https://issues.apache.org/jira/browse/PROTON-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-677. Resolution: Fixed Fix Version/s: 0.8 proton-c: transport incorrectly detaches all links with closed=true by default -- Key: PROTON-677 URL: https://issues.apache.org/jira/browse/PROTON-677 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch qpid-proton detaches all links with closed=true by default. If a subscription has a time-to-live and is not expected to be destroyed on detach then we shouldn't be setting closed=true on the detach call. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
[ https://issues.apache.org/jira/browse/PROTON-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-678: --- Assignee: Andrew Stitcher proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 27_32bit_windows_fix_transport.c.patch For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
