[jira] [Updated] (PROTON-209) Update README file(s) to more specific about required versions of tools
[ https://issues.apache.org/jira/browse/PROTON-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-209: --- Labels: docs (was: ) > Update README file(s) to more specific about required versions of tools > --- > > Key: PROTON-209 > URL: https://issues.apache.org/jira/browse/PROTON-209 > Project: Qpid Proton > Issue Type: Task >Affects Versions: 0.3 >Reporter: Philip Harvey >Priority: Minor > Labels: docs > > We should be more explicit about which version of the following tools are > required by Proton, either in the top level README or in READMEs in the > relevant sub-folders: > - Python (see PROTON-199). > - Swig > - cmake? (the required version is specified in the CMakeLists.txt files but > maybe it would be polite to mention in the README too). > - Maven? (or maybe we can omit this for same reasons as cmake version) > - possibly others, e.g. openssl, gcc, epydoc, Perl, Ruby etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-416) Proton needs an icon
[ https://issues.apache.org/jira/browse/PROTON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-416: --- Fix Version/s: Future > Proton needs an icon > > > Key: PROTON-416 > URL: https://issues.apache.org/jira/browse/PROTON-416 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: 0.5 >Reporter: Chuck Rolke > Fix For: Future > > > The Proton project needs a cool icon. Qpid has the Q with the feather but > Qpid Proton doesn't have anything yet. > Who has a graphic for us? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-282) Add support for transport unbind to proton-j
[ https://issues.apache.org/jira/browse/PROTON-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-282: --- Fix Version/s: Future > Add support for transport unbind to proton-j > > > Key: PROTON-282 > URL: https://issues.apache.org/jira/browse/PROTON-282 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Philip Harvey > Fix For: Future > > > As discussed on the mailing list recently (see > http://qpid.2158936.n2.nabble.com/Defining-the-behaviour-of-Proton-Engine-API-under-error-conditions-tp7590533.html), > Proton applications sometimes want to unbind a transport, e.g. following an > error, with the intention of binding to a new transport later on. > proton-j does not currently support unbinding. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-135) Provide hooks in proton-c to allow override of malloc/free for internal types
[ https://issues.apache.org/jira/browse/PROTON-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-135: --- Labels: close-pending (was: ) > Provide hooks in proton-c to allow override of malloc/free for internal types > - > > Key: PROTON-135 > URL: https://issues.apache.org/jira/browse/PROTON-135 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross > Labels: close-pending > > It is desirable for engine applications (i.e. advanced developers) to be able > to provide a custom memory management solution for data types used in proton. > I will follow up later with a proposal for how this might be done. My > general thought is to allow an extension "plugin" to provide type-specific > 'allocate' and 'free' functions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1311) [proton-c] engine interface provides no access to Attach/max-message-size
[ https://issues.apache.org/jira/browse/PROTON-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1311: Fix Version/s: 0.16.0 > [proton-c] engine interface provides no access to Attach/max-message-size > - > > Key: PROTON-1311 > URL: https://issues.apache.org/jira/browse/PROTON-1311 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.14.0 >Reporter: Chuck Rolke > Fix For: 0.16.0 > > > A set function for new links is required. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1175) Document BlockingConnection resource cleanup
[ https://issues.apache.org/jira/browse/PROTON-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1175: Labels: docs (was: ) > Document BlockingConnection resource cleanup > > > Key: PROTON-1175 > URL: https://issues.apache.org/jira/browse/PROTON-1175 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen > Labels: docs > Fix For: 0.17.0 > > > The documentation is silent on resource cleanup for BlockingConnections. > Currently if the BlockingConnection is not closed, the file descriptors and > other reactor machinery are leaked. > Standard Python techniques should be used to ensure resource clean up > (try..finally blocks etc.) > Only the sync_client example hints this might be desirable, let alone > necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1175) Document BlockingConnection resource cleanup
[ https://issues.apache.org/jira/browse/PROTON-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1175: Fix Version/s: 0.17.0 > Document BlockingConnection resource cleanup > > > Key: PROTON-1175 > URL: https://issues.apache.org/jira/browse/PROTON-1175 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen > Labels: docs > Fix For: 0.17.0 > > > The documentation is silent on resource cleanup for BlockingConnections. > Currently if the BlockingConnection is not closed, the file descriptors and > other reactor machinery are leaked. > Standard Python techniques should be used to ensure resource clean up > (try..finally blocks etc.) > Only the sync_client example hints this might be desirable, let alone > necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1176) Core dump if reactor creation fails
[ https://issues.apache.org/jira/browse/PROTON-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1176: Labels: crash (was: ) > Core dump if reactor creation fails > --- > > Key: PROTON-1176 > URL: https://issues.apache.org/jira/browse/PROTON-1176 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen > Labels: crash > Fix For: 0.17.0 > > > If a BlockingConnection fails creating a reactor from Proton-C, the wrapper > constructor for the container fails on a null "impl" value, causing a core > dump rather than an exception. > This can happen if the process runs out of file descriptors and cannot > allocate the self-pipes needed by the reactor. > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1176) Core dump if reactor creation fails
[ https://issues.apache.org/jira/browse/PROTON-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1176: Fix Version/s: 0.17.0 > Core dump if reactor creation fails > --- > > Key: PROTON-1176 > URL: https://issues.apache.org/jira/browse/PROTON-1176 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen > Fix For: 0.17.0 > > > If a BlockingConnection fails creating a reactor from Proton-C, the wrapper > constructor for the container fails on a null "impl" value, causing a core > dump rather than an exception. > This can happen if the process runs out of file descriptors and cannot > allocate the self-pipes needed by the reactor. > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1260) provide convenience operations for described types
[ https://issues.apache.org/jira/browse/PROTON-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1260: Fix Version/s: Future > provide convenience operations for described types > -- > > Key: PROTON-1260 > URL: https://issues.apache.org/jira/browse/PROTON-1260 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > Fix For: Future > > > Manipulating described types is not a frequent activity, but currently > requires using encoder/decoder classes to inspect/modify. See > examples/cpp/selected_recv.cpp. Same issue for server side code. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1234) Windows IO modules need updating to match Posix improvements
[ https://issues.apache.org/jira/browse/PROTON-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1234: Fix Version/s: Future > Windows IO modules need updating to match Posix improvements > > > Key: PROTON-1234 > URL: https://issues.apache.org/jira/browse/PROTON-1234 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.14.0 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: Future > > > The Posix IO and OpenSSL modules have had improvements not yet transferred to > the Windows side. These include better error messages, logging and probably > some basic bug fixes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory
[ https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1312: Labels: leak reproducer (was: ) > BlockingConnection leaks Proton-C memory > > > Key: PROTON-1312 > URL: https://issues.apache.org/jira/browse/PROTON-1312 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.15.0 >Reporter: Cliff Jansen > Labels: leak, reproducer > Fix For: 0.17.0 > > Attachments: ml8.py > > > The attached program leaks the underlying connection (the C proton > object) associated with the BlockingConnection on each loop iteration > on proton 0.9 as used by Satellite. Without the receiver, it cleans > up fine. > On master, the program leaks both the reactor and the connection > associated with the BlockingConnection for each loop. The receiver > creation can be commented out and it still leaks both objects. > Other objects may leak too (presumably session), but I have not > examined further. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1264) on_receiver_open event after close
[ https://issues.apache.org/jira/browse/PROTON-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1264: Labels: close-pending (was: ) > on_receiver_open event after close > -- > > Key: PROTON-1264 > URL: https://issues.apache.org/jira/browse/PROTON-1264 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > Labels: close-pending > Attachments: slow_attach > > > If the peer is slow to respond with its attach frame from a receiver open and > the initiator gives up and closes the receiver, the eventual attach frame > from the peer will generate an on_receiver_open() event. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1312) BlockingConnection leaks Proton-C memory
[ https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1312: Fix Version/s: 0.17.0 > BlockingConnection leaks Proton-C memory > > > Key: PROTON-1312 > URL: https://issues.apache.org/jira/browse/PROTON-1312 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.15.0 >Reporter: Cliff Jansen > Labels: leak, reproducer > Fix For: 0.17.0 > > Attachments: ml8.py > > > The attached program leaks the underlying connection (the C proton > object) associated with the BlockingConnection on each loop iteration > on proton 0.9 as used by Satellite. Without the receiver, it cleans > up fine. > On master, the program leaks both the reactor and the connection > associated with the BlockingConnection for each loop. The receiver > creation can be commented out and it still leaks both objects. > Other objects may leak too (presumably session), but I have not > examined further. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-889) Thread safe pn_io_t
[ https://issues.apache.org/jira/browse/PROTON-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-889: --- Labels: close-pending (was: ) > Thread safe pn_io_t > --- > > Key: PROTON-889 > URL: https://issues.apache.org/jira/browse/PROTON-889 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Cliff Jansen > Labels: close-pending > > It has been pointed out before that the pn_io API does not allow thread safe > use of > pn_error_t *pn_io_error(pn_io_t *io) > bool pn_wouldblock(pn_io_t *io); > For the moment, this JIRA serves as a reminder. I am hesitant to propose a > specific solution without a solid outline of an actual implementation using > it. We have the following use cases: > - moderately scalable single threaded implementation using Proton's > selector/selectable classes > - custom selector/IO just using the Proton engine (i.e. Dispatch, Qpid C++ > client/broker, no pn_io at all) > - external loop with direct calls to pn_io methods > The ultimate performance would come from the custom IO route optimized for > the particular work load using engine primitives. But given that Proton is > (at least mostly) thread safe on a per socket/connection basis (i.e. use by > Dispatch), it would seem that additional parallelization could be achieved > with various API changes (not just to pn_io methods). > So, again with the disclaimer that an actual implementation should drive > this, some options could be > > 6 new calls > pn_io_(io, selectable, buf, len); (send/recv/write/read) > pn_selectable_wouldblock(selectable); > pn_selectable_error(selectable); > 4 new calls > pn_io_(io, socket, buf, len, bool *wouldblock, pn_error_t *err) > Assuming the existing single threaded use cases should not be burdened with > locking overhead, other related changes might include customized incref and > decref functions per pn_class_t, external custom collectors (and surely more). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-584) Proton-c transport reserves large buffers for brief use
[ https://issues.apache.org/jira/browse/PROTON-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-584: --- Fix Version/s: 0.17.0 > Proton-c transport reserves large buffers for brief use > --- > > Key: PROTON-584 > URL: https://issues.apache.org/jira/browse/PROTON-584 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.8 >Reporter: Cliff Jansen > Fix For: 0.17.0 > > > When processing transfer frames for incoming messages, Proton requires a > temporary buffer holding the whole transfer frame briefly in contiguous space > in the transport before moving it to the engine proper which holds the > content in a separate memory area. > pn_transport_capacity grows the buffer in the non-ssl case > (transport->input_buf), and openssl.c largely duplicates the code (including > the comment about "no limit") for ssl->inbuf for ssl connections. > Either way, a large message will trigger reserving a similarly large buffer > for the rest of the life of the connection. > Is it necessary for the transport to buffer the whole message body and hang > on to that memory? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-837) C reactor event samples, including external loop (libuv)
[ https://issues.apache.org/jira/browse/PROTON-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-837: --- Labels: close-pending (was: ) > C reactor event samples, including external loop (libuv) > > > Key: PROTON-837 > URL: https://issues.apache.org/jira/browse/PROTON-837 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: close-pending > > Provide sample programs to use the reactor event model. Also provide > an optional external loop "driver" to demonstrate the use of external > event/io loops with Proton. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-348) Tests and examples need some platform helper functions
[ https://issues.apache.org/jira/browse/PROTON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-348: --- Labels: close-pending (was: ) > Tests and examples need some platform helper functions > -- > > Key: PROTON-348 > URL: https://issues.apache.org/jira/browse/PROTON-348 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.5 > Environment: All >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: close-pending > > New functionality in examples and tests require platform neutral basic > functionality such as getopt (again) and time. The existing code doesn't > build on Windows. Presumably additional such functionality will be needed in > the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1149) [Python binding] Python float values +inf and -inf do not work correctly as 32-bit AMQP float values on RHEL7
[ https://issues.apache.org/jira/browse/PROTON-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1149: Fix Version/s: Future > [Python binding] Python float values +inf and -inf do not work correctly as > 32-bit AMQP float values on RHEL7 > - > > Key: PROTON-1149 > URL: https://issues.apache.org/jira/browse/PROTON-1149 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.13.0 >Reporter: Kim van der Riet > Fix For: Future > > > When run on RHEL 7, the 32-bit floating point values +inf (0x7f80) and > -inf (0xff80) cause a failure in the swig interface: > {{OverflowError: in method 'pn_data_put_float', argument 2 of type 'float'}} > Interestingly, the test values +NaN (0x7fc0) and -NaN(0xffc0) which > are also a part of the same test, work ok. > This error does not occur on Fedora 22. > System details: > Red Hat Enterprise Linux Server release 7.2 (Maipo) > kernel: 3.10.0-327.el7.x86_64 > Python: 2.7.5 (default, Oct 11, 2015 17:47:16) > SWIG version 2.0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-251) When adding elements to an array, elements of a different type should cause an error
[ https://issues.apache.org/jira/browse/PROTON-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-251: --- Fix Version/s: Future > When adding elements to an array, elements of a different type should cause > an error > > > Key: PROTON-251 > URL: https://issues.apache.org/jira/browse/PROTON-251 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Darryl L. Pierce >Assignee: Kim van der Riet > Fix For: Future > > > If you create an array, you need to specify the type of elements for the > array. Then it seems logical that adding an element of a different type > should cause an error condition to occur and the element should not go into > the array. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1160) [Python binding] decimal32 and decimal64 are sent byte reversed
[ https://issues.apache.org/jira/browse/PROTON-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1160: Fix Version/s: 0.17.0 > [Python binding] decimal32 and decimal64 are sent byte reversed > --- > > Key: PROTON-1160 > URL: https://issues.apache.org/jira/browse/PROTON-1160 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.17.0 > > > When sending {{decimal32}} and {{decimal64}} types to or from the Python > binding, the byte order of the numbers are reversed. This does not apply to > the {{decimal128}} type. > It is noteworthy that this bug was exposed by qpid-interop-test when run > against the C++ binding. In C++, these types are all based on a byte array, > whereas in the Python binding, {{decimal32}} and {{decimal64}} are derived > from Python types {{int}} and {{long}} respectively, while {{decimal128}} is > derived from Python type {{bytes}}. > Decimal32: > {noformat} > sent:['0x', '0x40490fdb', '0xc02df854', '0xff7f'] > received:['0x', '0xdb0f4940', '0x54f82dc0', '0x7fff'] > {noformat} > Decimal64: > {noformat} > sent:['0x', '0x400921fb54442eea', '0xc005bf0a8b145fcf', > '0xffef'] > received:['0x', '0xea2e4454fb210940', '0xcf5f148b0abf05c0', > '0xefff'] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1091) [Python binding] AMQP null type not sent on wire according to AMQP specification
[ https://issues.apache.org/jira/browse/PROTON-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1091: Fix Version/s: 0.17.0 > [Python binding] AMQP null type not sent on wire according to AMQP > specification > > > Key: PROTON-1091 > URL: https://issues.apache.org/jira/browse/PROTON-1091 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Kim van der Riet >Assignee: Kim van der Riet > Fix For: 0.17.0 > > > When sending AMQP type null as the content of a message, the Python binding > sends the message with no body at all, and similarly interprets a no-body > AMQP type message as a null type. This violates the AMQP 1.0 specification on > two counts: > * A body MUST be present and be one of three types (section 3.2); > * When sending an AMQP null type, there is an assigned AMQP type code (0x40) > which should be used. > This causes interoperability issues with other clients. For example, the C++ > client can't send a null type to a python client without a failure (or _visa > versa_). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-40) Detect and report errors for accessing settled deliveries
[ https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-40: -- Labels: api close-pending (was: api) > Detect and report errors for accessing settled deliveries > - > > Key: PROTON-40 > URL: https://issues.apache.org/jira/browse/PROTON-40 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Priority: Minor > Labels: api, close-pending > > If a proton client calls pn_disposition on more than one received delivery > between the sending of disposition frames, the next disposition frame will > reference only the first message in the batch. > Ref: This code fragment from pn_post_disp which uses the same value for > first and last id: > return pn_post_frame(transport->disp, ssn_state->local_channel, > "DL[oIIo?DL[]]", DISPOSITION, > link->endpoint.type == RECEIVER, state->id, > state->id, > delivery->local_settled, > (bool)code, code); > The result of this is that dispositions for messages are lost and senders > hang if there are credit windows of greater than one. It would be ok, but > inefficient, to send multiple singleton dispositions. In fact, proton simply > skips one or more disposition so the settlement of messages is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-40) Detect and report errors for accessing settled deliveries
[ https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-40: -- Summary: Detect and report errors for accessing settled deliveries (was: detect and report errors for accessing settled deliveries) > Detect and report errors for accessing settled deliveries > - > > Key: PROTON-40 > URL: https://issues.apache.org/jira/browse/PROTON-40 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Priority: Minor > Labels: api, close-pending > > If a proton client calls pn_disposition on more than one received delivery > between the sending of disposition frames, the next disposition frame will > reference only the first message in the batch. > Ref: This code fragment from pn_post_disp which uses the same value for > first and last id: > return pn_post_frame(transport->disp, ssn_state->local_channel, > "DL[oIIo?DL[]]", DISPOSITION, > link->endpoint.type == RECEIVER, state->id, > state->id, > delivery->local_settled, > (bool)code, code); > The result of this is that dispositions for messages are lost and senders > hang if there are credit windows of greater than one. It would be ok, but > inefficient, to send multiple singleton dispositions. In fact, proton simply > skips one or more disposition so the settlement of messages is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-40) detect and report errors for accessing settled deliveries
[ https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-40: -- Labels: api (was: ) > detect and report errors for accessing settled deliveries > - > > Key: PROTON-40 > URL: https://issues.apache.org/jira/browse/PROTON-40 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Priority: Minor > Labels: api, close-pending > > If a proton client calls pn_disposition on more than one received delivery > between the sending of disposition frames, the next disposition frame will > reference only the first message in the batch. > Ref: This code fragment from pn_post_disp which uses the same value for > first and last id: > return pn_post_frame(transport->disp, ssn_state->local_channel, > "DL[oIIo?DL[]]", DISPOSITION, > link->endpoint.type == RECEIVER, state->id, > state->id, > delivery->local_settled, > (bool)code, code); > The result of this is that dispositions for messages are lost and senders > hang if there are credit windows of greater than one. It would be ok, but > inefficient, to send multiple singleton dispositions. In fact, proton simply > skips one or more disposition so the settlement of messages is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-40) detect and report errors for accessing settled deliveries
[ https://issues.apache.org/jira/browse/PROTON-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-40: -- Summary: detect and report errors for accessing settled deliveries (was: detect and report errors for acessing settled deliveries) > detect and report errors for accessing settled deliveries > - > > Key: PROTON-40 > URL: https://issues.apache.org/jira/browse/PROTON-40 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Priority: Minor > > If a proton client calls pn_disposition on more than one received delivery > between the sending of disposition frames, the next disposition frame will > reference only the first message in the batch. > Ref: This code fragment from pn_post_disp which uses the same value for > first and last id: > return pn_post_frame(transport->disp, ssn_state->local_channel, > "DL[oIIo?DL[]]", DISPOSITION, > link->endpoint.type == RECEIVER, state->id, > state->id, > delivery->local_settled, > (bool)code, code); > The result of this is that dispositions for messages are lost and senders > hang if there are credit windows of greater than one. It would be ok, but > inefficient, to send multiple singleton dispositions. In fact, proton simply > skips one or more disposition so the settlement of messages is incomplete. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-285) MessengerTest#testSendBogus fails against proton-c
[ https://issues.apache.org/jira/browse/PROTON-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-285: --- Labels: close-pending test-failure (was: ) > MessengerTest#testSendBogus fails against proton-c > -- > > Key: PROTON-285 > URL: https://issues.apache.org/jira/browse/PROTON-285 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Keith Wall >Assignee: Rafael H. Schloming > Labels: close-pending, test-failure > > As highlighted in the following mailing list post: > http://qpid.2158936.n2.nabble.com/Continually-failing-MessengerTests-WAS-NPE-from-MessengerTests-since-rev-1460174-tt7590662.html -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-296) need a new message status
[ https://issues.apache.org/jira/browse/PROTON-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-296: --- Labels: api close-pending (was: ) > need a new message status > - > > Key: PROTON-296 > URL: https://issues.apache.org/jira/browse/PROTON-296 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: michael goulish > Labels: api, close-pending > > Currently, if a receiver settles messages rather than accepting or rejecting, > the status that the sender sees is PENDING. That would seem to suggest that > it might change in the future, so the sender might keep checking back to see > if the status changes. But the status isn't going to change. > The only other available status for this situation is UNKNOWN, which has the > same problem. > Seems like we could use a separate status integer, like SETTLED, that means > "the other side doesn't care, and that's final." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-312) [Proton-J] should Closed-Closed Sessions and Links be returned from Connection.sessionHead() and Connection.linkHead()
[ https://issues.apache.org/jira/browse/PROTON-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-312: --- Labels: close-pending (was: ) > [Proton-J] should Closed-Closed Sessions and Links be returned from > Connection.sessionHead() and Connection.linkHead() > -- > > Key: PROTON-312 > URL: https://issues.apache.org/jira/browse/PROTON-312 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.4 >Reporter: Robbie Gemmell >Assignee: Philip Harvey > Labels: close-pending > > When using Connection.sessionHead() and Connection.linkHead(), should > CLOSED-CLOSED Sessions and Links be returned? It appears that they are for > Sessions, but are not for Links, which is at best inconsistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-86) Automatically generate a message id on creation or clear
[ https://issues.apache.org/jira/browse/PROTON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-86: -- Fix Version/s: Future > Automatically generate a message id on creation or clear > > > Key: PROTON-86 > URL: https://issues.apache.org/jira/browse/PROTON-86 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: William Henry > Fix For: Future > > > Useful to have an automatically generated unique id for a message. That way > users have one by default but can always set it explicitly using set_id if > needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-86) Automatically generate a message id on creation or clear
[ https://issues.apache.org/jira/browse/PROTON-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-86: -- Issue Type: Improvement (was: Bug) > Automatically generate a message id on creation or clear > > > Key: PROTON-86 > URL: https://issues.apache.org/jira/browse/PROTON-86 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: William Henry > > Useful to have an automatically generated unique id for a message. That way > users have one by default but can always set it explicitly using set_id if > needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-338) Support distributed transactions
[ https://issues.apache.org/jira/browse/PROTON-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-338: --- Labels: close-pending (was: ) > Support distributed transactions > - > > Key: PROTON-338 > URL: https://issues.apache.org/jira/browse/PROTON-338 > Project: Qpid Proton > Issue Type: Wish > Components: proton-j >Affects Versions: 0.5 >Reporter: Kim Palko > Labels: close-pending > > Distributed transactions should be supported with proton-j. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-220) Create a set of "glass box" tests to quantify the performance of the proton codebase.
[ https://issues.apache.org/jira/browse/PROTON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-220: --- Labels: perf testing (was: perfomance test) > Create a set of "glass box" tests to quantify the performance of the proton > codebase. > - > > Key: PROTON-220 > URL: https://issues.apache.org/jira/browse/PROTON-220 > Project: Qpid Proton > Issue Type: Test > Components: proton-c, proton-j >Reporter: Ken Giusti >Assignee: michael goulish > Labels: perf, testing > Fix For: 0.17.0 > > > The goal of these tests would be to detect any performance degradation > inadvertently introduced during development. These tests would not be > intended to provide any metrics regarding the "real world" behavior of > proton-based applications. Rather, these tests are targeted for use by the > proton developers to help gauge the effect their code changes may have on > performance. > These tests should require no special configuration or setup in order to run. > It should be easy to run these test as part of the development process. The > intent would be to have developer run the tests prior to making any code > changes, and record the metrics for comparison against the results obtained > after making changes to the code base. > As described by Rafi: > "I think it would be good to include some performance metrics that isolate > the various components of proton. For example having a metric that simply > repeatedly encodes/decodes a message would be quite useful in isolating the > message implementation. Setting up two engines in memory and using them to > blast zero sized messages back and forth as fast as possible would tell us > how much protocol overhead the engine is adding. Using the codec directly > to encode/decode data would also be a useful measure. Each of these would > probably want to have multiple profiles, different message content, > different acknowledgement/flow control patterns, and different kinds of > data. > I think breaking out the different dimensions of the implementation as > above would provide a very useful tool to run before/after any performance > sensitive changes to detect and isolate regressions, or to test potential > improvements." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-144: --- Labels: perf (was: message performance) > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar > Labels: perf > Fix For: 0.17.0 > > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024] > [0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61a840:1] <- FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61a840:1] -> TRANSFER @20
[jira] [Updated] (PROTON-1253) PHP client using C API send no empty frames - ActiveMQ broker drops the connection due to Inactivity after 60 seconds
[ https://issues.apache.org/jira/browse/PROTON-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1253: Fix Version/s: (was: 0.17.0) > PHP client using C API send no empty frames - ActiveMQ broker drops the > connection due to Inactivity after 60 seconds > - > > Key: PROTON-1253 > URL: https://issues.apache.org/jira/browse/PROTON-1253 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0, 0.13.0 > Environment: Linux yuriy-Aspire-E5-573G 4.2.0-18-generic #22-Ubuntu > SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Yuriy Yakubskiy > Labels: messenger, patch, php-proton > Attachments: > qpid-proton-0.13.0_messenger_set_idle_timeout_patch.tar.gz > > > Dear developers, > Could you please, clarify the following issue. > PHP client disconnected after no data message in the queue for 60 seconds. > Have client frame trace enabled (PN_TRACE_FRM=true) > No active frame sent by the client in order to prevent being disconnected by > ActiveMQ InactivityMonitor > Please advice, is there any way of setting heartbeats for the PHP client. > Please find, frames trace below. > Kind Regards, > Yuriy > 2016-07-11 14:05:46 > [0x2af58f0]: -> AMQP > [0x2af58f0]:0 -> @open(16) > [container-id="68426F2E-012E-4A64-BE2E-1E5355B4B022", hostname="0.0.0.0", > channel-max=32767] > [0x2af58f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, > outgoing-window=2147483647] > [0x2af58f0]:0 -> @attach(18) [name="first-test-queue", handle=0, role=true, > snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) > [address="first-test-queue", durable=0, timeout=0, dynamic=false], > target=@target(41) [address="first-test-queue", durable=0, timeout=0, > dynamic=false], initial-delivery-count=0] > [0x2af58f0]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, > outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1024, > drain=false] > [0x2af58f0]: <- AMQP > [0x2af58f0]:0 <- @open(16) [container-id="", hostname="", > max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, > offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], > properties={:product="ActiveMQ", :platform="Java/1.7.0_101", > :"topic-prefix"="topic://", :"queue-prefix"="queue://", :version="5.12.0"}] > [0x2af58f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, > incoming-window=0, outgoing-window=0, handle-max=65535] > [0x2af58f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, > next-outgoing-id=1, outgoing-window=0] > [0x2af58f0]:0 <- @attach(18) [name="first-test-queue", handle=0, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > [address="first-test-queue"], target=@target(41) > [address="first-test-queue"], incomplete-unsettled=false, > initial-delivery-count=0] > [0x2af58f0]:0 <- @close(24) [error=@error(29) > [condition=:"amqp:resource-limit-exceeded", description="local-idle-timeout > expired"]] > [0x2af58f0]: <- EOS > [0x2af58f0]:0 -> @close(24) [] > [0x2af58f0]: -> EOS > 2016-07-11 14:06:46 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-782) pn_messenger_start always calls pn_messenger_resolve
[ https://issues.apache.org/jira/browse/PROTON-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-782: --- Fix Version/s: (was: 0.17.0) > pn_messenger_start always calls pn_messenger_resolve > > > Key: PROTON-782 > URL: https://issues.apache.org/jira/browse/PROTON-782 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: David McCann > Labels: easyfix, messenger, patch > Attachments: check_routes_only_when_specified.patch > > Original Estimate: 2m > Remaining Estimate: 2m > > Code was added to pn_messenger_start in 0.8 to allow a resolve to take place > immediately if PN_FLAGS_CHECK_ROUTES is set. > Unfortunately the check for the flag is incorrect, causing the resolve to > always take place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-761) 100% CPU with multiple subscriptions
[ https://issues.apache.org/jira/browse/PROTON-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-761: --- Fix Version/s: (was: 0.17.0) > 100% CPU with multiple subscriptions > > > Key: PROTON-761 > URL: https://issues.apache.org/jira/browse/PROTON-761 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Fabien CHEVALIER > Labels: messenger, reproducer > Attachments: infinite-loop.c > > > Calling pn_messenger_subscribe() twice (which seems to be perfectly valid) > can result in proton hanging at 100% cpu, when one of the two sources is > unreachable. > To reproduce, start the attached test case against a pristine ActiveMQ copy > (./bin/activemq console). Proton will go nuts when trying to connect to the > unavailable amqp://localhost:15672/ganymede instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl
[ https://issues.apache.org/jira/browse/PROTON-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-252: --- Fix Version/s: (was: 0.17.0) > Reduce visibiliy of constructors for classes that should be created by > factories eg MessageImpl > --- > > Key: PROTON-252 > URL: https://issues.apache.org/jira/browse/PROTON-252 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.4 >Reporter: Philip Harvey >Assignee: Philip Harvey >Priority: Minor > Labels: api, close-pending > > These constructors are currently public but deprecated, and should be made > package-private where possible to enforce the use of the factories instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault
[ https://issues.apache.org/jira/browse/PROTON-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-158: --- Fix Version/s: (was: 0.17.0) > detach with invalid handle causes segfault > -- > > Key: PROTON-158 > URL: https://issues.apache.org/jira/browse/PROTON-158 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Minor > Labels: close-pending, crash > > I.e. a detach where the handle was not previously used in an attach -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-970) SASL options for setting path and name should not be transport-specific
[ https://issues.apache.org/jira/browse/PROTON-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-970: --- Fix Version/s: (was: 0.16.0) > SASL options for setting path and name should not be transport-specific > --- > > Key: PROTON-970 > URL: https://issues.apache.org/jira/browse/PROTON-970 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross > Labels: close-pending > > Both pn_sasl_config_name and pn_sasl_config_path take a pn_sasl_t object as > an argument, suggesting that different transports may use different > configurations. > Cyrus SASL treats both the path and (server) name as per-process settings. > The above methods in pn_sasl should reflect this scope and not use a > pn_sasl_t as an argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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 ] Justin Ross updated PROTON-287: --- Fix Version/s: (was: 0.17.0) > 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, close-pending, patch > > 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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1057) Windows SChannel SSL test failure
[ https://issues.apache.org/jira/browse/PROTON-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1057: Fix Version/s: Future > Windows SChannel SSL test failure > - > > Key: PROTON-1057 > URL: https://issues.apache.org/jira/browse/PROTON-1057 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.12.0 > Environment: Windows only. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > Fix For: Future > > > This problem started since PROTON-1048 which did not touch the Proton-C > SChannel related code - it just tweaked the test infrastructure to use > alternate certificate formats for Windows. > The proton_tests.ssl.SslTest.test_server_hostname_authentication test > randomly crashes on Windows, presumably from some memory corruption > somewhere. It often runs fine. Seems to happen more frequently on some > systems than others. Not yet seen on a 64 bit build. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (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:all-tabpanel ] Justin Ross updated PROTON-824: --- Assignee: Cliff Jansen > 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 >Assignee: Cliff Jansen > Labels: close-pending, test-failure, windows > > {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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-840) Fix Windows components to use transport logging
[ https://issues.apache.org/jira/browse/PROTON-840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-840: --- Fix Version/s: 0.17.0 > Fix Windows components to use transport logging > --- > > Key: PROTON-840 > URL: https://issues.apache.org/jira/browse/PROTON-840 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8, 0.9 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: windows > Fix For: 0.17.0 > > > Posix implemented new centralized logging. Windows needs to catch up. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (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:all-tabpanel ] Justin Ross updated PROTON-824: --- Labels: test-failure windows (was: windows) > 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 > Labels: close-pending, test-failure, windows > > {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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (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:all-tabpanel ] Justin Ross updated PROTON-824: --- Labels: close-pending test-failure windows (was: test-failure windows) > 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 >Assignee: Cliff Jansen > Labels: close-pending, test-failure, windows > > {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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-789) Lots of Deprecation Warnings on OSX
[ https://issues.apache.org/jira/browse/PROTON-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-789: --- Labels: close-pending osx (was: osx) > Lots of Deprecation Warnings on OSX > --- > > Key: PROTON-789 > URL: https://issues.apache.org/jira/browse/PROTON-789 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 > Environment: Darwin gethsemane.local 14.0.0 Darwin Kernel Version > 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 > x86_64 >Reporter: Weston M. Price >Priority: Minor > Labels: close-pending, osx > Attachments: proton-build-osx.txt > > > Building proton-c on OS X 10.10.1 (Yosemite) gives quite a few deprecation > warnings, primarily in the SSL libraries. I have attached a file showing a > typical build run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages
[ https://issues.apache.org/jira/browse/PROTON-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-766: --- Fix Version/s: 0.17.0 > Proton-c Windows IO prints misleading error messages > > > Key: PROTON-766 > URL: https://issues.apache.org/jira/browse/PROTON-766 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 > Environment: Windows Server 2012 R2 > Examples messaging c recv >Reporter: Chuck Rolke >Assignee: Cliff Jansen > Labels: windows > Fix For: 0.17.0 > > > Connecting to a port that is not open. > Windows: > {noformat} > > send -a [::1] > recv: No error > [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch: > '' > CONNECTION ERROR connection aborted (remote) > send: No error > {noformat} > The same action on Linux: > {noformat} > > ./send -a [::1] > recv: Connection refused > [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch: > Insufficient data to determine protocol [''] (connection aborted) > CONNECTION ERROR connection aborted (remote) > send: Broken pipe > {noformat} > The Linux messages are more useful and indicate the precise error conditions. > The Windows messages show recv: and send: with 'No error' and that is not the > case. > The same error message is displayed for IPv4 and IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-766) Proton-c Windows IO prints misleading error messages
[ https://issues.apache.org/jira/browse/PROTON-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-766: --- Assignee: Cliff Jansen > Proton-c Windows IO prints misleading error messages > > > Key: PROTON-766 > URL: https://issues.apache.org/jira/browse/PROTON-766 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 > Environment: Windows Server 2012 R2 > Examples messaging c recv >Reporter: Chuck Rolke >Assignee: Cliff Jansen > Labels: windows > Fix For: 0.17.0 > > > Connecting to a port that is not open. > Windows: > {noformat} > > send -a [::1] > recv: No error > [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch: > '' > CONNECTION ERROR connection aborted (remote) > send: No error > {noformat} > The same action on Linux: > {noformat} > > ./send -a [::1] > recv: Connection refused > [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch: > Insufficient data to determine protocol [''] (connection aborted) > CONNECTION ERROR connection aborted (remote) > send: Broken pipe > {noformat} > The Linux messages are more useful and indicate the precise error conditions. > The Windows messages show recv: and send: with 'No error' and that is not the > case. > The same error message is displayed for IPv4 and IPv6. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-151) Have the python interface use dynamic proxies to the engine impl objects so to ensure that only public interface methods are being used by the python tests.
[ https://issues.apache.org/jira/browse/PROTON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-151: --- Fix Version/s: Future > Have the python interface use dynamic proxies to the engine impl objects so > to ensure that only public interface methods are being used by the python > tests. > > > Key: PROTON-151 > URL: https://issues.apache.org/jira/browse/PROTON-151 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > Labels: patch, testing > Fix For: Future > > Attachments: PROTON-151.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-186) Message encode should always return the number of bytes needed to fully encode the message
[ https://issues.apache.org/jira/browse/PROTON-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-186: --- Labels: close-pending patch (was: patch) > Message encode should always return the number of bytes needed to fully > encode the message > -- > > Key: PROTON-186 > URL: https://issues.apache.org/jira/browse/PROTON-186 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Hiram Chirino > Labels: close-pending, patch > Attachments: PROTON-186v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-391) Proton perl binding fails to build on OS X
[ https://issues.apache.org/jira/browse/PROTON-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-391: --- Fix Version/s: Future > Proton perl binding fails to build on OS X > -- > > Key: PROTON-391 > URL: https://issues.apache.org/jira/browse/PROTON-391 > Project: Qpid Proton > Issue Type: Bug > Components: perl-binding > Environment: OS X >Reporter: Hiram Chirino > Labels: osx > Fix For: Future > > > [ 71%] Building C object > proton-c/bindings/perl/CMakeFiles/cproton_perl.dir/perlPERL_wrap.c.o > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:26, > from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31, > from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:53: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_equals’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/object.h:65: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_list_remove’ > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:31, > from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:73: error: > expected specifier-qualifier-list before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:111: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_next’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:112: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_prev’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:113: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_enter’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:114: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘pn_data_exit’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:115: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_lookup’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:126: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:129: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:154: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_array_described’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:156: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_described’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:157: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_is_null’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:158: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_get_bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/codec.h:187: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_data_restore’ > In file included from > /Users/chirino/sandbox/qpid-proton/proton-c/bindings/perl/perlPERL_wrap.c:1574: > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:428: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_transport_quiesced’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:445: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_is_sender’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:446: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_is_receiver’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:455: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_link_advance’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:500: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_terminus_is_dynamic’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:501: > error: expected declaration specifiers or ‘...’ before ‘bool’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:519: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_delivery_settled’ > /Users/chirino/sandbox/qpid-proton/proton-c/include/proton/engine.h:521: > error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before > ‘pn_delivery_partial’ > /Users/chirino/
[jira] [Updated] (PROTON-390) Suppress or Fix the warnings openssl.c produce
[ https://issues.apache.org/jira/browse/PROTON-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-390: --- Fix Version/s: Future > Suppress or Fix the warnings openssl.c produce > -- > > Key: PROTON-390 > URL: https://issues.apache.org/jira/browse/PROTON-390 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Environment: OS X >Reporter: Hiram Chirino > Labels: osx > Fix For: Future > > > openssl.c produces lots of warnings. > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘_log_ssl_error’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:165: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:167: warning: > ‘ERR_error_string_n’ is deprecated (declared at > /usr/include/openssl/err.h:280) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:169: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘ssl_failed’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:189: warning: > ‘ERR_get_error’ is deprecated (declared at /usr/include/openssl/err.h:266) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:191: warning: > ‘ERR_error_string_n’ is deprecated (declared at > /usr/include/openssl/err.h:280) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘verify_callback’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:257: warning: > ‘X509_STORE_CTX_get_error_depth’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:453) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:261: warning: > ‘X509_STORE_CTX_get_current_cert’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:454) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: > ‘X509_STORE_CTX_get_ex_data’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:450) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:262: warning: > ‘SSL_get_ex_data_X509_STORE_CTX_idx’ is deprecated (declared at > /usr/include/openssl/ssl.h:1601) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:268: warning: > ‘SSL_get_ex_data’ is deprecated (declared at /usr/include/openssl/ssl.h:1587) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:285: warning: > ‘X509_get_ext_d2i’ is deprecated (declared at > /usr/include/openssl/x509.h:1151) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:287: warning: > ‘sk_num’ is deprecated (declared at /usr/include/openssl/stack.h:81) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:290: warning: > ‘sk_value’ is deprecated (declared at /usr/include/openssl/stack.h:82) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:295: warning: > ‘ASN1_STRING_to_UTF8’ is deprecated (declared at > /usr/include/openssl/asn1.h:981) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:299: warning: > ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:308: warning: > ‘X509_get_subject_name’ is deprecated (declared at > /usr/include/openssl/x509.h:1013) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:310: warning: > ‘X509_NAME_get_index_by_NID’ is deprecated (declared at > /usr/include/openssl/x509.h:1105) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:311: warning: > ‘X509_NAME_get_entry’ is deprecated (declared at > /usr/include/openssl/x509.h:1108) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:312: warning: > ‘X509_NAME_ENTRY_get_data’ is deprecated (declared at > /usr/include/openssl/x509.h:1130) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:315: warning: > ‘ASN1_STRING_to_UTF8’ is deprecated (declared at > /usr/include/openssl/asn1.h:981) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:319: warning: > ‘CRYPTO_free’ is deprecated (declared at /usr/include/openssl/crypto.h:480) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:329: warning: > ‘X509_STORE_CTX_set_error’ is deprecated (declared at > /usr/include/openssl/x509_vfy.h:452) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c: In function > ‘get_dh2048’: > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:371: warning: > ‘DH_new’ is deprecated (declared at /usr/include/openssl/dh.h:184) > /Users/chirino/sandbox/qpid-proton/proton-c/src/ssl/openssl.c:372: warning: > ‘BN_bin2bn’ is deprecated (declared at /usr/include/open
[jira] [Updated] (PROTON-21) Extract the logical AMQP frame handling to an AbstractConnectionHandler
[ https://issues.apache.org/jira/browse/PROTON-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-21: -- Fix Version/s: 0.17.0 > Extract the logical AMQP frame handling to an AbstractConnectionHandler > --- > > Key: PROTON-21 > URL: https://issues.apache.org/jira/browse/PROTON-21 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Hiram Chirino >Assignee: Rob Godfrey > Labels: api, patch > Fix For: 0.17.0 > > Attachments: PROTON-21-v3.patch > > > Right now all the logic that handles logical AMQP frame events is inside of > the TransportImpl class. That interface only allows you to pump bytes in and > out of the connection. If we extract all the handling logic to an > AbstractConnectionHandler you should be able to use that directly and pump > logical AMQP frames and avoid the frame encoding/decoding phase that the > TransportImpl also does. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-598) CProton python binding fails to build Windows debug configuration
[ https://issues.apache.org/jira/browse/PROTON-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-598: --- Labels: close-pending windows (was: windows) > CProton python binding fails to build Windows debug configuration > - > > Key: PROTON-598 > URL: https://issues.apache.org/jira/browse/PROTON-598 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Windows, Python 2.6.1 >Reporter: Chuck Rolke > Labels: close-pending, windows > > cpython fails to link with file python26_d.lib not found. > The issue here is that the windows installer for python does not install the > debug versions (identified by the _d suffix) of the python libraries. Wisdom > from the web suggests either to build your own debug python or to debug using > a release build. > Links using the RelWithDebInfo work just fine and I can make progress running > ctest. Just a heads up for anyone who wants to run ctest with Debug builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-599) Visual Studio warnings - enumeration update
[ https://issues.apache.org/jira/browse/PROTON-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-599: --- Labels: close-pending windows (was: windows) > Visual Studio warnings - enumeration update > --- > > Key: PROTON-599 > URL: https://issues.apache.org/jira/browse/PROTON-599 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 > Environment: Visual Studio 2008, 2010, 2012, 2013 >Reporter: Chuck Rolke > Labels: close-pending, windows > Attachments: vs-proton-warnings.txt > > > After suppressing the 'usual' warnings (see PROTON-546, > http://svn.apache.org/r1601010) and running some later compiler versions a > new list of errors emerges. Please see attached listing for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
[ https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-546: --- Fix Version/s: 0.17.0 > C++ Windows warnings: conversions and possible loss of data > --- > > Key: PROTON-546 > URL: https://issues.apache.org/jira/browse/PROTON-546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Andrew Stitcher > Labels: windows > Fix For: 0.17.0 > > Attachments: PROTON-546-size-warnings.txt > > > Windows has other warnings similar to PROTON-545, especially during 64-bit > builds. > See attached file for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-409) [proton-c] Windows .dll does not have embedded version resource
[ https://issues.apache.org/jira/browse/PROTON-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-409: --- Labels: close-pending windows (was: windows) > [proton-c] Windows .dll does not have embedded version resource > > > Key: PROTON-409 > URL: https://issues.apache.org/jira/browse/PROTON-409 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: close-pending, windows > > Windows output objects may contain a version resource that allow the build > engineer to tag files with file and product resource numbers. Support for > this feature is missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-407) [proton-c] Windows install does not install .lib nor .pdb files
[ https://issues.apache.org/jira/browse/PROTON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-407: --- Labels: close-pending windows (was: windows) > [proton-c] Windows install does not install .lib nor .pdb files > --- > > Key: PROTON-407 > URL: https://issues.apache.org/jira/browse/PROTON-407 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Chuck Rolke > Labels: close-pending, windows > > In current trunk building the INSTALL project in VS2010 does not place the > qpid-proton.lib, qpid-proton.pdb files into the install area. Consequently > consumers using an installed kit are unable to link to the qpid-proton > library. > In a dev environment the files are available in the build area as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-363) recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error 11004
[ https://issues.apache.org/jira/browse/PROTON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-363: --- Labels: close-pending windows (was: windows) > recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error > 11004 > - > > Key: PROTON-363 > URL: https://issues.apache.org/jira/browse/PROTON-363 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 > Environment: Windows XP, Visual Studio 2010 >Reporter: Jakub Scholz > Labels: close-pending, windows > > I build the proton-c library on Windows XP using Visual Studio 10. > Afterwards, when trying to run the recv.exe and send.exe examples, the > recv.exe always fails with: > > recv.exe amqp://~0.0.0.0:5672 > getnameinfo: The requested name is valid and was found in the database, but > it does not have the correct associated data being resolved for. > It doesn't fail immediately after start but only when I attempt to connect > with send.exe. As a result, the Proton seems to be pretty much not working on > my machine. > --- > The error seems to originate from the function pn_listener_accept in driver.c > and it translates to WSANO_DATA error / error 11004. I did some digging > around and playing with the getnameinfo function and it seems to me, that the > problem is that the getnameinfo function is unable to recognize the service > name based on the port number. And - according to MSDN > (http://msdn.microsoft.com/en-us/library/windows/desktop/ms738532(v=vs.85).aspx) > - that on Windows Server 2003 and earlier results in error (on Windows Vista > and later this works fine). > If I add a flag NI_NUMERICSERV to the getnameinfo call: > code = getnameinfo((struct sockaddr *) &addr, addrlen, host, 1024, serv, 64, > NI_NUMERICSERV) > it will not return an error but return success and use the port number as a > service name. And with this change the recv.exe starts working fine. > However, adding this flag will on Windows Vista and higher and in Linux > probably result in the service name being always returned as a port number > and not as a name. So I'm not sure it is desired to add this flag on all > platforms. > Regards > Jakub -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-237) Porting Issue -- basename() not found in Visual Studio 2010
[ https://issues.apache.org/jira/browse/PROTON-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-237: --- Labels: build close-pending windows (was: build windows) > Porting Issue -- basename() not found in Visual Studio 2010 > --- > > Key: PROTON-237 > URL: https://issues.apache.org/jira/browse/PROTON-237 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows Visual Studio 2010 >Reporter: Mary hinton > Labels: build, close-pending, windows > > The basename() function in proton.c is not found in Visual Studio 2010. It is > in Visual Studio 2012 when the header is included. > It is only used in a printf statement and is not needed for porting to Visual > Studio 2010: > printf("Usage: %s [-h] [-c [user[:password]@]host[:port]] [-a ] [-m > ]\n", basename(argv[0])); -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-236: --- Labels: close-pending windows (was: windows) > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: close-pending, windows > Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-239) Porting Issue -- gethostname() is part of winsock library
[ https://issues.apache.org/jira/browse/PROTON-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-239: --- Labels: build close-pending windows (was: build windows) > Porting Issue -- gethostname() is part of winsock library > - > > Key: PROTON-239 > URL: https://issues.apache.org/jira/browse/PROTON-239 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: build, close-pending, windows > > In Visual Studio, gethostname() is found within the winsock library. To use > it in proton.c, we have to include the winsock header and make sure the > WSAStartup() (used to initialize the windows socket library) has already been > called by pn_driver(). > I was wondering if we could isolate the winsock header so that it is only > included in driver.c. > We could set up a new function in driver.c called pn_gethostname() whose only > function is to call gethostname(). > int pn_gethostname(char *name, int namelen) > { > return gethostname(name, namelen); > } -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-515: --- Fix Version/s: 0.17.0 > 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.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys >Assignee: Andrew Stitcher > Labels: openvms, patch > Fix For: 0.17.0 > > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, > CMakeLists.txt.patch, io.c.patch, pipe.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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-515: --- Labels: openvms patch (was: OpenVMS patch) > 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.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys >Assignee: Andrew Stitcher > Labels: openvms, patch > Fix For: 0.17.0 > > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, > CMakeLists.txt.patch, io.c.patch, pipe.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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1021) ProtonE - the Deeply Embedded ProtonC variant
[ https://issues.apache.org/jira/browse/PROTON-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1021: Labels: features patch (was: features) > ProtonE - the Deeply Embedded ProtonC variant > - > > Key: PROTON-1021 > URL: https://issues.apache.org/jira/browse/PROTON-1021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Embedded C - IAR or GCC. >Reporter: German Shepherd (PrE) >Priority: Minor > Labels: features, patch > Fix For: Future > > > Let me introduce a project I've started on 2013, when I've been tasked with a > solution on how to connect an deeply embedded Wi-Fi enabled device to MS > Azure Cloud (the plan is to connect millions of such devices). > The obvious solution was to go with ServiceBus and AMQP over TLS. Since the > embedded stuff is always written in plain C, the ProtonC is choice was > obvious. > The Proton-C typically requires a 230kB of RAM by default (most of it > dynamically allocated), which is way too much of what is physically available > in any embedded CPU of the general class (those typically end up with RAM > sizes in 192kB area) - so there is no way on how to directly use the ProtonC > on such CPUs. > *Solution?* > The outcome of my work is the *Proton-E*, based off the Proton-C library, > squeezed to run on 32kB of total RAM usage (without sacrificing any > functionality) and with a TLS on side taking addition approx. 11kB. > This allows you to fit the AMQPS into any connected embedded CPU with 128kB > of RAM (or more) - which most of the commonly available CPUs on market > provide (for a great price). > The "embedded" modifications are backwards applicable to the ProtonC, and > this is what I would like to introduce through this JIRA Ticket. > *Note* > This work was picked up by Microsoft in mid-2014, and I have personally > cooperated with them; but I have not seen any result being provided to > community, as it seems the whole effort on their side vanished (and if not, > they stopped the cooperation - so they won't have my latest sources). > Never mind, as I have the most actual source code (as I've never stopped the > development, and I do follow every commit the ProtonC community does), none > is lost. > At this moment, before the ProtonE source gets out, let me use this ticket to > provide an assurance, that indeed the ProtonE (resp. modified ProtonC) can be > used on the constrained system, and, most importantly, it is production ready > for Azure Cloud. > *ProtonE Features* > * Super-Low RAM footprint: total 32kB of RAM usage, for a AMQP message with > 1.5kB of payload > * Azure Cloud: Service Bus / eventHub - both verified (IoT Hub - very close > future, will definitely work - my colleagues cooperate with MS on this) > * Azure Cloud: SASL PLAIN over TLS (Active Directory) - verified > * Azure Cloud: SAS tokens (CBS) - verified > * No modifications to ProtonC API what-so-ever > * TCP stack, and RTOS, independent > *The ProtonE has been made to run and personally tested, by myself, with the > following setup: * > * CPUs: 32-bit ARM - Cortex M3 (STM32, SAM3), Cortex M4 (Atmel SAM4), Cortex > M7 (Atmel SAM S70/V71), I also run this on TI Sitara with embedded RTOS > * There is no reason why this would not work on any other CPUs (all is just a > plain-C code) > * RTOS: FreeRTOS/SafeRTOS; but primarily: expressLogic ThreadX > * TCP/IP stack: expressLogic NetX & NetX-Duo TCP/IP > * Comms: Broadcom WICED Wi-Fi solution > * TLS via Mocana NanoSSL (v6.0 or newer) > * TLS via MatrixSSL (3.6.1 or newer) > *SSL/TLS* > This is quite a huge memory hog, but should you understand it deeply, you > won't have trouble managing this. > Some numbers I've got: > * Handshake establishment: RAM usage peak is 30kB for TLS itself (handshake: > RSA) > * After the Handshake is done and the TLS tunnel is open: the TLS itself > requires 11kB of RAM (tunnel: AES) > I'm looking forward to have Microsoft to switch the Azure solely to ECC for > us (now they have RSA and ECC, and the server-side cert is solely RSA). Then > the handshake number will be even much more positive. > *Final words* > Once you realize that the AMQPS is the only possible scalable future for the > IoT (... hate this buzzword, BTW.), where the 95% of devices will be deeply > embedded ones, then it is obvious what role the ProtonE will play. > Best regards from CZ, > Adam N -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1021) ProtonE - the Deeply Embedded ProtonC variant
[ https://issues.apache.org/jira/browse/PROTON-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1021: Fix Version/s: Future > ProtonE - the Deeply Embedded ProtonC variant > - > > Key: PROTON-1021 > URL: https://issues.apache.org/jira/browse/PROTON-1021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Embedded C - IAR or GCC. >Reporter: German Shepherd (PrE) >Priority: Minor > Labels: features > Fix For: Future > > > Let me introduce a project I've started on 2013, when I've been tasked with a > solution on how to connect an deeply embedded Wi-Fi enabled device to MS > Azure Cloud (the plan is to connect millions of such devices). > The obvious solution was to go with ServiceBus and AMQP over TLS. Since the > embedded stuff is always written in plain C, the ProtonC is choice was > obvious. > The Proton-C typically requires a 230kB of RAM by default (most of it > dynamically allocated), which is way too much of what is physically available > in any embedded CPU of the general class (those typically end up with RAM > sizes in 192kB area) - so there is no way on how to directly use the ProtonC > on such CPUs. > *Solution?* > The outcome of my work is the *Proton-E*, based off the Proton-C library, > squeezed to run on 32kB of total RAM usage (without sacrificing any > functionality) and with a TLS on side taking addition approx. 11kB. > This allows you to fit the AMQPS into any connected embedded CPU with 128kB > of RAM (or more) - which most of the commonly available CPUs on market > provide (for a great price). > The "embedded" modifications are backwards applicable to the ProtonC, and > this is what I would like to introduce through this JIRA Ticket. > *Note* > This work was picked up by Microsoft in mid-2014, and I have personally > cooperated with them; but I have not seen any result being provided to > community, as it seems the whole effort on their side vanished (and if not, > they stopped the cooperation - so they won't have my latest sources). > Never mind, as I have the most actual source code (as I've never stopped the > development, and I do follow every commit the ProtonC community does), none > is lost. > At this moment, before the ProtonE source gets out, let me use this ticket to > provide an assurance, that indeed the ProtonE (resp. modified ProtonC) can be > used on the constrained system, and, most importantly, it is production ready > for Azure Cloud. > *ProtonE Features* > * Super-Low RAM footprint: total 32kB of RAM usage, for a AMQP message with > 1.5kB of payload > * Azure Cloud: Service Bus / eventHub - both verified (IoT Hub - very close > future, will definitely work - my colleagues cooperate with MS on this) > * Azure Cloud: SASL PLAIN over TLS (Active Directory) - verified > * Azure Cloud: SAS tokens (CBS) - verified > * No modifications to ProtonC API what-so-ever > * TCP stack, and RTOS, independent > *The ProtonE has been made to run and personally tested, by myself, with the > following setup: * > * CPUs: 32-bit ARM - Cortex M3 (STM32, SAM3), Cortex M4 (Atmel SAM4), Cortex > M7 (Atmel SAM S70/V71), I also run this on TI Sitara with embedded RTOS > * There is no reason why this would not work on any other CPUs (all is just a > plain-C code) > * RTOS: FreeRTOS/SafeRTOS; but primarily: expressLogic ThreadX > * TCP/IP stack: expressLogic NetX & NetX-Duo TCP/IP > * Comms: Broadcom WICED Wi-Fi solution > * TLS via Mocana NanoSSL (v6.0 or newer) > * TLS via MatrixSSL (3.6.1 or newer) > *SSL/TLS* > This is quite a huge memory hog, but should you understand it deeply, you > won't have trouble managing this. > Some numbers I've got: > * Handshake establishment: RAM usage peak is 30kB for TLS itself (handshake: > RSA) > * After the Handshake is done and the TLS tunnel is open: the TLS itself > requires 11kB of RAM (tunnel: AES) > I'm looking forward to have Microsoft to switch the Azure solely to ECC for > us (now they have RSA and ECC, and the server-side cert is solely RSA). Then > the handshake number will be even much more positive. > *Final words* > Once you realize that the AMQPS is the only possible scalable future for the > IoT (... hate this buzzword, BTW.), where the 95% of devices will be deeply > embedded ones, then it is obvious what role the ProtonE will play. > Best regards from CZ, > Adam N -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-905: --- Fix Version/s: 0.17.0 > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti > Labels: leak > Fix For: 0.17.0 > > Attachments: test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-703) inlining performance improvements
[ https://issues.apache.org/jira/browse/PROTON-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-703: --- Labels: close-pending perf (was: perf) > inlining performance improvements > - > > Key: PROTON-703 > URL: https://issues.apache.org/jira/browse/PROTON-703 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: michael goulish >Assignee: michael goulish >Priority: Minor > Labels: close-pending, perf > > omnibus jira for any other inlining performance improvements i may find. > notes to self: > * don't affect public APIs. > * don't forget to test Debug build. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-659) if protons internal buffer gets large, performance can suffer
[ https://issues.apache.org/jira/browse/PROTON-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-659: --- Fix Version/s: 0.17.0 > if protons internal buffer gets large, performance can suffer > - > > Key: PROTON-659 > URL: https://issues.apache.org/jira/browse/PROTON-659 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.7 >Reporter: Gordon Sim >Priority: Minor > Labels: perf > Fix For: 0.17.0 > > > In doing some performance investigations using qpid::messaging over 1.0, in > particular as message size got larger, I saw much lower throughput and lots > of cpu used. From callgrind it looked like this was from shuffliing up the > buffer in pn_dispatcher_output. Because of the threading in qpid::messaging, > it was possible for the application to generate too much output using the > top-half of the engine API before the IO was done for the bottom half. Fixing > that in qpid:messaging improved performance. > There may perhaps be something that proton could do to make users more aware > of this (e.g. a log message if the buffer exceeds a certain size? or just > documentation?) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-621) Added support for Android to Qpid-Proton0.6
[ https://issues.apache.org/jira/browse/PROTON-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-621: --- Labels: android features patch (was: features github-import patch) > Added support for Android to Qpid-Proton0.6 > --- > > Key: PROTON-621 > URL: https://issues.apache.org/jira/browse/PROTON-621 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.6 > Environment: Android OS >Reporter: Jimmy Campbell > Labels: android, features, patch > Fix For: Future > > Original Estimate: 0h > Remaining Estimate: 0h > > The focus of this JIRA is for providing a method to build the Proton-C > library and get it running in the Android environment. I have forked the > Qpid-Proton repository and made a branch called AndroidProton that is based > off of 0.6. I have put together a little folder called proton-a which sits > inside the former 0.6 branch. Proton-a is the foundation for Proton on > Android. It contains a readme with instructions on how to build targeting > Android, the necessary files, and an example Android Project utilizing the > Proton-C library. I would like my changes to get pulled into the 0.6 branch > as an added feature. > https://github.com/jimmypc92/qpid-proton/tree/AndroidProton > Issues porting Proton-C to Android > The first issue of getting Proton-C working on Android was the lack of > openssl and uuid support. I fixed this by using open source implementations I > found online. My openssl for Android implementation was acquired off an old > github repository > "https://github/eighthave/openssl-android.git"; > My uuid for Android implementation was acquired from AOSP > "android/platform/external/e2fsprogs/./lib/uuid" > Building the C libraries for Android > I built these libraries using the ndk-build system that comes with the > Android ndk. My folder comes with a README that links to the Android ndk if > one does not already have it. The README folder also has step-by-step > instructions for someone to build the library their selves. As I said, this > involves calling ndk-build 3 times. The user will build the openssl, then the > uuid, then the Proton-C libraries. The user can create their own java > bindings for calling the c library from Android by building the desktop > Qpid-Proton-0.6 with java swig bindings. Or they can use the jars that come > with my folder. > Changes > Every occurrence of getprotobyname("tcp")->p_proto had to be replaced with > IPPROTO_TCP in the source file proton-c/src/posix/driver.c This fix checks if > the source is being compiled with the NDK compiler to ensure that it doesn't > break the desktop build. The pre-processor definition for Android is > #ifdef __ANDROID__ > functional bug fix > The swig language binding jars produced with Qpid-Proton-0.6 build system > were causing a segfault whenever receiving a message that had the messageId > set to a generated uuid from the desktop Qpid-Proton-0.6 client. The error is > in JNIMessage.java in > qpid-proton-0.6/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/messsage/jni. > at the convert method whenever type is a uuid. > The fix I used involved removing the use of pn_bytes_to_array in favor of > getting a pn_uuid_t from value (which is a pn_atom_t_u) and then getting the > byte array directly from the pn_uuid_t with the pn_uuid_t.getBytes() method > call. > {code:title=JNIMessage.java|borderStyle=solid} > else if(pn_type_t.PN_UUID.equals(type)) > { > pn_uuid_t uuidT = value.getAs_uuid(); > byte[] uuidBytes = uuidT.getBytes(); > -deleted- byte[] b = Proton.pn_bytes_to_array(value.getAs_bytes()); > ByteBuffer buf = ByteBuffer.wrap(uuidBytes); > return new UUID(buf.getLong(), buf.getLong()); > } > {code} > Example Android project > In the AndroidProtonBuild folder, a sample Android Proton project is included > that uses Proton-C. This project contains a file called UsingSwig.java which > exposes simple methods like send(). This sample project has a send and > receive button to check if the function is working with your target messaging > endpoint. The address to send and receive from must be specified in the > UsingSwig.java source file. > tip for native development on android > If you want to check for compilation by the NDK build system use > #ifdef __ANDROID__ > If you want to use eclipse and print to LogCat from C code, include the > following lines at the top of the source file: > #ifdef __ANDROID__ > #include > #define LOG_TAG "my-log-tag" > #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__) > #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__) > #endif > These lines allow you to call LOGD([str
[jira] [Updated] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
[ https://issues.apache.org/jira/browse/PROTON-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1073: Fix Version/s: 0.12.0 > Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1 > --- > > Key: PROTON-1073 > URL: https://issues.apache.org/jira/browse/PROTON-1073 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0 > Environment: MacOS X 10.11.1, XCode 7.1.1 > Compilation options: > env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake > .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF > -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64 >Reporter: Ollivier Robert >Assignee: Cliff Jansen > Labels: build-failure, osx > Fix For: 0.12.0 > > > Compiling 0.11 leads to build failure in the tests for the C++ bindings: > [...] > Linking CXX shared library libqpid-proton-cpp.dylib > [ 66%] Built target qpid-proton-cpp > Scanning dependencies of target conversion_test > [ 66%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p = s.ptr(); > ^ ~~~ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25: > note: > in instantiation of function template specialization > 'test_owning std::__1::default_delete >, > std::__1::unique_ptr std::__1::default_delete > >' > requested here > failed += run_test(&test_owning< > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p2 = s.ptr(); > ^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > 2 errors generated. > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o] > Error 1 > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error > 2 > make: *** [all] Error 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
[ https://issues.apache.org/jira/browse/PROTON-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1073. --- Resolution: Fixed > Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1 > --- > > Key: PROTON-1073 > URL: https://issues.apache.org/jira/browse/PROTON-1073 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0 > Environment: MacOS X 10.11.1, XCode 7.1.1 > Compilation options: > env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake > .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF > -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64 >Reporter: Ollivier Robert >Assignee: Cliff Jansen > Labels: build-failure, osx > Fix For: 0.12.0 > > > Compiling 0.11 leads to build failure in the tests for the C++ bindings: > [...] > Linking CXX shared library libqpid-proton-cpp.dylib > [ 66%] Built target qpid-proton-cpp > Scanning dependencies of target conversion_test > [ 66%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p = s.ptr(); > ^ ~~~ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25: > note: > in instantiation of function template specialization > 'test_owning std::__1::default_delete >, > std::__1::unique_ptr std::__1::default_delete > >' > requested here > failed += run_test(&test_owning< > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p2 = s.ptr(); > ^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > 2 errors generated. > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o] > Error 1 > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error > 2 > make: *** [all] Error 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-621) Added support for Android to Qpid-Proton0.6
[ https://issues.apache.org/jira/browse/PROTON-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-621: --- Fix Version/s: Future > Added support for Android to Qpid-Proton0.6 > --- > > Key: PROTON-621 > URL: https://issues.apache.org/jira/browse/PROTON-621 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.6 > Environment: Android OS >Reporter: Jimmy Campbell > Labels: android, features, patch > Fix For: Future > > Original Estimate: 0h > Remaining Estimate: 0h > > The focus of this JIRA is for providing a method to build the Proton-C > library and get it running in the Android environment. I have forked the > Qpid-Proton repository and made a branch called AndroidProton that is based > off of 0.6. I have put together a little folder called proton-a which sits > inside the former 0.6 branch. Proton-a is the foundation for Proton on > Android. It contains a readme with instructions on how to build targeting > Android, the necessary files, and an example Android Project utilizing the > Proton-C library. I would like my changes to get pulled into the 0.6 branch > as an added feature. > https://github.com/jimmypc92/qpid-proton/tree/AndroidProton > Issues porting Proton-C to Android > The first issue of getting Proton-C working on Android was the lack of > openssl and uuid support. I fixed this by using open source implementations I > found online. My openssl for Android implementation was acquired off an old > github repository > "https://github/eighthave/openssl-android.git"; > My uuid for Android implementation was acquired from AOSP > "android/platform/external/e2fsprogs/./lib/uuid" > Building the C libraries for Android > I built these libraries using the ndk-build system that comes with the > Android ndk. My folder comes with a README that links to the Android ndk if > one does not already have it. The README folder also has step-by-step > instructions for someone to build the library their selves. As I said, this > involves calling ndk-build 3 times. The user will build the openssl, then the > uuid, then the Proton-C libraries. The user can create their own java > bindings for calling the c library from Android by building the desktop > Qpid-Proton-0.6 with java swig bindings. Or they can use the jars that come > with my folder. > Changes > Every occurrence of getprotobyname("tcp")->p_proto had to be replaced with > IPPROTO_TCP in the source file proton-c/src/posix/driver.c This fix checks if > the source is being compiled with the NDK compiler to ensure that it doesn't > break the desktop build. The pre-processor definition for Android is > #ifdef __ANDROID__ > functional bug fix > The swig language binding jars produced with Qpid-Proton-0.6 build system > were causing a segfault whenever receiving a message that had the messageId > set to a generated uuid from the desktop Qpid-Proton-0.6 client. The error is > in JNIMessage.java in > qpid-proton-0.6/proton-c/bindings/java/src/main/java/org/apache/qpid/proton/messsage/jni. > at the convert method whenever type is a uuid. > The fix I used involved removing the use of pn_bytes_to_array in favor of > getting a pn_uuid_t from value (which is a pn_atom_t_u) and then getting the > byte array directly from the pn_uuid_t with the pn_uuid_t.getBytes() method > call. > {code:title=JNIMessage.java|borderStyle=solid} > else if(pn_type_t.PN_UUID.equals(type)) > { > pn_uuid_t uuidT = value.getAs_uuid(); > byte[] uuidBytes = uuidT.getBytes(); > -deleted- byte[] b = Proton.pn_bytes_to_array(value.getAs_bytes()); > ByteBuffer buf = ByteBuffer.wrap(uuidBytes); > return new UUID(buf.getLong(), buf.getLong()); > } > {code} > Example Android project > In the AndroidProtonBuild folder, a sample Android Proton project is included > that uses Proton-C. This project contains a file called UsingSwig.java which > exposes simple methods like send(). This sample project has a send and > receive button to check if the function is working with your target messaging > endpoint. The address to send and receive from must be specified in the > UsingSwig.java source file. > tip for native development on android > If you want to check for compilation by the NDK build system use > #ifdef __ANDROID__ > If you want to use eclipse and print to LogCat from C code, include the > following lines at the top of the source file: > #ifdef __ANDROID__ > #include > #define LOG_TAG "my-log-tag" > #define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, __VA_ARGS__) > #define LOGE(...) __android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__) > #endif > These lines allow you to call LOGD([stringToPrint]); Which basically serves > as a p
[jira] [Closed] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
[ https://issues.apache.org/jira/browse/PROTON-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1073. --- Resolution: Fixed > Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1 > --- > > Key: PROTON-1073 > URL: https://issues.apache.org/jira/browse/PROTON-1073 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0 > Environment: MacOS X 10.11.1, XCode 7.1.1 > Compilation options: > env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake > .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF > -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64 >Reporter: Ollivier Robert >Assignee: Cliff Jansen > Labels: build-failure, osx > > Compiling 0.11 leads to build failure in the tests for the C++ bindings: > [...] > Linking CXX shared library libqpid-proton-cpp.dylib > [ 66%] Built target qpid-proton-cpp > Scanning dependencies of target conversion_test > [ 66%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p = s.ptr(); > ^ ~~~ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25: > note: > in instantiation of function template specialization > 'test_owning std::__1::default_delete >, > std::__1::unique_ptr std::__1::default_delete > >' > requested here > failed += run_test(&test_owning< > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p2 = s.ptr(); > ^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > 2 errors generated. > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o] > Error 1 > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error > 2 > make: *** [all] Error 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
[ https://issues.apache.org/jira/browse/PROTON-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reopened PROTON-1073: - > Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1 > --- > > Key: PROTON-1073 > URL: https://issues.apache.org/jira/browse/PROTON-1073 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0 > Environment: MacOS X 10.11.1, XCode 7.1.1 > Compilation options: > env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake > .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF > -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64 >Reporter: Ollivier Robert >Assignee: Cliff Jansen > Labels: build-failure, osx > Fix For: 0.12.0 > > > Compiling 0.11 leads to build failure in the tests for the C++ bindings: > [...] > Linking CXX shared library libqpid-proton-cpp.dylib > [ 66%] Built target qpid-proton-cpp > Scanning dependencies of target conversion_test > [ 66%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p = s.ptr(); > ^ ~~~ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25: > note: > in instantiation of function template specialization > 'test_owning std::__1::default_delete >, > std::__1::unique_ptr std::__1::default_delete > >' > requested here > failed += run_test(&test_owning< > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p2 = s.ptr(); > ^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > 2 errors generated. > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o] > Error 1 > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error > 2 > make: *** [all] Error 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1073) Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1
[ https://issues.apache.org/jira/browse/PROTON-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1073: Labels: build-failure osx (was: build-failure) > Building tests for C++ bindings seems to be broken on OSX 10.11/Xcode 7.1.1 > --- > > Key: PROTON-1073 > URL: https://issues.apache.org/jira/browse/PROTON-1073 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.11.0 > Environment: MacOS X 10.11.1, XCode 7.1.1 > Compilation options: > env CFLAGS="-I/opt/local/include -m64" LDFLAGS="-m64 -L/opt/local/lib" cmake > .. -DCMAKE_INSTALL_PREFIX=/usr/local -DSYSINSTALL_BINDINGS=ON -DBUILD_PHP=OFF > -DBUILD_PERL=OFF -DBUILD_PYTHON=OFF -DCMAKE_OSX_ARCHITECTURES=x86_64 >Reporter: Ollivier Robert >Assignee: Cliff Jansen > Labels: build-failure, osx > > Compiling 0.11 leads to build failure in the tests for the C++ bindings: > [...] > Linking CXX shared library libqpid-proton-cpp.dylib > [ 66%] Built target qpid-proton-cpp > Scanning dependencies of target conversion_test > [ 66%] Building CXX object > proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:36:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p = s.ptr(); > ^ ~~~ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:58:25: > note: > in instantiation of function template specialization > 'test_owning std::__1::default_delete >, > std::__1::unique_ptr std::__1::default_delete > >' > requested here > failed += run_test(&test_owning< > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > /Users/roberto/Src/ERC/GIT/qpid-proton-0.11.0/proton-c/bindings/cpp/src/conversion_test.cpp:37:17: > error: > no viable constructor copying variable of type > 'std::unique_ptr' > session_ptr p2 = s.ptr(); > ^~~~ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2497:5: > note: > candidate constructor not viable: expects an l-value for 1st argument > unique_ptr(unique_ptr&); > ^ > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2499:9: > note: > candidate constructor [with _Up = proton::session, _Ep = > std::__1::default_delete] not viable: expects an > l-value for 1st > argument > unique_ptr(unique_ptr<_Up, _Ep>&); > ^ > 2 errors generated. > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/src/conversion_test.cpp.o] > Error 1 > make[1]: *** [proton-c/bindings/cpp/CMakeFiles/conversion_test.dir/all] Error > 2 > make: *** [all] Error 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-731) Installing language bindings provides no means to override the install path
[ https://issues.apache.org/jira/browse/PROTON-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-731: --- Fix Version/s: Future > Installing language bindings provides no means to override the install path > --- > > Key: PROTON-731 > URL: https://issues.apache.org/jira/browse/PROTON-731 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Darryl L. Pierce > Labels: patch > Fix For: Future > > Attachments: > 0001-PROTON-731-Installing-Python-requires-Proton-be-inst.patch > > > When performing an install, such as with Fedora or Ubuntu packaging, the > python installation bits use setuptools to build and install the bindings. > However, since the code isn't necessarily installed at that point the install > fails with: > running sdist > running check > warning: sdist: manifest template 'MANIFEST.in' does not exist (using default > file list) > warning: sdist: standard file not found: should have one of README, README.txt > writing manifest file 'MANIFEST' > creating python-qpid-proton-0.8-0 > making hard links in python-qpid-proton-0.8-0... > hard linking cproton.py -> python-qpid-proton-0.8-0 > hard linking cprotonPYTHON_wrap.c -> python-qpid-proton-0.8-0 > hard linking proton.py -> python-qpid-proton-0.8-0 > hard linking setup.py -> python-qpid-proton-0.8-0 > creating dist > Creating tar archive > removing 'python-qpid-proton-0.8-0' (and everything under it) > running install > running build > running build_py > creating build > creating build/lib.linux-x86_64-2.7 > copying proton.py -> build/lib.linux-x86_64-2.7 > copying cproton.py -> build/lib.linux-x86_64-2.7 > running build_ext > building '_cproton' extension > creating build/temp.linux-x86_64-2.7 > gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv > -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 > -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Itemp/usr/local/include > -I/usr/include/python2.7 -c cprotonPYTHON_wrap.c -o > build/temp.linux-x86_64-2.7/cprotonPYTHON_wrap.o > cprotonPYTHON_wrap.c:3019:24: fatal error: proton/url.h: No such file or > directory > #include > ^ > compilation terminated. > ERROR:root:setup failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-852) Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support getaddrinfo(),getprotobyname()
[ https://issues.apache.org/jira/browse/PROTON-852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-852: --- Labels: close-pending patch (was: patch) > Implement pn_getaddrinfo,pn_getprotobyname for platforms that not support > getaddrinfo(),getprotobyname() > - > > Key: PROTON-852 > URL: https://issues.apache.org/jira/browse/PROTON-852 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.9, 0.9.1, 0.10 > Environment: uclinux m68k >Reporter: Tomasz Nowicki >Assignee: Andrew Stitcher > Labels: close-pending, patch > Attachments: proton-c-GETADDRINFO.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > We are using proton-c on a small ebedded system based on uclinux/uclibc.c On > this platform several required functions ex getaddrinfo(), getprotobyname() > are not implemented.We added support for this type of platform by wraping > with pn_getaddrinfo,pn_getprotobyname. Relevant pn_freeaddrinfo is also > introduced. If GETADDRINFO_NOT_IMPL flag is not present, native > implementation is called. Changes apply for posix versions that use old lib.c > Specifically in some embedded versions "get host" is not present(ip address > is used instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-692) Add php build on composer
[ https://issues.apache.org/jira/browse/PROTON-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-692: --- Labels: messenger (was: php php-proton) > Add php build on composer > - > > Key: PROTON-692 > URL: https://issues.apache.org/jira/browse/PROTON-692 > Project: Qpid Proton > Issue Type: Wish > Components: php-binding >Reporter: Haag Olivier >Priority: Minor > Labels: messenger > > Would it be possible to make the php build pullable from composer ? > https://getcomposer.org/ > https://packagist.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-366) Add a protocol dump utility for java
[ https://issues.apache.org/jira/browse/PROTON-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-366: --- Labels: close-pending patch (was: patch) > Add a protocol dump utility for java > > > Key: PROTON-366 > URL: https://issues.apache.org/jira/browse/PROTON-366 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.4 >Reporter: Justin Ross >Priority: Minor > Labels: close-pending, patch > Attachments: QPID-4106.patch > > > This bug was originally under the QPID jira instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-793) error LNK2019: unresolved external symbol _pn_selector_size referenced in function _pn_reactor_work
[ https://issues.apache.org/jira/browse/PROTON-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-793: --- Assignee: Chuck Rolke > error LNK2019: unresolved external symbol _pn_selector_size referenced in > function _pn_reactor_work > --- > > Key: PROTON-793 > URL: https://issues.apache.org/jira/browse/PROTON-793 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 > Environment: Windows, Visual Studio 8 2005 >Reporter: daniel >Assignee: Chuck Rolke > Labels: build-failure, close-pending > > function pn_selector_sized is declared in selector.h, used in reactor.c > Could not find its definition in any file. > I guess this is a wrapper around struct pn_selector_t. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-692) Add php build on composer
[ https://issues.apache.org/jira/browse/PROTON-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-692: --- Component/s: php-binding > Add php build on composer > - > > Key: PROTON-692 > URL: https://issues.apache.org/jira/browse/PROTON-692 > Project: Qpid Proton > Issue Type: Wish > Components: php-binding >Reporter: Haag Olivier >Priority: Minor > Labels: php, php-proton > > Would it be possible to make the php build pullable from composer ? > https://getcomposer.org/ > https://packagist.org/ -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-793) error LNK2019: unresolved external symbol _pn_selector_size referenced in function _pn_reactor_work
[ https://issues.apache.org/jira/browse/PROTON-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-793: --- Labels: build-failure close-pending (was: build) > error LNK2019: unresolved external symbol _pn_selector_size referenced in > function _pn_reactor_work > --- > > Key: PROTON-793 > URL: https://issues.apache.org/jira/browse/PROTON-793 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 > Environment: Windows, Visual Studio 8 2005 >Reporter: daniel > Labels: build-failure, close-pending > > function pn_selector_sized is declared in selector.h, used in reactor.c > Could not find its definition in any file. > I guess this is a wrapper around struct pn_selector_t. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-353) DecoderImpl returns private UnknownDescribedType instead of ...amqp.UnknownDescribedType
[ https://issues.apache.org/jira/browse/PROTON-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-353: --- Fix Version/s: 0.17.0 > DecoderImpl returns private UnknownDescribedType instead of > ...amqp.UnknownDescribedType > > > Key: PROTON-353 > URL: https://issues.apache.org/jira/browse/PROTON-353 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.4 > Environment: Windows / Eclipse Juno >Reporter: Sean Gallagher >Priority: Minor > Labels: api, codec > Fix For: 0.17.0 > > > DecoderImpl.java creates and exposes to the application, instances of a > private class UnknownDescribedType. It should probably instantiate instances > of org.apache.qpid.proton.amqp.UnknownDescribedType. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-353) DecoderImpl returns private UnknownDescribedType instead of ...amqp.UnknownDescribedType
[ https://issues.apache.org/jira/browse/PROTON-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-353: --- Labels: api codec (was: codec) > DecoderImpl returns private UnknownDescribedType instead of > ...amqp.UnknownDescribedType > > > Key: PROTON-353 > URL: https://issues.apache.org/jira/browse/PROTON-353 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.4 > Environment: Windows / Eclipse Juno >Reporter: Sean Gallagher >Priority: Minor > Labels: api, codec > Fix For: 0.17.0 > > > DecoderImpl.java creates and exposes to the application, instances of a > private class UnknownDescribedType. It should probably instantiate instances > of org.apache.qpid.proton.amqp.UnknownDescribedType. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-335) Need a means of specifying and reading link properties
[ https://issues.apache.org/jira/browse/PROTON-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-335: --- Labels: api close-pending (was: api) > Need a means of specifying and reading link properties > -- > > Key: PROTON-335 > URL: https://issues.apache.org/jira/browse/PROTON-335 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Priority: Minor > Labels: api, close-pending > > There are some cases where it may be beneficial to use link properties (since > link capabilities do not allow for key-value pairs, they can't easily convey > a desired configurable value and the properties on a terminus refer to the > dynamically created node not the link or the terminus itself). > (I've set this to minor since major feels a little strong, but I do think its > important ultimately for the engine to expose all the extension points from > the protocol.) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-291) fix the SSL layer of the transport to only pop from the amqp layer when bytes are known to have actually been written to the socket
[ https://issues.apache.org/jira/browse/PROTON-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-291: --- Labels: close-pending ssl (was: ssl) > fix the SSL layer of the transport to only pop from the amqp layer when bytes > are known to have actually been written to the socket > --- > > Key: PROTON-291 > URL: https://issues.apache.org/jira/browse/PROTON-291 > Project: Qpid Proton > Issue Type: Bug >Reporter: Rafael H. Schloming >Assignee: Ken Giusti > Labels: close-pending, ssl > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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 ] Justin Ross updated PROTON-287: --- Fix Version/s: 0.17.0 > 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, close-pending, patch > Fix For: 0.17.0 > > > 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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[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 ] Justin Ross updated PROTON-287: --- Labels: build close-pending patch (was: build patch) > 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, close-pending, patch > > 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) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl
[ https://issues.apache.org/jira/browse/PROTON-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-252: --- Labels: api close-pending (was: visibility) > Reduce visibiliy of constructors for classes that should be created by > factories eg MessageImpl > --- > > Key: PROTON-252 > URL: https://issues.apache.org/jira/browse/PROTON-252 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.4 >Reporter: Philip Harvey >Assignee: Philip Harvey >Priority: Minor > Labels: api, close-pending > Fix For: 0.17.0 > > > These constructors are currently public but deprecated, and should be made > package-private where possible to enforce the use of the factories instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl
[ https://issues.apache.org/jira/browse/PROTON-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-252: --- Fix Version/s: 0.17.0 > Reduce visibiliy of constructors for classes that should be created by > factories eg MessageImpl > --- > > Key: PROTON-252 > URL: https://issues.apache.org/jira/browse/PROTON-252 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.4 >Reporter: Philip Harvey >Assignee: Philip Harvey >Priority: Minor > Labels: visibility > Fix For: 0.17.0 > > > These constructors are currently public but deprecated, and should be made > package-private where possible to enforce the use of the factories instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-241) proton-c: mark old transport interfaces 'deprecated'
[ https://issues.apache.org/jira/browse/PROTON-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-241: --- Fix Version/s: 0.16.0 > proton-c: mark old transport interfaces 'deprecated' > > > Key: PROTON-241 > URL: https://issues.apache.org/jira/browse/PROTON-241 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ken Giusti >Priority: Trivial > Labels: api > Fix For: 0.16.0 > > > Once PROTON-225 is implemented, we should eventually remove the old > interfaces after marking them deprecated. > Example: > #ifdef __GNUC__ > #define DEPRECATED(func) func __attribute__ ((deprecated)) > #elif defined(_MSC_VER) > #define DEPRECATED(func) __declspec(deprecated) func > #else > #pragma message("WARNING: You need to implement DEPRECATED for this compiler") > #define DEPRECATED(func) func > #endif -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-220) Create a set of "glass box" tests to quantify the performance of the proton codebase.
[ https://issues.apache.org/jira/browse/PROTON-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-220: --- Fix Version/s: 0.17.0 > Create a set of "glass box" tests to quantify the performance of the proton > codebase. > - > > Key: PROTON-220 > URL: https://issues.apache.org/jira/browse/PROTON-220 > Project: Qpid Proton > Issue Type: Test > Components: proton-c, proton-j >Reporter: Ken Giusti >Assignee: michael goulish > Labels: perfomance, test > Fix For: 0.17.0 > > > The goal of these tests would be to detect any performance degradation > inadvertently introduced during development. These tests would not be > intended to provide any metrics regarding the "real world" behavior of > proton-based applications. Rather, these tests are targeted for use by the > proton developers to help gauge the effect their code changes may have on > performance. > These tests should require no special configuration or setup in order to run. > It should be easy to run these test as part of the development process. The > intent would be to have developer run the tests prior to making any code > changes, and record the metrics for comparison against the results obtained > after making changes to the code base. > As described by Rafi: > "I think it would be good to include some performance metrics that isolate > the various components of proton. For example having a metric that simply > repeatedly encodes/decodes a message would be quite useful in isolating the > message implementation. Setting up two engines in memory and using them to > blast zero sized messages back and forth as fast as possible would tell us > how much protocol overhead the engine is adding. Using the codec directly > to encode/decode data would also be a useful measure. Each of these would > probably want to have multiple profiles, different message content, > different acknowledgement/flow control patterns, and different kinds of > data. > I think breaking out the different dimensions of the implementation as > above would provide a very useful tool to run before/after any performance > sensitive changes to detect and isolate regressions, or to test potential > improvements." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-162) SSL implementation does not support certification revocation
[ https://issues.apache.org/jira/browse/PROTON-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-162: --- Fix Version/s: Future > SSL implementation does not support certification revocation > > > Key: PROTON-162 > URL: https://issues.apache.org/jira/browse/PROTON-162 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 >Reporter: Ken Giusti > Labels: security, ssl > Fix For: Future > > > OpenSSL supports a means for configuring lists of revoked certificates. The > SSL layer used by proton-c does not provide a means to configure this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-161: --- Labels: close-pending security (was: security) > SSL impl does not allow verification of the peer's identity > --- > > Key: PROTON-161 > URL: https://issues.apache.org/jira/browse/PROTON-161 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.3 >Reporter: Ken Giusti >Priority: Minor > Labels: close-pending, security > > The current SSL implementation validates the peer's certificate, and will not > permit the connection to come up if the certificate is invalid. > However - it does not provide a way to check if the peer's identity as > provided in the certificate is the expected identity (eg, the same hostname > used to set up the TCP connection). While a certificate may be valid (that > is, signed by a CA trusted by the client), it may not belong to the intended > destination. > RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-73) Server should force renegotiate when client authentication setting is changed on an active connection.
[ https://issues.apache.org/jira/browse/PROTON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-73: -- Fix Version/s: Future > Server should force renegotiate when client authentication setting is changed > on an active connection. > -- > > Key: PROTON-73 > URL: https://issues.apache.org/jira/browse/PROTON-73 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Labels: security, ssl > Fix For: Future > > > If the server application changes the peer authentication setting from > 'anonymous' to 'verify-peer' while an SSL session is active, then the server > should force the client to re-negotiate (SSL handshake) to verify the > remote's identity. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault
[ https://issues.apache.org/jira/browse/PROTON-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-158: --- Labels: close-pending crash (was: crash) > detach with invalid handle causes segfault > -- > > Key: PROTON-158 > URL: https://issues.apache.org/jira/browse/PROTON-158 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Minor > Labels: close-pending, crash > Fix For: 0.17.0 > > > I.e. a detach where the handle was not previously used in an attach -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-158) detach with invalid handle causes segfault
[ https://issues.apache.org/jira/browse/PROTON-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-158: --- Fix Version/s: 0.17.0 > detach with invalid handle causes segfault > -- > > Key: PROTON-158 > URL: https://issues.apache.org/jira/browse/PROTON-158 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Gordon Sim >Assignee: Ken Giusti >Priority: Minor > Labels: close-pending, crash > Fix For: 0.17.0 > > > I.e. a detach where the handle was not previously used in an attach -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-357) Add PHP PECL package
[ https://issues.apache.org/jira/browse/PROTON-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-357: --- Labels: messenger packaging (was: packaging) > Add PHP PECL package > > > Key: PROTON-357 > URL: https://issues.apache.org/jira/browse/PROTON-357 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.4 > Environment: Linux, Macos X >Reporter: Serge Smertin > Labels: messenger, packaging > > In order to get Proton adoption in PHP ecosystem and not to build library > from sources, PECL package should be introduced. Probably with Packagist as > well. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org