[jira] [Commented] (PROTON-827) Reactive client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14341268#comment-14341268 ] Alan Conway commented on PROTON-827: Very clever!! I was just trying to come up with a good solution to Andrews wiki vs. mailing list dilemma, that is just the ticket. Reactive client binding for the go programming language. -- Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-831) proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5
[ https://issues.apache.org/jira/browse/PROTON-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Irina Boverman updated PROTON-831: -- Attachment: PROTON-831.patch proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5 - Key: PROTON-831 URL: https://issues.apache.org/jira/browse/PROTON-831 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Environment: RHEL 5 Reporter: Irina Boverman Priority: Minor Attachments: PROTON-831.patch proton_tests.utils.SyncRequestResponseTest.test_request_response fail Error during test: Traceback (most recent call last): File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton-test, line 355, in run phase() File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 92, in test_request_response test(foo) # Simple request/resposne File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 82, in test response = client.call(Message(address=address, body=body)) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 315, in call self.sender.send(request) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 76, in send delivery = self.link.send(msg) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2845, in send return obj.send(self, tag=tag) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 1098, in send dlv = sender.delivery(tag or sender.delivery_tag()) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2858, in delivery_tag return next(self.tag_generator) NameError: global name 'next' is not defined Suggested fix (contributed by Ted Ross): Seems the next builtin function was introduced in Python 2.6. Perhaps this should be changed to: return self.tag_generator.next() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-830) [IGNORE ME] GitHub integration test
[ https://issues.apache.org/jira/browse/PROTON-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-830. --- Resolution: Fixed [IGNORE ME] GitHub integration test --- Key: PROTON-830 URL: https://issues.apache.org/jira/browse/PROTON-830 Project: Qpid Proton Issue Type: Bug Reporter: Robbie Gemmell Assignee: Robbie Gemmell JIRA to perform some GitHub integration tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-831) proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5
[ https://issues.apache.org/jira/browse/PROTON-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340360#comment-14340360 ] Irina Boverman commented on PROTON-831: --- Added patch to resolve the issue. Rebuilt and ran tests, all passed 100%. proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5 - Key: PROTON-831 URL: https://issues.apache.org/jira/browse/PROTON-831 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Environment: RHEL 5 Reporter: Irina Boverman Priority: Minor Attachments: PROTON-831.patch proton_tests.utils.SyncRequestResponseTest.test_request_response fail Error during test: Traceback (most recent call last): File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton-test, line 355, in run phase() File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 92, in test_request_response test(foo) # Simple request/resposne File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 82, in test response = client.call(Message(address=address, body=body)) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 315, in call self.sender.send(request) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 76, in send delivery = self.link.send(msg) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2845, in send return obj.send(self, tag=tag) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 1098, in send dlv = sender.delivery(tag or sender.delivery_tag()) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2858, in delivery_tag return next(self.tag_generator) NameError: global name 'next' is not defined Suggested fix (contributed by Ted Ross): Seems the next builtin function was introduced in Python 2.6. Perhaps this should be changed to: return self.tag_generator.next() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: I think that's a blocker...
The Proton IOCP implementation provides a reactor capability over the proactor API, which mostly works as you expect. I would remind folks of the following Windows-isms compared to POSIX: Windows was late to the tcp/ip party (championing LAN Manager) and 3rd parties provided tcp/ip stacks for a long time. A socket was an alien entity that was supposed to use different APIs from other file handle things. This persists to this day and is why you can't mix a Windows pipe and socket in a single Windows selection mechanism. Hence the documented restrictions on pn_pipe(). Well you can mix them in IOCP, because that came along after Microsoft was in the tcp/ip game. But that has other consequences: a socket doesn't have fluid usage in IOCP since it can be bound only once. Once selected within Proton, it cannot be used in another IOCP context elsewhere. Proton can support external loops provide its own loop allow applications to completely manage IO themselves (i.e. qpid cpp) Proton appears to be close to supporting a Dispatch-level of concurrency. Is the above enough, or do we have to find extensions to these that are useful to developers but don't stretch the differences between Windows and POSIX beyond possibility? On Thu, Feb 26, 2015 at 12:22 PM, Andrew Stitcher astitc...@redhat.com wrote: On Thu, 2015-02-26 at 15:09 -0500, Rafael Schloming wrote: ... It sounds like one way or another we need at least some design changes. I don't think it's workable to have overlapping/close but distinct semantics for the API on different platforms (e.g. you can move sockets on one platform but not on another). I'm starting to think we either need one platform to precisely and fully emulate the semantics of the other platform, or they both need to implement some interface that is slightly higher level and can better accommodate the differences. I may have misremembered, but I think the essential platform difference here is that Windows IOCP really tries to implement a Proactor type of pattern rather than the reactor type of pattern that we are using in Proton. [Proactor is where fundamentally the system calls back a processing function on a thread that you give it] In the qpid implementation I had to effectively make the exposed interface a proactor type interface in all platforms, to bridge the gap. I'm not sure this is workable in a context where the user can supply their own event loop. Andrew
GitHub integration tweaks
Hi all, I'm sure some of you already noticed me spamming the JIRA projects and mailing lists already when testing this, but just incase you didnt or wondered what I was doing... I asked infra via [1] and [2] to enable/fix some of the extra GitHub integration bits for our four GitHub mirrors (the qpid and dispatch git-svn mirrors, and the qpid-proton and qpid-jms git mirrors). The summary is: - Pull Requests opened at GitHub will be emailed to the dev@ or proton@ lists, and a comment placed on any JIRA mentioned in the title. - Commenting on the PR at GitHub will result in the same. - Replying to the emails on the mailing list will add a comment on the PR. Robbie [1] https://issues.apache.org/jira/browse/INFRA-9073 [2] https://issues.apache.org/jira/browse/INFRA-9208
[jira] [Created] (PROTON-831) proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5
Irina Boverman created PROTON-831: - Summary: proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5 Key: PROTON-831 URL: https://issues.apache.org/jira/browse/PROTON-831 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Environment: RHEL 5 Reporter: Irina Boverman Priority: Minor proton_tests.utils.SyncRequestResponseTest.test_request_response fail Error during test: Traceback (most recent call last): File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton-test, line 355, in run phase() File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 92, in test_request_response test(foo) # Simple request/resposne File /var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py, line 82, in test response = client.call(Message(address=address, body=body)) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 315, in call self.sender.send(request) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py, line 76, in send delivery = self.link.send(msg) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2845, in send return obj.send(self, tag=tag) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 1098, in send dlv = sender.delivery(tag or sender.delivery_tag()) File /var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py, line 2858, in delivery_tag return next(self.tag_generator) NameError: global name 'next' is not defined Suggested fix (contributed by Ted Ross): Seems the next builtin function was introduced in Python 2.6. Perhaps this should be changed to: return self.tag_generator.next() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: GitHub integration tweaks
This is awesome! Good job. Rajith On Fri, Feb 27, 2015 at 1:58 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, I'm sure some of you already noticed me spamming the JIRA projects and mailing lists already when testing this, but just incase you didnt or wondered what I was doing... I asked infra via [1] and [2] to enable/fix some of the extra GitHub integration bits for our four GitHub mirrors (the qpid and dispatch git-svn mirrors, and the qpid-proton and qpid-jms git mirrors). The summary is: - Pull Requests opened at GitHub will be emailed to the dev@ or proton@ lists, and a comment placed on any JIRA mentioned in the title. - Commenting on the PR at GitHub will result in the same. - Replying to the emails on the mailing list will add a comment on the PR. Robbie [1] https://issues.apache.org/jira/browse/INFRA-9073 [2] https://issues.apache.org/jira/browse/INFRA-9208
[jira] [Commented] (PROTON-827) Reactive client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340690#comment-14340690 ] Justin Ross commented on PROTON-827: List discussion: https://issues.apache.org/jira/browse/PROTON-827 Reactive client binding for the go programming language. -- Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-827) Reactive client binding for the go programming language.
[ https://issues.apache.org/jira/browse/PROTON-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14340690#comment-14340690 ] Justin Ross edited comment on PROTON-827 at 2/27/15 7:46 PM: - List discussion: http://qpid.2158936.n2.nabble.com/PROTON-827-Reactive-client-binding-for-the-quot-go-quot-programming-language-td7621025.html was (Author: justi9): List discussion: https://issues.apache.org/jira/browse/PROTON-827 Reactive client binding for the go programming language. -- Key: PROTON-827 URL: https://issues.apache.org/jira/browse/PROTON-827 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Develop a reactive API binding in go http://golang.org/, similar to the existing reactive python API illustrated in examples/python. It should follow the pattern of the existing python and C reactive APIs as far as possible while respecting common conventions and idioms of the go langauge. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposed SASL changes (API and functional)
On 26 February 2015 at 17:52, Andrew Stitcher astitc...@redhat.com wrote: On Thu, 2015-02-26 at 12:28 +, Robbie Gemmell wrote: ... I'm going to post my comments here and on the wiki, as I dont think many (except maybe you) will actually see them on the wiki ;) Thank you for the excellent feedback. I'm going to answer on the wiki - as it'll save me from cutting and pasting. [I did try to add the lists as watchers, but that doesn't seem to be possible in any obvious way] wiki link: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51812103focusedCommentId=51812468#comment-51812468 Andrew Replied on the Wiki, but also including below for anyone not clicking these links ;) https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51812103focusedCommentId=51812571#comment-51812571 3. Do you really mean to have only ANONYMOUS for 0.9 for Proton-J? That would render it fairly useless if the existing transport/sasl API is removed since that would prevent people using any existing implementation they already have (ANONYMOUS, PLAIN, CRAM-MD5 thus far for the JMS client, with EXTERNAL sitting on the TODO list). 4. I do still think there is a change (by having to handle the SASL previously, you would always know the authentication result before the connection ever happened, and you had to call done on the server to say it was, whereas now you get a transport event in either case), but I take your point that you could adjust to waiting for the successful connection open state/event to be reached and both approaches would then appear to work the same from that point. 5. I'd say the positive list of mechs to use is more straight forward in many scenarios, and the exclusion list could work better in some others. Offering both options would let people do whatever they want. - The exclusion list might be something you used initially to e.g prevent use of ANONYMOUS, but you have that scenario covered by pn_transport_require_auth already. - After that, it is presumably to be used for things like disabling mechs that are either not considered secure enough (e.g PLAIN, because you are requiring everying uses SCRAM-SHA-foo today because its Friday), or are installed but not configured/usable (e.g GSSAPI as you mentioned). Between those, you would need to know the name of every mechanism that could ever be present, and then exclude them all in case they should be installed (possibly later). Or, you might better get what you want by being able to specify only the mechs you want to be enabled and have already installed as a result. - On what to do to do if a positively-requested mechanism isnt available, as I said we could posibly give the choice of of throwing to indicate the requirement couldn't be met or potentially making that optional, because if you positively-specify more than one you probabyl dont care which is used too much. 6. I saw the deprecation, but I wasnt aware the default had already been changed for allow skip, was that ever mentioned anywhere, e.g a JIRA raised to cover a significant change in behaviour? I think its the wrong decision personally, and code using the engine should have to opt-in to permitting non-SASL connections (and ANONYMOUS). If the rest of the current SASL API is going away and the default remains changed, then it seems allow skip should probably just be removed too, since its very likely the only people using it will be configuring the new behaviour and there is a new API for anyone wanting to configure the historical default behaviour when they realise (this will presumably be release-noted?) it becomes necessary to secure it with the new release.
