[jira] [Commented] (PROTON-334) SASL Plug-in for Proton
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335443#comment-14335443 ] Andrew Stitcher commented on PROTON-334: Link to documentation on this work: https://cwiki.apache.org/confluence/x/B5cWAw SASL Plug-in for Proton --- Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Proposed SASL changes (API and functional)
As many of you know I've been working on implementing a SASL AMQP protocol layer that does more than PLAIN and ANONYMOUS for proton-c. I'm currently in at a point where the work is reasonably functional (with some gaps) I've put together a fairly comprehensive account of this work on the Apache wiki: https://cwiki.apache.org/confluence/x/B5cWAw If you are at all interested please go and look at the proposal and comment on it there. You can see my actual code changes in my github proton repo: https://github.com/astitcher/qpid-proton/commits/sasl-work [This is my working branch, so not all the changes make a lot of sense, just pay attention to the tip of the branch] In a short while when people have had enough time to absorb the proposal and comment I will post a code review of the actual code changes. As there are substantial API changes I'd like to get this in for 0.9 because we were intending to stabilise the API at this point. Thanks. Andrew
[jira] [Commented] (PROTON-825) BlockingReceiver.receive() uses 100% CPU.
[ https://issues.apache.org/jira/browse/PROTON-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334911#comment-14334911 ] ASF subversion and git services commented on PROTON-825: Commit 2f854430c1490aaaf7e5a9545921a42b8454cf68 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2f85443 ] PROTON-825: SyncRequestResponse should yield in on_message. This is the replacement fix for the reverted commit: 1455f32 PROTON-825: Reactor should yield before quiescing. Instead of changing the reactor process() logic, we call pn_reactor_yield from on_message in the SyncRequestResponse handler. BlockingReceiver.receive() uses 100% CPU. - Key: PROTON-825 URL: https://issues.apache.org/jira/browse/PROTON-825 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Environment: F20 Built from master 2/19. Reporter: Jeff Ortel Assignee: Alan Conway Fix For: 0.9 Calling BlockingReceiver.receive(timeout=10) blocks the caller for 10 seconds but uses 100% CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-825) BlockingReceiver.receive() uses 100% CPU.
[ https://issues.apache.org/jira/browse/PROTON-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334910#comment-14334910 ] ASF subversion and git services commented on PROTON-825: Commit 14bdfbe045f036c99cb5d9fb3a6117fc1b1dd863 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=14bdfbe ] Revert PROTON-825: Reactor should yield before quiescing. This reverts commit 1455f32575921ac8ed90cce539273233058f2b70. There is no need to put this logic in the reactor process loop, instead an application that needs the reactor to yield the thread can call pn_reactor_yield. New fix for SyncRequestResponse will follow. BlockingReceiver.receive() uses 100% CPU. - Key: PROTON-825 URL: https://issues.apache.org/jira/browse/PROTON-825 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Environment: F20 Built from master 2/19. Reporter: Jeff Ortel Assignee: Alan Conway Fix For: 0.9 Calling BlockingReceiver.receive(timeout=10) blocks the caller for 10 seconds but uses 100% CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-825) BlockingReceiver.receive() uses 100% CPU.
[ https://issues.apache.org/jira/browse/PROTON-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334912#comment-14334912 ] ASF subversion and git services commented on PROTON-825: Commit 2f854430c1490aaaf7e5a9545921a42b8454cf68 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2f85443 ] PROTON-825: SyncRequestResponse should yield in on_message. This is the replacement fix for the reverted commit: 1455f32 PROTON-825: Reactor should yield before quiescing. Instead of changing the reactor process() logic, we call pn_reactor_yield from on_message in the SyncRequestResponse handler. BlockingReceiver.receive() uses 100% CPU. - Key: PROTON-825 URL: https://issues.apache.org/jira/browse/PROTON-825 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Environment: F20 Built from master 2/19. Reporter: Jeff Ortel Assignee: Alan Conway Fix For: 0.9 Calling BlockingReceiver.receive(timeout=10) blocks the caller for 10 seconds but uses 100% CPU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-818) Reactor C soak tests
[ https://issues.apache.org/jira/browse/PROTON-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335293#comment-14335293 ] Justin Ross commented on PROTON-818: https://reviews.apache.org/r/30898/ Reactor C soak tests Key: PROTON-818 URL: https://issues.apache.org/jira/browse/PROTON-818 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.9 Reporter: Cliff Jansen Assignee: Cliff Jansen Provide analogous programs to msgr-send and msgr-recv that can extend the soak tests to reactor sample programs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-826) recent checkin causes frequent double-free or corruption crash
michael goulish created PROTON-826:
--
Summary: recent checkin causes frequent double-free or corruption
crash
Key: PROTON-826
URL: https://issues.apache.org/jira/browse/PROTON-826
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: michael goulish
Priority: Blocker
In my dispatch testing I am seeing frequent crashes in proton library that
began with proton checkin 01cb00c on 2015-02-15 report read and write
errors through the transport
The output at crash-time says this:
---
*** Error in `/home/mick/dispatch/install/sbin/qdrouterd': double free or
corruption (fasttop): 0x020ee880 ***
=== Backtrace: =
/lib64/libc.so.6[0x3e3d875a4f]
/lib64/libc.so.6[0x3e3d87cd78]
/lib64/libqpid-proton.so.2(pn_error_clear+0x18)[0x7f4f4f4e1f18]
/lib64/libqpid-proton.so.2(pn_error_set+0x11)[0x7f4f4f4e1f41]
/lib64/libqpid-proton.so.2(pn_error_vformat+0x3e)[0x7f4f4f4e1f9e]
/lib64/libqpid-proton.so.2(pn_error_format+0x82)[0x7f4f4f4e2032]
/lib64/libqpid-proton.so.2(pn_i_error_from_errno+0x67)[0x7f4f4f4fd737]
/lib64/libqpid-proton.so.2(pn_recv+0x5a)[0x7f4f4f4fd16a]
/home/mick/dispatch/install/lib64/libqpid-dispatch.so.0(qdpn_connector_process+0xd7)[0x7f4f4f759430]
The backtrace from the core file looks like this:
#0 0x003e3d835877 in raise () from /lib64/libc.so.6
#1 0x003e3d836f68 in abort () from /lib64/libc.so.6
#2 0x003e3d875a54 in __libc_message () from /lib64/libc.so.6
#3 0x003e3d87cd78 in _int_free () from /lib64/libc.so.6
#4 0x7fbf8a59b2e8 in pn_error_clear (error=error@entry=0x1501140)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:56
#5 0x7fbf8a59b311 in pn_error_set (error=error@entry=0x1501140,
code=code@entry=-2,
text=text@entry=0x7fbf801a69c0 recv: Resource temporarily unavailable)
at /home/mick/rh-qpid-proton/proton-c/src/error.c:65
#6 0x7fbf8a59b36e in pn_error_vformat (error=0x1501140, code=-2,
fmt=optimized out,
ap=ap@entry=0x7fbf801a6de8) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:81
#7 0x7fbf8a59b402 in pn_error_format (error=error@entry=0x1501140,
code=optimized out,
fmt=fmt@entry=0x7fbf8a5bb21e %s: %s) at
/home/mick/rh-qpid-proton/proton-c/src/error.c:89
#8 0x7fbf8a5b6797 in pn_i_error_from_errno (error=0x1501140,
msg=msg@entry=0x7fbf8a5bbe1a recv)
at /home/mick/rh-qpid-proton/proton-c/src/platform.c:119
#9 0x7fbf8a5b61ca in pn_recv (io=0x14e77b0, socket=optimized out,
buf=optimized out,
size=optimized out) at
/home/mick/rh-qpid-proton/proton-c/src/posix/io.c:271
#10 0x7fbf8a812430 in qdpn_connector_process (c=0x7fbf7801c7f0)
-
And I can prevent the crash from happening, apparently forever, by commenting
out this line:
free(error-text);
in the function pn_error_clear
in the file proton-c/src/error.c
The error text that is being freed which causes the crash looks like this:
$2 = {text = 0x7f66e8104e30 recv: Resource temporarily unavailable, root =
0x0, code = -2}
My dispatch test creates a router network and then repeatedly kills and
restarts a randomly-selected router. After this proton checkin it almost never
gets through 5 iterations without this crash. After I commented out that line,
it got through more than 500 iterations before I stopped it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
