[jira] [Commented] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130087#comment-15130087 ] Tomas Soltys commented on PROTON-515: - 1) According to http://h71000.www7.hp.com/doc/82final/6529/6529pro_018.html poll should set only EAGAIN or EINTR. Everything works fine when you have file descriptors created same way (all fds are created only with pipe() or only with socket()). But if you mix them then poll will fail and set errno to ENOTSOCK. I was not able to find anything in the documentation regarding this behavior. So, I will create ../openvms/pipe.c and provide a patch. 2) My compiler on OpenVMS is "HP C V7.2-001 on OpenVMS IA64 V8.4" and throws following error. PN_HANDLE(PNI_ACCEPTOR_HANDLER) ^ %CC-E-BADSTATICCVT, In the initializer for PNI_ACCEPTOR_HANDLER, the address cannot be converted to the destination type. at line number 31 in file [.qpid-proton-0_11_1.proton-c.src.reactor]acceptor.c;1 Description: A static initialization tried to convert a link-time address to another type. However, the linker on this platform will not support such a conversion. User Action: Rewrite the static initialization, or perform the initialization using runtime code. The way how PN_HANDLER is used it is guaranteed that using __LINE__ will return unique value since variable it creates is static in the scope of the file and therefore no other variable created with this macro can have the same value since it is on different line of that file. There is only one possible situation that I can think of in which the value would not be unique: PN_HANDLE(A) PN_HANDLE(B) But this can be solved by making macro two-lined. #define PN_HANDLE(name) \ static pn_handle_t name = __LINE__; \ > 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 > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130087#comment-15130087 ] Tomas Soltys edited comment on PROTON-515 at 2/3/16 9:19 AM: - 1) According to http://h71000.www7.hp.com/doc/82final/6529/6529pro_018.html poll should set only EAGAIN or EINTR. Everything works fine when you have file descriptors created in the same way (all fds are created only with pipe() or only with socket()). But if you mix them, then poll will fail and set errno to ENOTSOCK. I was not able to find anything in the documentation regarding this behavior. So, I will create ../openvms/pipe.c and provide a patch. 2) My compiler on OpenVMS is "HP C V7.2-001 on OpenVMS IA64 V8.4" and throws following error. PN_HANDLE(PNI_ACCEPTOR_HANDLER) ^ %CC-E-BADSTATICCVT, In the initializer for PNI_ACCEPTOR_HANDLER, the address cannot be converted to the destination type. at line number 31 in file [.qpid-proton-0_11_1.proton-c.src.reactor]acceptor.c;1 Description: A static initialization tried to convert a link-time address to another type. However, the linker on this platform will not support such a conversion. User Action: Rewrite the static initialization, or perform the initialization using runtime code. The way how PN_HANDLER is used it is guaranteed that using __LINE__ will return unique value since variable it creates is static in the scope of the file and therefore no other variable created with this macro can have the same value since it is on different line of that file. There is only one possible situation that I can think of in which the value would not be unique: PN_HANDLE(A) PN_HANDLE(B) But this can be solved by making macro two-lined. #define PN_HANDLE(name) \ static pn_handle_t name = __LINE__; \ was (Author: solttom): 1) According to http://h71000.www7.hp.com/doc/82final/6529/6529pro_018.html poll should set only EAGAIN or EINTR. Everything works fine when you have file descriptors created same way (all fds are created only with pipe() or only with socket()). But if you mix them then poll will fail and set errno to ENOTSOCK. I was not able to find anything in the documentation regarding this behavior. So, I will create ../openvms/pipe.c and provide a patch. 2) My compiler on OpenVMS is "HP C V7.2-001 on OpenVMS IA64 V8.4" and throws following error. PN_HANDLE(PNI_ACCEPTOR_HANDLER) ^ %CC-E-BADSTATICCVT, In the initializer for PNI_ACCEPTOR_HANDLER, the address cannot be converted to the destination type. at line number 31 in file [.qpid-proton-0_11_1.proton-c.src.reactor]acceptor.c;1 Description: A static initialization tried to convert a link-time address to another type. However, the linker on this platform will not support such a conversion. User Action: Rewrite the static initialization, or perform the initialization using runtime code. The way how PN_HANDLER is used it is guaranteed that using __LINE__ will return unique value since variable it creates is static in the scope of the file and therefore no other variable created with this macro can have the same value since it is on different line of that file. There is only one possible situation that I can think of in which the value would not be unique: PN_HANDLE(A) PN_HANDLE(B) But this can be solved by making macro two-lined. #define PN_HANDLE(name) \ static pn_handle_t name = __LINE__; \ > 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 > Attachments: io.c.patch, object.h.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)
Proton 0.12.0 release update - RC is available
The release candidate is now available: https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1061 Test output on Fedora 23 x86-64: http://people.apache.org/~jross/qpid-releases/quirk-proton-0.12.0-rc.log The artifacts are in final form and signed. If we approve this RC for release, these RC bits will become the GA bits. I will wait until Monday the 8th to start the vote, in case we discover any important problems and need to plan another RC. Thanks! Justin --- Proton 0.12.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.12.0
Re: Proton 0.12.0 release update - RC is available
On Wed, Feb 3, 2016 at 5:47 AM, Justin Ross wrote: > I will wait until Monday the 8th to start the vote, in case we discover > any important problems and need to plan another RC. > Robbie suggested I may as well start the vote now. Incoming.
[VOTE] Release Qpid Proton 0.12.0
The artifacts proposed for release: https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ Please indicate your vote below. If you favor releasing the 0.12.0 RC bits as 0.12.0 GA, vote +1. If you have reason to think the RC is not ready for release, vote -1. Thanks, Justin
[jira] [Commented] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130551#comment-15130551 ] Andrew Stitcher commented on PROTON-515: 1) Seems like a strange platform behaviour, but I think it'll work if you follow the plan I outlined. 2) I think you have misunderstood the purpose of the statics: _PN_HANDLE_ ## name is used only used to get the compiler to allocate a unique address in the program address space. This address is then converted into an integer and used as a handle for the record type. This handle needs to be unique for the entire program even if the variable that holds it is static - that's because it is used by the logic that attaches records to events to distinguish the various record types. I think this limitation of your linker is pretty serious, because every scheme I can think of to generate this unique ids straightforwardly involves getting the linker to allocate some space in the program get its address and use that as the handle. Perhaps we could make the pn_handle_t actually use a void* as its type - that might work around the linker (as the message implied that it was converting to a non pointer type that is the issue). > 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 > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1126) Allow setting connection properties in BlockingConnection
Ganesh Murthy created PROTON-1126: - Summary: Allow setting connection properties in BlockingConnection Key: PROTON-1126 URL: https://issues.apache.org/jira/browse/PROTON-1126 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11.1 Reporter: Ganesh Murthy Priority: Minor Fix For: 0.13.0 The BlockingConnection class in proton/bindings/python/proton/utils.py does not have a way to set the connection properties. connection properties are sent as part of the AMQP open frame. Allow the connection properties to be set on the BlockingConnection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1126) Allow setting connection properties in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131013#comment-15131013 ] Ganesh Murthy commented on PROTON-1126: --- See if you can also allow setting the offered_capabilities and desired_capabilities > Allow setting connection properties in BlockingConnection > - > > Key: PROTON-1126 > URL: https://issues.apache.org/jira/browse/PROTON-1126 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Priority: Minor > Fix For: 0.13.0 > > > The BlockingConnection class in proton/bindings/python/proton/utils.py does > not have a way to set the connection properties. > connection properties are sent as part of the AMQP open frame. > Allow the connection properties to be set on the BlockingConnection -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Best practices using proton-j Reactor
Hello Folks! Couple of Questions on Proton-j Reactor usage-pattern: 1. In the current version of proton-j: 1 Reactor instance is tied to 1 connection – is there any way to associate 1 Reactor per Link. Or in other words, If there are multiple links attached to one Connection, which is handled by one Reactor instance - What is the recommendation to use reactor in such a way that One link will not impact others – the unhandled exceptions and the time it takes to process. Here’s the Problem: When one of the links perform I/O upon any event dispatched (ex: onDelivery) by the Reactor pump – all other links are starving for messages as that I/O is blocking the thread in which reactor.run() – which absolutely makes sense from Reactor pump (the reactor.run()) perspective. 2. What is the Best way to gracefully Stop the Reactor. In our Tests – where we are Starting a Reactor per testclass and calling reactor.free as part of class cleanup – throws exception: reactor:org.apache.qpid.proton.engine.HandlerException: java.nio.channels.ClosedSelectorException Do we need to handle this by try-catch’ing the reactor.run() block ? Thanks a lot for such a Wonderful Collaboration! Sree
Re: [VOTE] Release Qpid Proton 0.12.0
+1 release 0.12.0 RC bits as 0.12.0 GA tested on Centos7: - unit test and install - verified pyngus 2.0.3 unit tests and examples pass - verified mainline oslo.messaging functional tests pass - verified mainline rsyslog amqp1 plugin functions - Original Message - > From: "Justin Ross" > To: us...@qpid.apache.org, proton@qpid.apache.org > Sent: Wednesday, February 3, 2016 10:10:12 AM > Subject: [VOTE] Release Qpid Proton 0.12.0 > > The artifacts proposed for release: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ > > Please indicate your vote below. If you favor releasing the 0.12.0 RC bits > as 0.12.0 GA, vote +1. If you have reason to think the RC is not ready for > release, vote -1. > > Thanks, > Justin > -- -K
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-515: --- Attachment: 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch I've attached a possible fix for the OpenVMS linker problem. [~solttom] please try this on your OpenVMS system, if it works for you I'm open to getting this in Proton. > 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 > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, io.c.patch, > object.h.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)
Re: [VOTE] Release Qpid Proton 0.12.0
+1 * Built and ran tests. * validated signatures and sums * Built ActiveMQ using the staged maven artifacts and ran all AMQP tests * Built Qpid-JMS using the staged maven artifacts and ran all the tests. On 02/03/2016 10:10 AM, Justin Ross wrote: > The artifacts proposed for release: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/ > > Please indicate your vote below. If you favor releasing the 0.12.0 RC bits > as 0.12.0 GA, vote +1. If you have reason to think the RC is not ready for > release, vote -1. > > Thanks, > Justin > -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/
