[jira] [Resolved] (PROTON-940) provide the session initial incoming window via Begin rather than sending a separate Flow
[ https://issues.apache.org/jira/browse/PROTON-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-940. --- Resolution: Fixed provide the session initial incoming window via Begin rather than sending a separate Flow - Key: PROTON-940 URL: https://issues.apache.org/jira/browse/PROTON-940 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-940-calculate-the-incoming-window-before-send.patch When a session is created, a Begin frame is sent. One of the fields on the frame is the initial incoming window. Instead of populating the field, Proton-J currently sets it to 0 but then immediately discovers the window is 0 and sends a seperate Flow frame (in the same transport output sas the Begin frame) changing the window to the actual calculated value. This result is equivalent in the end and allowed by the protocol, but is not particularly obvious behaviour and is different than proton-c. The initial incoming window value should be conveyed in the Begin frame instead, removing need for the immediate Flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proton Devs using Linux: please run the python-tox-test unit tests!!
ubuntu3 is probably the single oldest node in the group, so I wouldnt be surprised if it didnt have python3. I'm surprised it hasn't been pulled from service yet actually. We can ask for things to be installed by raising a JIRA at https://issues.apache.org/jira/browse/BUILDS though it woudl probably be more fuitful to do that in regards to getting the job running on the other nodes . I believe there are also some cloud based dynamic nodes, and some running docker...but their possible existence is about as much as I know about that. Robbie On 9 July 2015 at 15:28, Ken Giusti kgiu...@redhat.com wrote: Apparently ubuntu3 doesn't have 'pip' installed, so our jenkin's script can't pull down tox and run the python-tox-test. Assuming ubuntu3 is really old, it probably doesn't have python3 installed either (just a guess). So even if we had pip/tox installed, the tests would only run under python2 anyways. -K - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Thursday, July 9, 2015 9:45:10 AM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! One thing that may or may not come up is that the job on the ASF Jenkins is tied to run only on the 'legacy-ubuntu' label currently, which only includes the old ubuntu3 node. All the other Ubuntu nodes are newer but the build was failing on many of them due to needing packages installed, so it isnt running on those currently. Robbie On 8 July 2015 at 18:30, Dominic Evans dominic.ev...@uk.ibm.com wrote: I do have an unpushed change that partially enables it for travis. I'll push later tonight. On 8 Jul 2015, at 18:27, Ken Giusti kgiu...@redhat.com wrote: Good point, I'll see what I can do on that front. - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Wednesday, July 8, 2015 12:21:57 PM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! On 8 July 2015 at 15:48, Ken Giusti kgiu...@redhat.com wrote: Devs, As you probably know, I've pushed changes to the proton python bindings that make proton compatible with python3. Since then, I've hit bugs in the python3 stuff that could've been caught by running the above unit test on a linux system that has python3 installed. This test currently only runs on linux, and requires both python3 and extra python tools be installed in order to run it. I suspect most devs don't have these tools installed by default. If the tools are not available - or are not current - ctest will skip running these tests. Most current linux distros - I'm running Fedora 21 btw - support installing both python2.x and python3.x in parallel. Most default to just having python 2.x installed - you usually have to install python3 manually. Once you have python3 installed, you will also need to have an up-to-date version of the 'tox' and 'virtualenv' tools installed. For example, on my F21 box: sudo yum install python-tox python-virtualenv does the trick. Note: the unit tests require version 1.7+ of python-tox. If that isn't available to you, you can use 'python-pip' to either overwrite the installed version of tox with a newer one, or install a local copy of tox in your home directory: $ sudo pip install -U tox # this overwrites or $ pip install --user -U tox # will put tox in ~/.local - you'll have to update your PATH/PYTHONPATH to look there Once all that is done, a simple 'make test' should run the python-tox-test. Doing all this is optional, and will increase the time it takes to run the unit tests, but it prevent inadvertent regressions to the python3 support. And it will greatly appreciated by yours truly! thanks all, -K It would probably help if some or all of the CI environments (ASF Jenkins, Travis CI, Appveyor) we have checking thing over were set up to do this. Robbie -- -K -- -K On 9 July 2015 at 15:28, Ken Giusti kgiu...@redhat.com wrote: Apparently ubuntu3 doesn't have 'pip' installed, so our jenkin's script can't pull down tox and run the python-tox-test. Assuming ubuntu3 is really old, it probably doesn't have python3 installed either (just a guess). So even if we had pip/tox installed, the tests would only run under python2 anyways. -K - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Thursday, July 9, 2015 9:45:10 AM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! One thing that may or may not come up is that the job on the ASF Jenkins is tied to run only on the 'legacy-ubuntu' label currently, which only includes the old ubuntu3 node. All the other Ubuntu nodes are newer but the build was failing on many of them due to needing packages installed,
Re: [1/2] qpid-proton git commit: PROTON-937: LinkImpl.localOpen() does not initialize source and target
On 8. 07. 15 18.16, Robbie Gemmell wrote: Hi Bozzo, some comments and questions. I am seeing test failures due to NPE's from the new code: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1043/ There should be null checks on the remote Source and Target before trying to copy them, since there are cases where they are allowed and expected to be null (though in the failing tests its not clear the they fall in to those, so much as perhaps not bothering to set them as they werent of interest for the test). I see you listed the change as a bug, but I can't say I was ever under the impression it should do this (though I can certainly see it makes life easier in some cases). Does proton-c do this and proton-j did not? I reverted this, and will do it properly. Proton-c does do it in the handshaker and in the messenger. Just do a git grep pn_terminus_copy. And yes, it has a check so it doesn't try to copy non-existing stuff. In which case the copy returns an error, which handshaker ignores :) For some unexplicable reason I thought the LinkImpl.localOpen was a better place to do it while it's perfectly easy to do in in the Handshaker.onLinkRemoteOpen() and the messenger already does it in a way. //TODO: the following is not correct; should only copy those properties that we understand link.setSource(link.getRemoteSource()); link.setTarget(link.getRemoteTarget()); If we are doing this for Source and Target objects, should it not also work for the Coordinator? Seems a bit unfair to leave it out given the method was added. I've yet to come up-to-speed with the Coordinator, so cannot comment here :) Please don't use if statements without braces, someone will inevitably screw it up when updating things later :) Agree, too much switching between python and Java and C in one day :) Bozzo
Re: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks
Thanks Bozzo, that sorts those failures (so long as the issue from your other change is worked around, to let the build get that far). Robbie On 9 July 2015 at 11:22, Bozo Dragojevic bo...@digiverse.si wrote: Hi Robbie, Yeah, my bad. I was sitting on some local changes so I missed this. I'll test on a clean checkout next time. Sorry for all the mess. I've commited the missing methods to proton-j Bozzo On 9. 07. 15 12.14, Robbie Gemmell wrote: Hi Bozzo, This change also seems to be causing test failures when using the maven build (if you update things to get past the earlier failures, caused by the commit mentioned in the other thread on proton@): proton_tests.reactor.ExceptionTest.test_schedule_cancel . fail Error during test: Traceback (most recent call last): File /home/gemmellr/workspace/proton/tests/python/proton-test, line 360, in run phase() File /home/gemmellr/workspace/proton/tests/python/proton_tests/reactor.py, line 181, in test_schedule_cancel now = self.reactor.mark() File /home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/reactor.py, line 118, in mark return pn_reactor_mark(self._impl) NameError: global name 'pn_reactor_mark' is not defined Robbie On 9 July 2015 at 10:55, Bozo Dragojevic bo...@digiverse.si wrote: Hi Ken, I've installed python3.4 and tox and friends and tried to reproduce it here and I can confirm that some completely unrelated test fail mysteriously with python3.4 and that reverting my change makes that failure go away :) I've added more task cancellation tests to force the error while still in the implicated code, as I suspected it could be some refcounting problem but the new tests do not show anything unusual. What is even weirder, with the new tests even the python3.4 suite passes without segfault! So, I consider this a false positive and have left the change in, including the new tests at ca47d72. Does such solution work for you? Bozzo On 8. 07. 15 16.32, Ken Giusti wrote: Hi Bozzo, Can you please revert this change? It is causing a segfault in the python unit tests when they are run under python3.4. I haven't hit the segfault on python2.7, only on python3.4 thanks, -K - Original Message - From: bo...@apache.org To: comm...@qpid.apache.org Sent: Tuesday, July 7, 2015 3:50:16 PM Subject: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks PROTON-928: cancellable tasks A scheduled task can be cancelled. A cancelled task does not prevent reactor from stopping running Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/d4d22ee3 Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/d4d22ee3 Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/d4d22ee3 Branch: refs/heads/master Commit: d4d22ee396163babcac19c48845b1f10ca3b5a48 Parents: 09af375 Author: Bozo Dragojevic bo...@digiverse.si Authored: Tue Jul 7 10:17:40 2015 +0200 Committer: Bozo Dragojevic bo...@digiverse.si Committed: Tue Jul 7 21:49:44 2015 +0200 -- proton-c/bindings/python/proton/reactor.py | 5 +++- proton-c/include/proton/reactor.h | 1 + proton-c/src/reactor/timer.c| 25 +++- proton-c/src/tests/reactor.c| 15 .../org/apache/qpid/proton/reactor/Task.java| 4 .../qpid/proton/reactor/impl/TaskImpl.java | 10 .../apache/qpid/proton/reactor/impl/Timer.java | 19 --- proton-j/src/main/resources/creactor.py | 3 +++ tests/python/proton_tests/reactor.py| 14 +++ 9 files changed, 91 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/bindings/python/proton/reactor.py -- diff --git a/proton-c/bindings/python/proton/reactor.py b/proton-c/bindings/python/proton/reactor.py index c66334b..d019554 100644 --- a/proton-c/bindings/python/proton/reactor.py +++ b/proton-c/bindings/python/proton/reactor.py @@ -53,6 +53,9 @@ class Task(Wrapper): def _init(self): pass +def cancel(self): +pn_task_cancel(self._impl) + class Acceptor(Wrapper): def __init__(self, impl): @@ -112,7 +115,7 @@ class Reactor(Wrapper): pn_reactor_yield(self._impl) def mark(self): -pn_reactor_mark(self._impl) +return pn_reactor_mark(self._impl) def _get_handler(self): return WrappedHandler.wrap(pn_reactor_get_handler(self._impl), self.on_error) http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/include/proton/reactor.h
Fwd: [1/2] qpid-proton git commit: PROTON-937: LinkImpl.localOpen() does not initialize source and target
Sending to the list... -- Forwarded message -- From: Robbie Gemmell robbie.gemm...@gmail.com Date: 9 July 2015 at 12:35 Subject: Re: [1/2] qpid-proton git commit: PROTON-937: LinkImpl.localOpen() does not initialize source and target To: Bozo Dragojevic bo...@digiverse.si On 9 July 2015 at 12:23, Bozo Dragojevic bo...@digiverse.si wrote: On 8. 07. 15 18.16, Robbie Gemmell wrote: Hi Bozzo, some comments and questions. I am seeing test failures due to NPE's from the new code: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1043/ There should be null checks on the remote Source and Target before trying to copy them, since there are cases where they are allowed and expected to be null (though in the failing tests its not clear the they fall in to those, so much as perhaps not bothering to set them as they werent of interest for the test). I see you listed the change as a bug, but I can't say I was ever under the impression it should do this (though I can certainly see it makes life easier in some cases). Does proton-c do this and proton-j did not? I reverted this, and will do it properly. Great, thanks. Proton-c does do it in the handshaker and in the messenger. Just do a git grep pn_terminus_copy. And yes, it has a check so it doesn't try to copy non-existing stuff. In which case the copy returns an error, which handshaker ignores :) For some unexplicable reason I thought the LinkImpl.localOpen was a better place to do it while it's perfectly easy to do in in the Handshaker.onLinkRemoteOpen() and the messenger already does it in a way. //TODO: the following is not correct; should only copy those properties that we understand link.setSource(link.getRemoteSource()); link.setTarget(link.getRemoteTarget()); Yes, doing it in Handshaker / Messenger is quite different than doing so within the link object itself, and more in line with what I would expect. The comment in the above snippet is another reason doing it in the link would cause issues. If we are doing this for Source and Target objects, should it not also work for the Coordinator? Seems a bit unfair to leave it out given the method was added. I've yet to come up-to-speed with the Coordinator, so cannot comment here :) Please don't use if statements without braces, someone will inevitably screw it up when updating things later :) Agree, too much switching between python and Java and C in one day :) Bozzo
[GitHub] qpid-proton pull request: PROTON-936 session outgoing window handl...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/42 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-936) update session outgoing window handling
[ https://issues.apache.org/jira/browse/PROTON-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620373#comment-14620373 ] ASF subversion and git services commented on PROTON-936: Commit a02ad90cab9af446e8251157a1525e3413776934 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a02ad90 ] PROTON-936: make the session outgoing window a fixed value, defaulted very large but configurable if needed update session outgoing window handling --- Key: PROTON-936 URL: https://issues.apache.org/jira/browse/PROTON-936 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 As discussed on the mailing lists \[1\], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionall, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. We should update the outgoing window to address these issues. \[1\] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-936) update session outgoing window handling
[ https://issues.apache.org/jira/browse/PROTON-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620374#comment-14620374 ] ASF GitHub Bot commented on PROTON-936: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/42 update session outgoing window handling --- Key: PROTON-936 URL: https://issues.apache.org/jira/browse/PROTON-936 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 As discussed on the mailing lists \[1\], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionall, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. We should update the outgoing window to address these issues. \[1\] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-936) update session outgoing window handling
[ https://issues.apache.org/jira/browse/PROTON-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-936. --- Resolution: Fixed update session outgoing window handling --- Key: PROTON-936 URL: https://issues.apache.org/jira/browse/PROTON-936 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.10 As discussed on the mailing lists \[1\], proton currently sets the outgoing window to 0 in most cases (except when using Messenger), but then sends messages anyway if allowed by the current remote-outgoing-window. This means it is typically violating the advertised window. Additionall, Service Bus uses the outgoing window to initialise its incoming window, which means it is set to 0 and we can never send it any messages. We should update the outgoing window to address these issues. \[1\] http://mail-archives.apache.org/mod_mbox/qpid-users/201507.mbox/%3CCAFitrpQoK8SFgd1xXPtc9PeNWwWcEqtJgN8ZN88RBj3u6fwdag%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proton Devs using Linux: please run the python-tox-test unit tests!!
Is it worth putting some version of this in DEVELOPERS.md? --Rafael On Wed, Jul 8, 2015 at 7:48 AM, Ken Giusti kgiu...@redhat.com wrote: Devs, As you probably know, I've pushed changes to the proton python bindings that make proton compatible with python3. Since then, I've hit bugs in the python3 stuff that could've been caught by running the above unit test on a linux system that has python3 installed. This test currently only runs on linux, and requires both python3 and extra python tools be installed in order to run it. I suspect most devs don't have these tools installed by default. If the tools are not available - or are not current - ctest will skip running these tests. Most current linux distros - I'm running Fedora 21 btw - support installing both python2.x and python3.x in parallel. Most default to just having python 2.x installed - you usually have to install python3 manually. Once you have python3 installed, you will also need to have an up-to-date version of the 'tox' and 'virtualenv' tools installed. For example, on my F21 box: sudo yum install python-tox python-virtualenv does the trick. Note: the unit tests require version 1.7+ of python-tox. If that isn't available to you, you can use 'python-pip' to either overwrite the installed version of tox with a newer one, or install a local copy of tox in your home directory: $ sudo pip install -U tox # this overwrites or $ pip install --user -U tox # will put tox in ~/.local - you'll have to update your PATH/PYTHONPATH to look there Once all that is done, a simple 'make test' should run the python-tox-test. Doing all this is optional, and will increase the time it takes to run the unit tests, but it prevent inadvertent regressions to the python3 support. And it will greatly appreciated by yours truly! thanks all, -K
Re: Proton Devs using Linux: please run the python-tox-test unit tests!!
- Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Thursday, July 9, 2015 8:18:25 AM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! Is it worth putting some version of this in DEVELOPERS.md? --Rafael That's a great idea - I'll see to it. On Wed, Jul 8, 2015 at 7:48 AM, Ken Giusti kgiu...@redhat.com wrote: Devs, As you probably know, I've pushed changes to the proton python bindings that make proton compatible with python3. Since then, I've hit bugs in the python3 stuff that could've been caught by running the above unit test on a linux system that has python3 installed. This test currently only runs on linux, and requires both python3 and extra python tools be installed in order to run it. I suspect most devs don't have these tools installed by default. If the tools are not available - or are not current - ctest will skip running these tests. Most current linux distros - I'm running Fedora 21 btw - support installing both python2.x and python3.x in parallel. Most default to just having python 2.x installed - you usually have to install python3 manually. Once you have python3 installed, you will also need to have an up-to-date version of the 'tox' and 'virtualenv' tools installed. For example, on my F21 box: sudo yum install python-tox python-virtualenv does the trick. Note: the unit tests require version 1.7+ of python-tox. If that isn't available to you, you can use 'python-pip' to either overwrite the installed version of tox with a newer one, or install a local copy of tox in your home directory: $ sudo pip install -U tox # this overwrites or $ pip install --user -U tox # will put tox in ~/.local - you'll have to update your PATH/PYTHONPATH to look there Once all that is done, a simple 'make test' should run the python-tox-test. Doing all this is optional, and will increase the time it takes to run the unit tests, but it prevent inadvertent regressions to the python3 support. And it will greatly appreciated by yours truly! thanks all, -K -- -K
Re: [1/2] qpid-proton git commit: PROTON-937: LinkImpl.localOpen() does not initialize source and target
Thinking this through further, there are also cases where you actually want to set the source/target to be null when the remote versions were originally not, which this change would somewhat break. I think we need to revert this for now and look to do something after the release, once the approach is clearer and it is actually tested etc. The NPEs from the change are also causing the CI jobs to hang, I just killed one running since yesterday (and updated the job to have a timeout to ensure it doesnt happen again), https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/716. It got this far and then nothing else was logged. Obviously this might also point to an issue with the new reactor bits and its tests. proton_tests.reactor_interop.ReactorInteropTest. \ test_protonj_to_protonc_1 ...org.apache.qpid.proton.engine.HandlerException: java.lang.NullPointerException at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:212) at org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:269) at org.apache.qpid.proton.reactor.impl.ReactorImpl.run(ReactorImpl.java:332) at org.apache.qpid.proton.ProtonJInterop.main(ProtonJInterop.java:190) Caused by: java.lang.NullPointerException at org.apache.qpid.proton.engine.impl.LinkImpl.localOpen(LinkImpl.java:422) at org.apache.qpid.proton.engine.impl.EndpointImpl.open(EndpointImpl.java:74) at org.apache.qpid.proton.ProtonJInterop$SendHandler.onConnectionInit(ProtonJInterop.java:66) at org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:88) ... 3 more Tweaking things to remove the NPE, I still see another test failure in the maven build: proton_tests.reactor.ExceptionTest.test_schedule_cancel . fail Error during test: Traceback (most recent call last): File /home/gemmellr/workspace/proton/tests/python/proton-test, line 360, in run phase() File /home/gemmellr/workspace/proton/tests/python/proton_tests/reactor.py, line 181, in test_schedule_cancel now = self.reactor.mark() File /home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/reactor.py, line 118, in mark return pn_reactor_mark(self._impl) NameError: global name 'pn_reactor_mark' is not defined Robbie On 8 July 2015 at 17:16, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi Bozzo, some comments and questions. I am seeing test failures due to NPE's from the new code: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1043/ There should be null checks on the remote Source and Target before trying to copy them, since there are cases where they are allowed and expected to be null (though in the failing tests its not clear the they fall in to those, so much as perhaps not bothering to set them as they werent of interest for the test). I see you listed the change as a bug, but I can't say I was ever under the impression it should do this (though I can certainly see it makes life easier in some cases). Does proton-c do this and proton-j did not? If we are doing this for Source and Target objects, should it not also work for the Coordinator? Seems a bit unfair to leave it out given the method was added. Please don't use if statements without braces, someone will inevitably screw it up when updating things later :) Robbie On 7 July 2015 at 20:50, bo...@apache.org wrote: Repository: qpid-proton Updated Branches: refs/heads/master 09af37524 - f6d74a47d PROTON-937: LinkImpl.localOpen() does not initialize source and target Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/f6d74a47 Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/f6d74a47 Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/f6d74a47 Branch: refs/heads/master Commit: f6d74a47d1f3f4ee3f4f3a444e239a209276f928 Parents: d4d22ee Author: Bozo Dragojevic bo...@digiverse.si Authored: Tue Jul 7 21:32:58 2015 +0200 Committer: Bozo Dragojevic bo...@digiverse.si Committed: Tue Jul 7 21:49:44 2015 +0200 -- .../qpid/proton/amqp/messaging/Source.java | 19 +++ .../qpid/proton/amqp/messaging/Target.java | 12 .../qpid/proton/amqp/messaging/Terminus.java | 17 + .../proton/amqp/transaction/Coordinator.java | 5 + .../qpid/proton/amqp/transport/Source.java | 2 ++ .../qpid/proton/amqp/transport/Target.java | 2 ++ .../apache/qpid/proton/engine/impl/LinkImpl.java | 4 7 files changed, 61 insertions(+) -- http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/f6d74a47/proton-j/src/main/java/org/apache/qpid/proton/amqp/messaging/Source.java
[jira] [Commented] (PROTON-928) Cancellable tasks
[ https://issues.apache.org/jira/browse/PROTON-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620203#comment-14620203 ] ASF subversion and git services commented on PROTON-928: Commit ca47d7260da1052e26cc8cac0997c6a1e491d5ef in qpid-proton's branch refs/heads/master from [~bozzo] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ca47d72 ] PROTON-928: add more task cancellation tests Cancellable tasks - Key: PROTON-928 URL: https://issues.apache.org/jira/browse/PROTON-928 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j, python-binding Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic Allow scheduled tasks to be cancelled. A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks
Hi Ken,
I've installed python3.4 and tox and friends and tried to reproduce it here
and I can confirm that some completely unrelated test fail mysteriously
with python3.4 and that reverting my change makes that failure go away :)
I've added more task cancellation tests to force the error while still
in the implicated code, as I suspected it could be some refcounting
problem but the new tests do not show anything unusual.
What is even weirder, with the new tests even the python3.4 suite passes
without segfault!
So, I consider this a false positive and have left the change in,
including the new tests at ca47d72.
Does such solution work for you?
Bozzo
On 8. 07. 15 16.32, Ken Giusti wrote:
Hi Bozzo,
Can you please revert this change?
It is causing a segfault in the python unit tests when they are run under
python3.4.
I haven't hit the segfault on python2.7, only on python3.4
thanks,
-K
- Original Message -
From: bo...@apache.org
To: comm...@qpid.apache.org
Sent: Tuesday, July 7, 2015 3:50:16 PM
Subject: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks
PROTON-928: cancellable tasks
A scheduled task can be cancelled.
A cancelled task does not prevent reactor from stopping running
Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo
Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/d4d22ee3
Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/d4d22ee3
Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/d4d22ee3
Branch: refs/heads/master
Commit: d4d22ee396163babcac19c48845b1f10ca3b5a48
Parents: 09af375
Author: Bozo Dragojevic bo...@digiverse.si
Authored: Tue Jul 7 10:17:40 2015 +0200
Committer: Bozo Dragojevic bo...@digiverse.si
Committed: Tue Jul 7 21:49:44 2015 +0200
--
proton-c/bindings/python/proton/reactor.py | 5 +++-
proton-c/include/proton/reactor.h | 1 +
proton-c/src/reactor/timer.c| 25 +++-
proton-c/src/tests/reactor.c| 15
.../org/apache/qpid/proton/reactor/Task.java| 4
.../qpid/proton/reactor/impl/TaskImpl.java | 10
.../apache/qpid/proton/reactor/impl/Timer.java | 19 ---
proton-j/src/main/resources/creactor.py | 3 +++
tests/python/proton_tests/reactor.py| 14 +++
9 files changed, 91 insertions(+), 5 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/bindings/python/proton/reactor.py
--
diff --git a/proton-c/bindings/python/proton/reactor.py
b/proton-c/bindings/python/proton/reactor.py
index c66334b..d019554 100644
--- a/proton-c/bindings/python/proton/reactor.py
+++ b/proton-c/bindings/python/proton/reactor.py
@@ -53,6 +53,9 @@ class Task(Wrapper):
def _init(self):
pass
+def cancel(self):
+pn_task_cancel(self._impl)
+
class Acceptor(Wrapper):
def __init__(self, impl):
@@ -112,7 +115,7 @@ class Reactor(Wrapper):
pn_reactor_yield(self._impl)
def mark(self):
-pn_reactor_mark(self._impl)
+return pn_reactor_mark(self._impl)
def _get_handler(self):
return WrappedHandler.wrap(pn_reactor_get_handler(self._impl),
self.on_error)
http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/include/proton/reactor.h
--
diff --git a/proton-c/include/proton/reactor.h
b/proton-c/include/proton/reactor.h
index 59b2282..6f52d22 100644
--- a/proton-c/include/proton/reactor.h
+++ b/proton-c/include/proton/reactor.h
@@ -96,6 +96,7 @@ PN_EXTERN pn_task_t *pn_timer_schedule(pn_timer_t *timer,
pn_timestamp_t deadlin
PN_EXTERN int pn_timer_tasks(pn_timer_t *timer);
PN_EXTERN pn_record_t *pn_task_attachments(pn_task_t *task);
+PN_EXTERN void pn_task_cancel(pn_task_t *task);
PN_EXTERN pn_reactor_t *pn_class_reactor(const pn_class_t *clazz, void
*object);
PN_EXTERN pn_reactor_t *pn_object_reactor(void *object);
http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/src/reactor/timer.c
--
diff --git a/proton-c/src/reactor/timer.c b/proton-c/src/reactor/timer.c
index 1ad0821..61efd31 100644
--- a/proton-c/src/reactor/timer.c
+++ b/proton-c/src/reactor/timer.c
@@ -27,12 +27,14 @@ struct pn_task_t {
pn_list_t *pool;
pn_record_t *attachments;
pn_timestamp_t deadline;
+ bool cancelled;
};
void pn_task_initialize(pn_task_t *task) {
task-pool = NULL;
task-attachments = pn_record();
task-deadline = 0;
+ task-cancelled = false;
}
void
Re: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks
Hi Bozzo, This change also seems to be causing test failures when using the maven build (if you update things to get past the earlier failures, caused by the commit mentioned in the other thread on proton@): proton_tests.reactor.ExceptionTest.test_schedule_cancel . fail Error during test: Traceback (most recent call last): File /home/gemmellr/workspace/proton/tests/python/proton-test, line 360, in run phase() File /home/gemmellr/workspace/proton/tests/python/proton_tests/reactor.py, line 181, in test_schedule_cancel now = self.reactor.mark() File /home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/reactor.py, line 118, in mark return pn_reactor_mark(self._impl) NameError: global name 'pn_reactor_mark' is not defined Robbie On 9 July 2015 at 10:55, Bozo Dragojevic bo...@digiverse.si wrote: Hi Ken, I've installed python3.4 and tox and friends and tried to reproduce it here and I can confirm that some completely unrelated test fail mysteriously with python3.4 and that reverting my change makes that failure go away :) I've added more task cancellation tests to force the error while still in the implicated code, as I suspected it could be some refcounting problem but the new tests do not show anything unusual. What is even weirder, with the new tests even the python3.4 suite passes without segfault! So, I consider this a false positive and have left the change in, including the new tests at ca47d72. Does such solution work for you? Bozzo On 8. 07. 15 16.32, Ken Giusti wrote: Hi Bozzo, Can you please revert this change? It is causing a segfault in the python unit tests when they are run under python3.4. I haven't hit the segfault on python2.7, only on python3.4 thanks, -K - Original Message - From: bo...@apache.org To: comm...@qpid.apache.org Sent: Tuesday, July 7, 2015 3:50:16 PM Subject: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks PROTON-928: cancellable tasks A scheduled task can be cancelled. A cancelled task does not prevent reactor from stopping running Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/d4d22ee3 Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/d4d22ee3 Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/d4d22ee3 Branch: refs/heads/master Commit: d4d22ee396163babcac19c48845b1f10ca3b5a48 Parents: 09af375 Author: Bozo Dragojevic bo...@digiverse.si Authored: Tue Jul 7 10:17:40 2015 +0200 Committer: Bozo Dragojevic bo...@digiverse.si Committed: Tue Jul 7 21:49:44 2015 +0200 -- proton-c/bindings/python/proton/reactor.py | 5 +++- proton-c/include/proton/reactor.h | 1 + proton-c/src/reactor/timer.c| 25 +++- proton-c/src/tests/reactor.c| 15 .../org/apache/qpid/proton/reactor/Task.java| 4 .../qpid/proton/reactor/impl/TaskImpl.java | 10 .../apache/qpid/proton/reactor/impl/Timer.java | 19 --- proton-j/src/main/resources/creactor.py | 3 +++ tests/python/proton_tests/reactor.py| 14 +++ 9 files changed, 91 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/bindings/python/proton/reactor.py -- diff --git a/proton-c/bindings/python/proton/reactor.py b/proton-c/bindings/python/proton/reactor.py index c66334b..d019554 100644 --- a/proton-c/bindings/python/proton/reactor.py +++ b/proton-c/bindings/python/proton/reactor.py @@ -53,6 +53,9 @@ class Task(Wrapper): def _init(self): pass +def cancel(self): +pn_task_cancel(self._impl) + class Acceptor(Wrapper): def __init__(self, impl): @@ -112,7 +115,7 @@ class Reactor(Wrapper): pn_reactor_yield(self._impl) def mark(self): -pn_reactor_mark(self._impl) +return pn_reactor_mark(self._impl) def _get_handler(self): return WrappedHandler.wrap(pn_reactor_get_handler(self._impl), self.on_error) http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/include/proton/reactor.h -- diff --git a/proton-c/include/proton/reactor.h b/proton-c/include/proton/reactor.h index 59b2282..6f52d22 100644 --- a/proton-c/include/proton/reactor.h +++ b/proton-c/include/proton/reactor.h @@ -96,6 +96,7 @@ PN_EXTERN pn_task_t *pn_timer_schedule(pn_timer_t *timer, pn_timestamp_t deadlin PN_EXTERN int pn_timer_tasks(pn_timer_t *timer); PN_EXTERN pn_record_t *pn_task_attachments(pn_task_t *task);
[jira] [Commented] (PROTON-928) Cancellable tasks
[ https://issues.apache.org/jira/browse/PROTON-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620264#comment-14620264 ] ASF subversion and git services commented on PROTON-928: Commit 5f664ad57d8c42572f5c4e8c18d73fc5520224af in qpid-proton's branch refs/heads/master from [~bozzo] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5f664ad ] PROTON-928: proton-j: Add two missing reactor methods Cancellable tasks - Key: PROTON-928 URL: https://issues.apache.org/jira/browse/PROTON-928 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j, python-binding Reporter: Bozo Dragojevic Assignee: Bozo Dragojevic Allow scheduled tasks to be cancelled. A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks
Hi Robbie, Yeah, my bad. I was sitting on some local changes so I missed this. I'll test on a clean checkout next time. Sorry for all the mess. I've commited the missing methods to proton-j Bozzo On 9. 07. 15 12.14, Robbie Gemmell wrote: Hi Bozzo, This change also seems to be causing test failures when using the maven build (if you update things to get past the earlier failures, caused by the commit mentioned in the other thread on proton@): proton_tests.reactor.ExceptionTest.test_schedule_cancel . fail Error during test: Traceback (most recent call last): File /home/gemmellr/workspace/proton/tests/python/proton-test, line 360, in run phase() File /home/gemmellr/workspace/proton/tests/python/proton_tests/reactor.py, line 181, in test_schedule_cancel now = self.reactor.mark() File /home/gemmellr/workspace/proton/tests/../proton-c/bindings/python/proton/reactor.py, line 118, in mark return pn_reactor_mark(self._impl) NameError: global name 'pn_reactor_mark' is not defined Robbie On 9 July 2015 at 10:55, Bozo Dragojevic bo...@digiverse.si wrote: Hi Ken, I've installed python3.4 and tox and friends and tried to reproduce it here and I can confirm that some completely unrelated test fail mysteriously with python3.4 and that reverting my change makes that failure go away :) I've added more task cancellation tests to force the error while still in the implicated code, as I suspected it could be some refcounting problem but the new tests do not show anything unusual. What is even weirder, with the new tests even the python3.4 suite passes without segfault! So, I consider this a false positive and have left the change in, including the new tests at ca47d72. Does such solution work for you? Bozzo On 8. 07. 15 16.32, Ken Giusti wrote: Hi Bozzo, Can you please revert this change? It is causing a segfault in the python unit tests when they are run under python3.4. I haven't hit the segfault on python2.7, only on python3.4 thanks, -K - Original Message - From: bo...@apache.org To: comm...@qpid.apache.org Sent: Tuesday, July 7, 2015 3:50:16 PM Subject: [2/2] qpid-proton git commit: PROTON-928: cancellable tasks PROTON-928: cancellable tasks A scheduled task can be cancelled. A cancelled task does not prevent reactor from stopping running Project: http://git-wip-us.apache.org/repos/asf/qpid-proton/repo Commit: http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/d4d22ee3 Tree: http://git-wip-us.apache.org/repos/asf/qpid-proton/tree/d4d22ee3 Diff: http://git-wip-us.apache.org/repos/asf/qpid-proton/diff/d4d22ee3 Branch: refs/heads/master Commit: d4d22ee396163babcac19c48845b1f10ca3b5a48 Parents: 09af375 Author: Bozo Dragojevic bo...@digiverse.si Authored: Tue Jul 7 10:17:40 2015 +0200 Committer: Bozo Dragojevic bo...@digiverse.si Committed: Tue Jul 7 21:49:44 2015 +0200 -- proton-c/bindings/python/proton/reactor.py | 5 +++- proton-c/include/proton/reactor.h | 1 + proton-c/src/reactor/timer.c| 25 +++- proton-c/src/tests/reactor.c| 15 .../org/apache/qpid/proton/reactor/Task.java| 4 .../qpid/proton/reactor/impl/TaskImpl.java | 10 .../apache/qpid/proton/reactor/impl/Timer.java | 19 --- proton-j/src/main/resources/creactor.py | 3 +++ tests/python/proton_tests/reactor.py| 14 +++ 9 files changed, 91 insertions(+), 5 deletions(-) -- http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/bindings/python/proton/reactor.py -- diff --git a/proton-c/bindings/python/proton/reactor.py b/proton-c/bindings/python/proton/reactor.py index c66334b..d019554 100644 --- a/proton-c/bindings/python/proton/reactor.py +++ b/proton-c/bindings/python/proton/reactor.py @@ -53,6 +53,9 @@ class Task(Wrapper): def _init(self): pass +def cancel(self): +pn_task_cancel(self._impl) + class Acceptor(Wrapper): def __init__(self, impl): @@ -112,7 +115,7 @@ class Reactor(Wrapper): pn_reactor_yield(self._impl) def mark(self): -pn_reactor_mark(self._impl) +return pn_reactor_mark(self._impl) def _get_handler(self): return WrappedHandler.wrap(pn_reactor_get_handler(self._impl), self.on_error) http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/d4d22ee3/proton-c/include/proton/reactor.h -- diff --git a/proton-c/include/proton/reactor.h b/proton-c/include/proton/reactor.h index 59b2282..6f52d22 100644 ---
[GitHub] qpid-proton pull request: Run the python-tox-test under Jenkins ...
GitHub user dnwe opened a pull request: https://github.com/apache/qpid-proton/pull/44 Run the python-tox-test under Jenkins Travis You can merge this pull request into a Git repository by running: $ git pull https://github.com/dnwe/qpid-proton travis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/44.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #44 commit d2e4b0bce27a663366cd6cdfb107893b930a15fa Author: Kenneth Giusti kgiu...@apache.org Date: 2015-07-08T18:55:20Z NO-JIRA: update jenkins scripts to run python-tox-test if possible commit 17946939e4e5ab8dbc282237b3a961178176dfa3 Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-07-08T19:12:07Z NO-JIRA: update travis to support the tox suite --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: Run the python-tox-test under Jenkins ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/44 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Proton Devs using Linux: please run the python-tox-test unit tests!!
One thing that may or may not come up is that the job on the ASF Jenkins is tied to run only on the 'legacy-ubuntu' label currently, which only includes the old ubuntu3 node. All the other Ubuntu nodes are newer but the build was failing on many of them due to needing packages installed, so it isnt running on those currently. Robbie On 8 July 2015 at 18:30, Dominic Evans dominic.ev...@uk.ibm.com wrote: I do have an unpushed change that partially enables it for travis. I'll push later tonight. On 8 Jul 2015, at 18:27, Ken Giusti kgiu...@redhat.com wrote: Good point, I'll see what I can do on that front. - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Wednesday, July 8, 2015 12:21:57 PM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! On 8 July 2015 at 15:48, Ken Giusti kgiu...@redhat.com wrote: Devs, As you probably know, I've pushed changes to the proton python bindings that make proton compatible with python3. Since then, I've hit bugs in the python3 stuff that could've been caught by running the above unit test on a linux system that has python3 installed. This test currently only runs on linux, and requires both python3 and extra python tools be installed in order to run it. I suspect most devs don't have these tools installed by default. If the tools are not available - or are not current - ctest will skip running these tests. Most current linux distros - I'm running Fedora 21 btw - support installing both python2.x and python3.x in parallel. Most default to just having python 2.x installed - you usually have to install python3 manually. Once you have python3 installed, you will also need to have an up-to-date version of the 'tox' and 'virtualenv' tools installed. For example, on my F21 box: sudo yum install python-tox python-virtualenv does the trick. Note: the unit tests require version 1.7+ of python-tox. If that isn't available to you, you can use 'python-pip' to either overwrite the installed version of tox with a newer one, or install a local copy of tox in your home directory: $ sudo pip install -U tox # this overwrites or $ pip install --user -U tox # will put tox in ~/.local - you'll have to update your PATH/PYTHONPATH to look there Once all that is done, a simple 'make test' should run the python-tox-test. Doing all this is optional, and will increase the time it takes to run the unit tests, but it prevent inadvertent regressions to the python3 support. And it will greatly appreciated by yours truly! thanks all, -K It would probably help if some or all of the CI environments (ASF Jenkins, Travis CI, Appveyor) we have checking thing over were set up to do this. Robbie -- -K
[GitHub] qpid-proton pull request: -Fix 2 Code Analysis warnings and a real...
Github user dcristoloveanu closed the pull request at: https://github.com/apache/qpid-proton/pull/43 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: -Fix 2 Code Analysis warnings in iocp.c ...
GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/45 -Fix 2 Code Analysis warnings in iocp.c and a realloc leak -Fix one realloc leak and the fact that the realloc result was not checked. This rippled through codec.c as more functions needed to have error checking. Also, more fixes regarding return values being checked need to be done throughout message.c, transport.c, etc., but the amount of changes is significant, so it needs to be done in several chunks. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton FixCodeAnalysis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/45.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #45 commit 9d14e1dd3d2fa5886752ff00eece93c4827cd1bd Author: dcristoloveanu dcri...@microsoft.com Date: 2015-07-09T20:01:30Z -Fix 2 Code Analysis warnings in iocp.c -Fix one realloc leak and the fact that the realloc result was not checked. This rippled through codec.c as more functions needed to have error checking. Also, more fixes regarding return values being checked need to be done throughout message.c, transport.c, etc., but the amount of changes is significant, so it needs to be done in several chunks. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Proton Devs using Linux: please run the python-tox-test unit tests!!
Apparently ubuntu3 doesn't have 'pip' installed, so our jenkin's script can't pull down tox and run the python-tox-test. Assuming ubuntu3 is really old, it probably doesn't have python3 installed either (just a guess). So even if we had pip/tox installed, the tests would only run under python2 anyways. -K - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Thursday, July 9, 2015 9:45:10 AM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! One thing that may or may not come up is that the job on the ASF Jenkins is tied to run only on the 'legacy-ubuntu' label currently, which only includes the old ubuntu3 node. All the other Ubuntu nodes are newer but the build was failing on many of them due to needing packages installed, so it isnt running on those currently. Robbie On 8 July 2015 at 18:30, Dominic Evans dominic.ev...@uk.ibm.com wrote: I do have an unpushed change that partially enables it for travis. I'll push later tonight. On 8 Jul 2015, at 18:27, Ken Giusti kgiu...@redhat.com wrote: Good point, I'll see what I can do on that front. - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Sent: Wednesday, July 8, 2015 12:21:57 PM Subject: Re: Proton Devs using Linux: please run the python-tox-test unit tests!! On 8 July 2015 at 15:48, Ken Giusti kgiu...@redhat.com wrote: Devs, As you probably know, I've pushed changes to the proton python bindings that make proton compatible with python3. Since then, I've hit bugs in the python3 stuff that could've been caught by running the above unit test on a linux system that has python3 installed. This test currently only runs on linux, and requires both python3 and extra python tools be installed in order to run it. I suspect most devs don't have these tools installed by default. If the tools are not available - or are not current - ctest will skip running these tests. Most current linux distros - I'm running Fedora 21 btw - support installing both python2.x and python3.x in parallel. Most default to just having python 2.x installed - you usually have to install python3 manually. Once you have python3 installed, you will also need to have an up-to-date version of the 'tox' and 'virtualenv' tools installed. For example, on my F21 box: sudo yum install python-tox python-virtualenv does the trick. Note: the unit tests require version 1.7+ of python-tox. If that isn't available to you, you can use 'python-pip' to either overwrite the installed version of tox with a newer one, or install a local copy of tox in your home directory: $ sudo pip install -U tox # this overwrites or $ pip install --user -U tox # will put tox in ~/.local - you'll have to update your PATH/PYTHONPATH to look there Once all that is done, a simple 'make test' should run the python-tox-test. Doing all this is optional, and will increase the time it takes to run the unit tests, but it prevent inadvertent regressions to the python3 support. And it will greatly appreciated by yours truly! thanks all, -K It would probably help if some or all of the CI environments (ASF Jenkins, Travis CI, Appveyor) we have checking thing over were set up to do this. Robbie -- -K -- -K
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14621373#comment-14621373 ] ASF subversion and git services commented on PROTON-865: Commit 377fd55032a0e99664e774999e858bf804d4b6e4 in qpid-proton's branch refs/heads/cjansen-cpp-client from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=377fd55 ] PROTON-865: Revert error check in array code. Removed an error check in proton array encoder to ensure elements in an array have the right type. This check was added to aid debugging but causes several test failures. C++ reactor client binding -- Key: PROTON-865 URL: https://issues.apache.org/jira/browse/PROTON-865 Project: Qpid Proton Issue Type: New Feature Environment: C++ Reporter: Cliff Jansen Assignee: Cliff Jansen This JIRA tracks initial work on a C++ binding to the Proton reactor event based model with an eye to providing an API very similar to the python client. As stated on the Proton list, the broad goals are: to make it easy to write simple programs natural to build out more complicated ones very similar API to the Python client lean and performant The initial introduction with accompanying HelloWorld can be found at https://github.com/apache/qpid-proton/pull/18 Ongoing work is proceeding in my github account in branch cpp-work https://github.com/cliffjansen/qpid-proton/tree/cpp-work commit 1453f57ca3f446450ef654505548f1947cb7a0f1 adds listener support, exceptions and a logging interface. The initial implementation will provide no thread safety guarantees, but the bone structure should allow that to be added later with no API change. I still hold out hope of eventually allowing multiple threads processing separate connections concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-940) provide the session initial incoming window via Begin rather than sending a separate Flow
[ https://issues.apache.org/jira/browse/PROTON-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14621372#comment-14621372 ] ASF subversion and git services commented on PROTON-940: Commit 2b41931dbb49730ddba92c42e40113899371c2d7 in qpid-proton's branch refs/heads/cjansen-cpp-client from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2b41931 ] PROTON-940: calculate the incoming window before sending the Begin frame to ensure it is initialised, which supresses the need for a subsequent Flow as seen previously provide the session initial incoming window via Begin rather than sending a separate Flow - Key: PROTON-940 URL: https://issues.apache.org/jira/browse/PROTON-940 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8, 0.9, 0.9.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-940-calculate-the-incoming-window-before-send.patch When a session is created, a Begin frame is sent. One of the fields on the frame is the initial incoming window. Instead of populating the field, Proton-J currently sets it to 0 but then immediately discovers the window is 0 and sends a seperate Flow frame (in the same transport output sas the Begin frame) changing the window to the actual calculated value. This result is equivalent in the end and allowed by the protocol, but is not particularly obvious behaviour and is different than proton-c. The initial incoming window value should be conveyed in the Begin frame instead, removing need for the immediate Flow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
