[jira] [Commented] (PROTON-810) Publish javascript binding on npm
[ https://issues.apache.org/jira/browse/PROTON-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14298773#comment-14298773 ] Matteo Murgida commented on PROTON-810: --- ok, how can I help? can I publish it by myself with that name? Publish javascript binding on npm - Key: PROTON-810 URL: https://issues.apache.org/jira/browse/PROTON-810 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.8 Environment: NodeJS Reporter: Matteo Murgida Labels: javascript, nodejs, npm Fix For: 0.9 It would be very useful to the nodejs community to have the javascript binding published on npm as qpid-proton. If you prefer, I can maintain that release for you :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-812: - Assignee: Gordon Sim LinkException needs an attribute that indicates the reason for the exception. - Key: PROTON-812 URL: https://issues.apache.org/jira/browse/PROTON-812 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.8 Reporter: Jeff Ortel Assignee: Gordon Sim LinkException needs an attribute that indicates the reason for the exception so that the exception can be appropriately delt with. For example: A link exception caused when a node does not exist would be delt with differently than a link exception caused by an issue in the link chain involving dispatch router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
Jeff Ortel created PROTON-812: - Summary: LinkException needs an attribute that indicates the reason for the exception. Key: PROTON-812 URL: https://issues.apache.org/jira/browse/PROTON-812 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.8 Reporter: Jeff Ortel LinkException needs an attribute that indicates the reason for the exception so that the exception can be appropriately delt with. For example: A link exception caused when a node does not exist would be delt with differently than a link exception caused by an issue in the link chain involving dispatch router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-809) Changes to build on AIX with IBM XL C
[ https://issues.apache.org/jira/browse/PROTON-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Huston resolved PROTON-809. - Resolution: Fixed Fix Version/s: 0.9 Changes to build on AIX with IBM XL C - Key: PROTON-809 URL: https://issues.apache.org/jira/browse/PROTON-809 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: IBM AIX 7, XL C/C++ 13.1 Reporter: Steve Huston Priority: Minor Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Ruby, Proton Engine and Records
So over the last week I've been working on a way to avoid leaking memory or causing segfaults when the underlying C library is giving a reference to a Ruby object. And after much coding and gnashing of teeth I foudn the easiest way to do this with manually wrapping the pn_record_t struct. That would allow for adding a mark function to mark any Ruby objects so that they could not be reaped during garbage collection. And this would work fine but for one problem: the instances of pn_record are created by transport, etc. as part of *their* initializations. So there is no way for us to manually wrap the pn_record_t type for Ruby use in Swig. So looking at things, I have an alternate method that's not brittle and which gives us the feature we're looking for. From the Swig code, we can wrap the call to pn_record_set, at which point we have access to the Ruby wrapper for the pn_record_t type. We can then add/modify instance variables on that Ruby wrapper. Specifically, we can add and then update one named pn_record_attrs (or any other arbitrary name) and use it to track any objects that're added or replaced for the record. And the bonus is that, when the pn_record_t is deleted, it's Ruby wrapper is deleted as well and _all_ instance variables (including our Ruby objects) will be reaped along with it. I'm going to do some more testing on this, but my initial findings support this memory management scheme as viable. I have a test application that creates 500k+ values, storing them in a single record instance. Iterating back over the records and recovering them after running garbage collect returns variables as expected. Commenting out the portion that manages the wrapper instance variable and the same tests fail with a segfault while accessing the records. The work can all be checked out here [1], with the changes to the ruby.i file as the most recent commit in the branch. I'd love to get some feedback on this work in general as well. [1] https://github.com/mcpierce/Proton/tree/PROTON-799-Ruby-engine-apis -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp3CnIpetAP6.pgp Description: PGP signature
[jira] [Commented] (PROTON-809) Changes to build on AIX with IBM XL C
[ https://issues.apache.org/jira/browse/PROTON-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14299197#comment-14299197 ] ASF subversion and git services commented on PROTON-809: Commit 5c6207f6ac673af3922975cb5f2669a29ff96ebb in qpid-proton's branch refs/heads/master from [~shuston] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5c6207f ] Merge branch 'PROTON-809' Changes to build on AIX with IBM XL C - Key: PROTON-809 URL: https://issues.apache.org/jira/browse/PROTON-809 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: IBM AIX 7, XL C/C++ 13.1 Reporter: Steve Huston Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 01:22:45PM -0500, Rafael Schloming wrote: snip Also, have you been able to validate your testing strategy for either/both of these POCs? Can you generate seg faults and/or valgrind warnings when you intentionally comment out the line of code that keeps the reference alive? The POC that uses manual wrapping of a C struct works correctly, preventing objects from being reaped without leaking memory. I validated this by creating exhaustive (1M+) instances of both pure Ruby and C structs that have been wrapped via the Data_Wrap_Struct, assigning the Ruby object to the C struct so that only C held a reference to it, then calling GC.start to reap objects and then checking that the expected number of the pure Ruby objects still existed, via ObjectSpace.each_object([class]).count. Accessing the C-help Ruby object and doing functions such as class_eval on it worked without segmentation faults. I then ensures that it wasn't a fluke by commenting out, in the function that marks the Ruby object in C to keep it from being reaped, and re-running the tests. The app *immediately* segfaults after trying to class_eval the first Ruby object after garbage collection. So this path is the right one to follow. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpjpMUrU8T1Y.pgp Description: PGP signature
[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=14298521#comment-14298521 ] Adrian Preston commented on PROTON-811: --- Once again, thanks for the quick feedback. I should have probably taken a look at the C implementation first, so cheers for pointing me at that. I don't think there is much difference between a timeout or deadline based approach - but since the C code uses deadlines (and got their first), I think that consistency should win. I'll re-work based on the C code. [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)
