[jira] [Resolved] (PROTON-2081) Hang in Windows proactor during connect
[ https://issues.apache.org/jira/browse/PROTON-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-2081. -- Resolution: Fixed Fix Version/s: proton-c-0.29.0 > Hang in Windows proactor during connect > --- > > Key: PROTON-2081 > URL: https://issues.apache.org/jira/browse/PROTON-2081 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.28.0 > Environment: Windows > Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.29.0 > > > The bug is a simple race between threads. The necessary context for the > connect completion routine should be set before the async connect is > initiated, not after. If the completion routine runs ahead of the context > setup, the successful connect data is mistaken for a drained completion on a > closed connection. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2081) Hang in Windows proactor during connect
Cliff Jansen created PROTON-2081: Summary: Hang in Windows proactor during connect Key: PROTON-2081 URL: https://issues.apache.org/jira/browse/PROTON-2081 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.28.0 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen The bug is a simple race between threads. The necessary context for the connect completion routine should be set before the async connect is initiated, not after. If the completion routine runs ahead of the context setup, the successful connect data is mistaken for a drained completion on a closed connection. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2036) Additional C++ threading documentation
[ https://issues.apache.org/jira/browse/PROTON-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16830729#comment-16830729 ] Cliff Jansen commented on PROTON-2036: -- Also add a clearer description that proton::work_queue::xyz() is thread safe, but that obtaining it must be done on the callback thread because proton_obj::work_queue() is not. It might also help to use a different name for the accessor to the application's copy of the work queue to something other than work_queue() in the multithreaded example programs. > Additional C++ threading documentation > -- > > Key: PROTON-2036 > URL: https://issues.apache.org/jira/browse/PROTON-2036 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.27.1 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > The C++ documentation about the threading model should explicitly call out > some the the common pitfalls encountered using Proton objects. > While the obvious method calls are easy to spot and address, the implicit > method calls to destructors or copy constructors are much easier to miss. > Some places where this happens are when embedding proton objects in other > classes, passing arguments to method calls or lambda captures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2036) Additional C++ threading documentation
Cliff Jansen created PROTON-2036: Summary: Additional C++ threading documentation Key: PROTON-2036 URL: https://issues.apache.org/jira/browse/PROTON-2036 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Affects Versions: proton-c-0.27.1 Reporter: Cliff Jansen Assignee: Cliff Jansen The C++ documentation about the threading model should explicitly call out some the the common pitfalls encountered using Proton objects. While the obvious method calls are easy to spot and address, the implicit method calls to destructors or copy constructors are much easier to miss. Some places where this happens are when embedding proton objects in other classes, passing arguments to method calls or lambda captures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2027) Proactor connection wake after memory freed when using pn_proactor_disconnect().
[ https://issues.apache.org/jira/browse/PROTON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-2027. -- Resolution: Fixed Test also works now on CentOS 6 > Proactor connection wake after memory freed when using > pn_proactor_disconnect(). > > > Key: PROTON-2027 > URL: https://issues.apache.org/jira/browse/PROTON-2027 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.28.0 > > > The normal cleanup procedure for epoll and win_iocp proactors waits for all > async activity to complete before freeing memory. > pn_proactor_disconnect can't actually force a close so it launches a separate > async activity piggy-backed on the internal wake mechanism of any connections > to be closed. > If the disconnect is happening at the same time as a separate thread doing a > normal close, a new wake can result after concluding there are none left. > The solution is to mark the connection as "already awake" before entering the > cleanup code so new wakes are no-ops. The libuv proactor doesn't need this > as the disconnect function is managed within libuv and never competes with > the normal close operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-2027) Proactor connection wake after memory freed when using pn_proactor_disconnect().
[ https://issues.apache.org/jira/browse/PROTON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reopened PROTON-2027: -- Use make_work for more platform coverage. > Proactor connection wake after memory freed when using > pn_proactor_disconnect(). > > > Key: PROTON-2027 > URL: https://issues.apache.org/jira/browse/PROTON-2027 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.28.0 > > > The normal cleanup procedure for epoll and win_iocp proactors waits for all > async activity to complete before freeing memory. > pn_proactor_disconnect can't actually force a close so it launches a separate > async activity piggy-backed on the internal wake mechanism of any connections > to be closed. > If the disconnect is happening at the same time as a separate thread doing a > normal close, a new wake can result after concluding there are none left. > The solution is to mark the connection as "already awake" before entering the > cleanup code so new wakes are no-ops. The libuv proactor doesn't need this > as the disconnect function is managed within libuv and never competes with > the normal close operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2027) Proactor connection wake after memory freed when using pn_proactor_disconnect().
[ https://issues.apache.org/jira/browse/PROTON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-2027. -- Resolution: Fixed Fix Version/s: proton-c-0.28.0 > Proactor connection wake after memory freed when using > pn_proactor_disconnect(). > > > Key: PROTON-2027 > URL: https://issues.apache.org/jira/browse/PROTON-2027 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.28.0 > > > The normal cleanup procedure for epoll and win_iocp proactors waits for all > async activity to complete before freeing memory. > pn_proactor_disconnect can't actually force a close so it launches a separate > async activity piggy-backed on the internal wake mechanism of any connections > to be closed. > If the disconnect is happening at the same time as a separate thread doing a > normal close, a new wake can result after concluding there are none left. > The solution is to mark the connection as "already awake" before entering the > cleanup code so new wakes are no-ops. The libuv proactor doesn't need this > as the disconnect function is managed within libuv and never competes with > the normal close operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2027) Proactor connection wake after memory freed when using pn_proactor_disconnect().
[ https://issues.apache.org/jira/browse/PROTON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-2027: - Affects Version/s: (was: proton-j-0.32.0) proton-c-0.27.0 > Proactor connection wake after memory freed when using > pn_proactor_disconnect(). > > > Key: PROTON-2027 > URL: https://issues.apache.org/jira/browse/PROTON-2027 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > The normal cleanup procedure for epoll and win_iocp proactors waits for all > async activity to complete before freeing memory. > pn_proactor_disconnect can't actually force a close so it launches a separate > async activity piggy-backed on the internal wake mechanism of any connections > to be closed. > If the disconnect is happening at the same time as a separate thread doing a > normal close, a new wake can result after concluding there are none left. > The solution is to mark the connection as "already awake" before entering the > cleanup code so new wakes are no-ops. The libuv proactor doesn't need this > as the disconnect function is managed within libuv and never competes with > the normal close operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2027) Proactor connection wake after memory freed when using pn_proactor_disconnect().
Cliff Jansen created PROTON-2027: Summary: Proactor connection wake after memory freed when using pn_proactor_disconnect(). Key: PROTON-2027 URL: https://issues.apache.org/jira/browse/PROTON-2027 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-j-0.32.0 Reporter: Cliff Jansen Assignee: Cliff Jansen The normal cleanup procedure for epoll and win_iocp proactors waits for all async activity to complete before freeing memory. pn_proactor_disconnect can't actually force a close so it launches a separate async activity piggy-backed on the internal wake mechanism of any connections to be closed. If the disconnect is happening at the same time as a separate thread doing a normal close, a new wake can result after concluding there are none left. The solution is to mark the connection as "already awake" before entering the cleanup code so new wakes are no-ops. The libuv proactor doesn't need this as the disconnect function is managed within libuv and never competes with the normal close operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800883#comment-16800883 ] Cliff Jansen commented on DISPATCH-1274: The connector timer is sometimes zero and sometimes non-zero. Perhaps its use is infrequent enough that it doesn't need to have special code to prevent collisions between a regular and immediate timers, and can just use the former. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1295) reduce cpu and locking in timer/immediate code.
Cliff Jansen created DISPATCH-1295: -- Summary: reduce cpu and locking in timer/immediate code. Key: DISPATCH-1295 URL: https://issues.apache.org/jira/browse/DISPATCH-1295 Project: Qpid Dispatch Issue Type: Improvement Components: Container Affects Versions: 1.6.0 Reporter: Cliff Jansen Follow on to DISPATCH-1274. Locks held for longer time than necessary (through system calls). Spurious calls to timer_visit() that should be restricted to immediate_visit(). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8278) Build failure on Windows
Cliff Jansen created QPID-8278: -- Summary: Build failure on Windows Key: QPID-8278 URL: https://issues.apache.org/jira/browse/QPID-8278 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.38.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Missing extern for Windows in Queue.h causes build failuers. Introduced with QPID-8209 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1990) drain gets stuck on
[ https://issues.apache.org/jira/browse/PROTON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reopened PROTON-1990: -- Naughty and unnecessary C++11 usage. > drain gets stuck on > --- > > Key: PROTON-1990 > URL: https://issues.apache.org/jira/browse/PROTON-1990 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Gordon Sim > Assignee: Cliff Jansen >Priority: Major > Labels: patch > Fix For: proton-c-0.27.0 > > Attachments: drain.patch > > > See [http://qpid.2158936.n2.nabble.com/Drain-issue-in-proton-C-td7681843.html] > > When draining a receiver link in the proton c++ api, if there are > insuffficient messages on the source, the draining mode gets stuck on so that > subsequent granting of credit causes the credit to be immediately drained. > This appears to be due to the flag not being set on the pn_link_t instance. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1999) [c] Crash in pn_connection_finalize
[
https://issues.apache.org/jira/browse/PROTON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759665#comment-16759665
]
Cliff Jansen commented on PROTON-1999:
--
Jeremy: I did not fully understand the scenario you have laid out but I think
you have answered your own question:
"Both threads are manipulating reference counts of objects, and I suspect a
race condition. "
90% of the threading information in cpp/docs/mt.md is aimed at preventing this
cross thread reference counting that never ends well.
What trips most people up is that connection::~connection() is just as thread
unsafe as proton::open_session(). Usually this happens because some shared
object passed between threads has an embedded proton::connection object. Calls
to connection::foo() are carefully scrutinized for obeying "the rules", but the
destructor is often left to the whims of a "shared pointer last reference",
which only gets the last dereference in the correct thread 50% of the time.
But it can also happen if a user object with an embedded Proton object is
copied in the wrong thread, or the Proton object is passed by value (copy!)
instead of by reference to a method in the wrong thread.
In your specific case, I wonder if activities (destructors?) that are happening
in a non-container thread need to be passed to a relevant work_queue instead,
before the container::stop() is invoked. That's mostly a guess at this point
and may be at best a "treat the symptom" suggestion as opposed to good design
advice.
> [c] Crash in pn_connection_finalize
> ---
>
> Key: PROTON-1999
> URL: https://issues.apache.org/jira/browse/PROTON-1999
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.26.0
> Environment: Linux 64-bits (Ubuntu 16.04 and Oracle Linux 7.4)
>Reporter: Olivier Delbeke
>Assignee: Cliff Jansen
>Priority: Major
> Attachments: call_stack.txt, example2.cpp, log.txt, main.cpp,
> run_qpid-broker.sh
>
>
> Here is my situation : I have several proton::containers (~20).
> Each one has its own proton::messaging_handler, and handles one
> proton::connection to a local qpid-broker (everything runs on the same Linux
> machine).
> 20 x ( one container with one handler with one connection with one link)
> Some containers/connections/handlers work in send mode ; they have one link
> that is a proton::sender.
> Some containers/connections/handlers work in receive mode ; they have one
> link that is a proton::receiver. Each time they receive an input message,
> they do some processing on it, and finally add a "sender->send()" task to the
> work queue of some sender handlers ( by calling work_queue()->add( [=] \{
> sender->send(msg); } as shown in the multi-threading examples).
> This works fine for some time (tens of thousands of messages, several minutes
> or hours), but eventually crashes, either with a SEGFAULT (when the
> qpid-proton lib is compiled in release mode) or with an assert (in debug
> mode), in qpid-proton/c/src/core/engine.c line 483,
> assert(!conn->transport->referenced) in function pn_connection_finalize().
> The proton logs (activated with export PN_TRACE_FRM=1) do not show anything
> abnormal (no loss of connection, no rejection of messages, no timeouts, ...).
> As the connection is not closed, I wonder why pn_connection_finalize() would
> be called in the first place.
> I joined the logs and the call trace.
> Happens on 0.26.0 but also reproduced with the latest master (Jan 28, 2019).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1999) [c] Crash in pn_connection_finalize
[
https://issues.apache.org/jira/browse/PROTON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759664#comment-16759664
]
Cliff Jansen commented on PROTON-1999:
--
Olivier Delbeke: the mapping mechanism between Proton-C objects and the extra
state in their C++ counterparts is not thread safe (pn_XXX_attachments()).
Perhaps that's an implementation detail that could be changed, but the current
C++ philosophy is to superimpose a minimal additional locking on top of the
Proton-C threading model. We try to piggy-back naturally on where threading is
safe or unsafe in Proton-C with the addition of (rare) extra locking: on the
work_queue.add() and methods on proton::container.
> [c] Crash in pn_connection_finalize
> ---
>
> Key: PROTON-1999
> URL: https://issues.apache.org/jira/browse/PROTON-1999
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.26.0
> Environment: Linux 64-bits (Ubuntu 16.04 and Oracle Linux 7.4)
>Reporter: Olivier Delbeke
>Assignee: Cliff Jansen
>Priority: Major
> Attachments: call_stack.txt, example2.cpp, log.txt, main.cpp,
> run_qpid-broker.sh
>
>
> Here is my situation : I have several proton::containers (~20).
> Each one has its own proton::messaging_handler, and handles one
> proton::connection to a local qpid-broker (everything runs on the same Linux
> machine).
> 20 x ( one container with one handler with one connection with one link)
> Some containers/connections/handlers work in send mode ; they have one link
> that is a proton::sender.
> Some containers/connections/handlers work in receive mode ; they have one
> link that is a proton::receiver. Each time they receive an input message,
> they do some processing on it, and finally add a "sender->send()" task to the
> work queue of some sender handlers ( by calling work_queue()->add( [=] \{
> sender->send(msg); } as shown in the multi-threading examples).
> This works fine for some time (tens of thousands of messages, several minutes
> or hours), but eventually crashes, either with a SEGFAULT (when the
> qpid-proton lib is compiled in release mode) or with an assert (in debug
> mode), in qpid-proton/c/src/core/engine.c line 483,
> assert(!conn->transport->referenced) in function pn_connection_finalize().
> The proton logs (activated with export PN_TRACE_FRM=1) do not show anything
> abnormal (no loss of connection, no rejection of messages, no timeouts, ...).
> As the connection is not closed, I wonder why pn_connection_finalize() would
> be called in the first place.
> I joined the logs and the call trace.
> Happens on 0.26.0 but also reproduced with the latest master (Jan 28, 2019).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1990) drain gets stuck on
[ https://issues.apache.org/jira/browse/PROTON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1990. -- Resolution: Fixed Added a test. Found a second instance of un-toggled drain that required the same treatment as in the provided patch. Thanks folks. > drain gets stuck on > --- > > Key: PROTON-1990 > URL: https://issues.apache.org/jira/browse/PROTON-1990 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.26.0 >Reporter: Gordon Sim > Assignee: Cliff Jansen >Priority: Major > Labels: patch > Fix For: proton-c-0.27.0 > > Attachments: drain.patch > > > See [http://qpid.2158936.n2.nabble.com/Drain-issue-in-proton-C-td7681843.html] > > When draining a receiver link in the proton c++ api, if there are > insuffficient messages on the source, the draining mode gets stuck on so that > subsequent granting of credit causes the credit to be immediately drained. > This appears to be due to the flag not being set on the pn_link_t instance. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1999) [c] Crash in pn_connection_finalize
[
https://issues.apache.org/jira/browse/PROTON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755400#comment-16755400
]
Cliff Jansen commented on PROTON-1999:
--
In example2.cpp
sender.work_queue()
is not thread safe, hence send_message() is not.
Take a look at the examples where a pointer to the work_queue is carefully
managed: NULL on init, set from within the handler callback, and your
send_message() would use:
my_work_queue_ptr_->add( the_work );
Please give that a try and report back.
> [c] Crash in pn_connection_finalize
> ---
>
> Key: PROTON-1999
> URL: https://issues.apache.org/jira/browse/PROTON-1999
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.26.0
> Environment: Linux 64-bits (Ubuntu 16.04 and Oracle Linux 7.4)
>Reporter: Olivier Delbeke
>Assignee: Cliff Jansen
>Priority: Major
> Attachments: call_stack.txt, example2.cpp, log.txt, main.cpp,
> run_qpid-broker.sh
>
>
> Here is my situation : I have several proton::containers (~20).
> Each one has its own proton::messaging_handler, and handles one
> proton::connection to a local qpid-broker (everything runs on the same Linux
> machine).
> 20 x ( one container with one handler with one connection with one link)
> Some containers/connections/handlers work in send mode ; they have one link
> that is a proton::sender.
> Some containers/connections/handlers work in receive mode ; they have one
> link that is a proton::receiver. Each time they receive an input message,
> they do some processing on it, and finally add a "sender->send()" task to the
> work queue of some sender handlers ( by calling work_queue()->add( [=] \{
> sender->send(msg); } as shown in the multi-threading examples).
> This works fine for some time (tens of thousands of messages, several minutes
> or hours), but eventually crashes, either with a SEGFAULT (when the
> qpid-proton lib is compiled in release mode) or with an assert (in debug
> mode), in qpid-proton/c/src/core/engine.c line 483,
> assert(!conn->transport->referenced) in function pn_connection_finalize().
> The proton logs (activated with export PN_TRACE_FRM=1) do not show anything
> abnormal (no loss of connection, no rejection of messages, no timeouts, ...).
> As the connection is not closed, I wonder why pn_connection_finalize() would
> be called in the first place.
> I joined the logs and the call trace.
> Happens on 0.26.0 but also reproduced with the latest master (Jan 28, 2019).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1999) [c] Crash in pn_connection_finalize
[
https://issues.apache.org/jira/browse/PROTON-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen reassigned PROTON-1999:
Assignee: Cliff Jansen
> [c] Crash in pn_connection_finalize
> ---
>
> Key: PROTON-1999
> URL: https://issues.apache.org/jira/browse/PROTON-1999
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.26.0
> Environment: Linux 64-bits (Ubuntu 16.04 and Oracle Linux 7.4)
>Reporter: Olivier Delbeke
>Assignee: Cliff Jansen
>Priority: Major
> Attachments: call_stack.txt, example2.cpp, log.txt, main.cpp,
> run_qpid-broker.sh
>
>
> Here is my situation : I have several proton::containers (~20).
> Each one has its own proton::messaging_handler, and handles one
> proton::connection to a local qpid-broker (everything runs on the same Linux
> machine).
> 20 x ( one container with one handler with one connection with one link)
> Some containers/connections/handlers work in send mode ; they have one link
> that is a proton::sender.
> Some containers/connections/handlers work in receive mode ; they have one
> link that is a proton::receiver. Each time they receive an input message,
> they do some processing on it, and finally add a "sender->send()" task to the
> work queue of some sender handlers ( by calling work_queue()->add( [=] \{
> sender->send(msg); } as shown in the multi-threading examples).
> This works fine for some time (tens of thousands of messages, several minutes
> or hours), but eventually crashes, either with a SEGFAULT (when the
> qpid-proton lib is compiled in release mode) or with an assert (in debug
> mode), in qpid-proton/c/src/core/engine.c line 483,
> assert(!conn->transport->referenced) in function pn_connection_finalize().
> The proton logs (activated with export PN_TRACE_FRM=1) do not show anything
> abnormal (no loss of connection, no rejection of messages, no timeouts, ...).
> As the connection is not closed, I wonder why pn_connection_finalize() would
> be called in the first place.
> I joined the logs and the call trace.
> Happens on 0.26.0 but also reproduced with the latest master (Jan 28, 2019).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1982) Proton C build fails on debian:stretch
[ https://issues.apache.org/jira/browse/PROTON-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1982. -- Resolution: Fixed Fix Version/s: proton-c-0.27.0 Debian:stretch build is now happy, thank-you. > Proton C build fails on debian:stretch > -- > > Key: PROTON-1982 > URL: https://issues.apache.org/jira/browse/PROTON-1982 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 >Reporter: Cliff Jansen >Priority: Major > Fix For: proton-c-0.27.0 > > > Using master, CMake fails with: > > CMake Error: CMake can not determine linker language for target: c-core-test > CMake Error: Cannot determine link language for target "c-core-test". > CMake Error: CMake can not determine linker language for target: c-extra-test > CMake Error: Cannot determine link language for target "c-extra-test". > CMake Error: CMake can not determine linker language for target: > c-proactor-test > CMake Error: Cannot determine link language for target "c-proactor-test". > > run command: > > cmake -DBUILD_GO=ON -DBUILD_CPP=OFF -DBUILD_PYTHON=OFF > -DBUILD_STATIC_LIBS=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release > > also fails with same error messages with simplfied args > > cmake -DBUILD_GO=ON -DCMAKE_BUILD_TYPE=Release .. > > This appears to be platform specific > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1982) Proton C build fails on debian:stretch
[ https://issues.apache.org/jira/browse/PROTON-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16717563#comment-16717563 ] Cliff Jansen commented on PROTON-1982: -- For me, the builds work up to f53c768 and fail after 0bdba37 - PROTON-1887: [c] Convert C tests to use Catch2 harness. 0bdba37 appears to rework CMake config files but I don't see anything that would necessitate new dependencies. https://github.com/cliffjansen/amqpsource/blob/master/Dockerfile is the Dockerfile I am using. Using that with the lines removed after the actual cmake command should be a reproducer on amd64 and the "git checkout" line altered to 0bdba37 or HEAD on master. > Proton C build fails on debian:stretch > -- > > Key: PROTON-1982 > URL: https://issues.apache.org/jira/browse/PROTON-1982 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.27.0 >Reporter: Cliff Jansen >Priority: Major > > Using master, CMake fails with: > > CMake Error: CMake can not determine linker language for target: c-core-test > CMake Error: Cannot determine link language for target "c-core-test". > CMake Error: CMake can not determine linker language for target: c-extra-test > CMake Error: Cannot determine link language for target "c-extra-test". > CMake Error: CMake can not determine linker language for target: > c-proactor-test > CMake Error: Cannot determine link language for target "c-proactor-test". > > run command: > > cmake -DBUILD_GO=ON -DBUILD_CPP=OFF -DBUILD_PYTHON=OFF > -DBUILD_STATIC_LIBS=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release > > also fails with same error messages with simplfied args > > cmake -DBUILD_GO=ON -DCMAKE_BUILD_TYPE=Release .. > > This appears to be platform specific > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1982) Proton C build fails on debian:stretch
Cliff Jansen created PROTON-1982: Summary: Proton C build fails on debian:stretch Key: PROTON-1982 URL: https://issues.apache.org/jira/browse/PROTON-1982 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.27.0 Reporter: Cliff Jansen Using master, CMake fails with: CMake Error: CMake can not determine linker language for target: c-core-test CMake Error: Cannot determine link language for target "c-core-test". CMake Error: CMake can not determine linker language for target: c-extra-test CMake Error: Cannot determine link language for target "c-extra-test". CMake Error: CMake can not determine linker language for target: c-proactor-test CMake Error: Cannot determine link language for target "c-proactor-test". run command: cmake -DBUILD_GO=ON -DBUILD_CPP=OFF -DBUILD_PYTHON=OFF -DBUILD_STATIC_LIBS=ON -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=Release also fails with same error messages with simplfied args cmake -DBUILD_GO=ON -DCMAKE_BUILD_TYPE=Release .. This appears to be platform specific -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1981) Wrong posix time for pn_proactor_now()
[ https://issues.apache.org/jira/browse/PROTON-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16715515#comment-16715515 ] Cliff Jansen commented on PROTON-1981: -- Looking at the doc for pn_proactor_now() in proactor.h, the 32 bit value returned is not intended for use in a timestamp on its own. So perhaps the fault lies exclusively in the implementation of timestamp::now(). > Wrong posix time for pn_proactor_now() > -- > > Key: PROTON-1981 > URL: https://issues.apache.org/jira/browse/PROTON-1981 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.26.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Major > > Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per > AMQP standard. > > Used by proton::timestamp::now() > > Can take you back to 1970 on Centos7. Other time travel destinations > possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1981) Wrong posix time for pn_proactor_now()
Cliff Jansen created PROTON-1981: Summary: Wrong posix time for pn_proactor_now() Key: PROTON-1981 URL: https://issues.apache.org/jira/browse/PROTON-1981 Project: Qpid Proton Issue Type: Bug Components: cpp-binding, proton-c Affects Versions: proton-c-0.26.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Uses MONOTONIC instead of REALTIME, hence not anchored to UNIX epoch as per AMQP standard. Used by proton::timestamp::now() Can take you back to 1970 on Centos7. Other time travel destinations possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8209) qpidd segfault with huge backtrace when deleting autoDel queue just being auto-deleted
[
https://issues.apache.org/jira/browse/QPID-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved QPID-8209.
Resolution: Fixed
Fix Version/s: qpid-cpp-1.37.0
> qpidd segfault with huge backtrace when deleting autoDel queue just being
> auto-deleted
> --
>
> Key: QPID-8209
> URL: https://issues.apache.org/jira/browse/QPID-8209
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Pavel Moravec
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: qpid-cpp-1.37.0
>
>
> Description of problem:
> When below two actions happen concurrently on an auto-delete queue (without
> auto-del timeout), qpidd segfaults.
> Two actions:
> - detaching (latest) consumer of the auto-del queue
> - deleting the queue in either way (i.e. via QMF or by sending proper AMQP
> performative)
> cause that:
> - segfaulting thread from the detach event has backtrace like:
> #0 0x7f9af745f40d in ScopedLock (this=0x7f9adc6c5a88, expectedVersion=1)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/sys/Mutex.h:33
> #1 qpid::broker::Queue::tryAutoDelete (this=0x7f9adc6c5a88,
> expectedVersion=1) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1348
> #2 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> #3 0x7f9af745f524 in qpid::broker::Queue::tryAutoDelete
> (this=0x7f9adc6c5a88, expectedVersion=) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1367
> #4 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> ..
> #12012 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> #12013 0x7f9af74601c6 in qpid::broker::Queue::cancel
> (this=0x7f9adc6c5a88, c=...,
> connectionId="qpid.127.0.0.1:5672-127.0.0.1:56736", userId="anonymous")
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:637
> ..
> - other thread trying to delete the queue has bt like:
> #0 0x00343ee11016 in qpid::broker::Exchange::propagateFedOp
> (this=0x260ee30, routingKey="autoDel_93", tags="", op="U", origin="",
> extra_args=0x0)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Exchange.cpp:344
> #1 0x00343ee66baf in qpid::broker::DirectExchange::unbind
> (this=0x260edd0, queue=..., routingKey="autoDel_93", args= out>)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/DirectExchange.cpp:159
> #2 0x00343eeac7c9 in qpid::broker::QueueBindings::unbind (this= optimized out>, exchanges=..., queue=...) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/QueueBindings.cpp:47
> #3 0x00343ee39b1d in qpid::broker::Queue::unbind (this= out>, exchanges=) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1208
> #4 0x00343ee39ca6 in qpid::broker::Queue::destroyed
> (this=0x7ff820308810) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1162
> #5 0x00343eeb1027 in qpid::broker::QueueRegistry::destroy
> (this=0x2606278, name="autoDel_93",
> connectionId="qpid.127.0.0.1:5672-127.0.0.1:39240", userId="anonymous")
> ..
> The segfault happens since depth of the backtrace exceeds some limit.
> Version-Release number of selected component (if applicable):
> current upstream
> 1.36
> 1.38
> How reproducible:
> randomly, but 100% in 1 hour
> Steps to Reproduce:
> compile C++ program to delete a queue via QMF - attached at the botton
> run below script with optionally updated parameters, such that numbers of
> "resource-deleted" (from qpid-receive) and "Delete failed. No such queue"
> (from delete_queue) errors are similar (i.e. the events to trigger the race
> condition happen usually at very similar time)
> queues=125
> slept=0.9922
> for i in $(seq 1 $queues); do
> while true; do
> qpid-receive -a "autoDel_${i}; \{create:always, node:{
> x-declare:{auto-delete:True}}}" --timeout=1 &
> sleep $slept
> delete_queue autoDel_${i}
> sleep 1
> done &
> sleep 0.1
&g
[jira] [Commented] (QPID-8209) qpidd segfault with huge backtrace when deleting autoDel queue just being auto-deleted
[
https://issues.apache.org/jira/browse/QPID-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16614430#comment-16614430
]
Cliff Jansen commented on QPID-8209:
The value Queue::deleted can be set arbitrarily late because the callback from
QueueRegistry to Queue::destroyed() can be. This can leave the Queue in a
semi-deleted state from the viewpoint of some threads.
The subject code has been refactored numerous times due to deadlocks from
multiple threads accessing the queue and the registry for different but
interrelated purposes.
One solution is to have a separate lock just for setting and getting the
deleted value. As a last level lock, it will be safe from deadlock.
Related "deleted" problem code is of the form:
foo(string &queueName, args1){
Queue::shared_ptr q = queueRegistry.find(queueName);
if (q && shouldDelete(q))
queueRegistry.destroy(q->name, args2);
}
The call to destroy() can occur after the found queue has already been
destroyed and replaced with a same named queue by other threads, resulting in
an unintended queue being deleted.
Changing the signature to destroy() so that it takes a queue pointer instead of
a string name can get around this problem.
> qpidd segfault with huge backtrace when deleting autoDel queue just being
> auto-deleted
> --
>
> Key: QPID-8209
> URL: https://issues.apache.org/jira/browse/QPID-8209
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Pavel Moravec
>Priority: Major
>
> Description of problem:
> When below two actions happen concurrently on an auto-delete queue (without
> auto-del timeout), qpidd segfaults.
> Two actions:
> - detaching (latest) consumer of the auto-del queue
> - deleting the queue in either way (i.e. via QMF or by sending proper AMQP
> performative)
> cause that:
> - segfaulting thread from the detach event has backtrace like:
> #0 0x7f9af745f40d in ScopedLock (this=0x7f9adc6c5a88, expectedVersion=1)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/sys/Mutex.h:33
> #1 qpid::broker::Queue::tryAutoDelete (this=0x7f9adc6c5a88,
> expectedVersion=1) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1348
> #2 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> #3 0x7f9af745f524 in qpid::broker::Queue::tryAutoDelete
> (this=0x7f9adc6c5a88, expectedVersion=) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1367
> #4 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> ..
> #12012 0x7f9af745eed4 in qpid::broker::Queue::scheduleAutoDelete
> (this=0x7f9adc6c5a88, immediate=false) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1339
> #12013 0x7f9af74601c6 in qpid::broker::Queue::cancel
> (this=0x7f9adc6c5a88, c=...,
> connectionId="qpid.127.0.0.1:5672-127.0.0.1:56736", userId="anonymous")
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:637
> ..
> - other thread trying to delete the queue has bt like:
> #0 0x00343ee11016 in qpid::broker::Exchange::propagateFedOp
> (this=0x260ee30, routingKey="autoDel_93", tags="", op="U", origin="",
> extra_args=0x0)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Exchange.cpp:344
> #1 0x00343ee66baf in qpid::broker::DirectExchange::unbind
> (this=0x260edd0, queue=..., routingKey="autoDel_93", args= out>)
> at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/DirectExchange.cpp:159
> #2 0x00343eeac7c9 in qpid::broker::QueueBindings::unbind (this= optimized out>, exchanges=..., queue=...) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/QueueBindings.cpp:47
> #3 0x00343ee39b1d in qpid::broker::Queue::unbind (this= out>, exchanges=) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1208
> #4 0x00343ee39ca6 in qpid::broker::Queue::destroyed
> (this=0x7ff820308810) at
> /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1162
> #5 0x00343eeb1027 in qpid::broker::QueueRegistry::destroy
> (this=0x2606278, name="autoDel_93",
> connectionId="qpid.127.0.0.1:5672-127.0.0.1:39240", userId="anonymous")
> ..
> The segfault happens since depth of the backtrace excee
[jira] [Resolved] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1842.
--
Resolution: Fixed
Fix Version/s: proton-c-0.25.0
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.25.0
>
> Attachments: helloworld.cpp, race.tsan, race.vg
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1833) [cpp] Crash on Windows after calling container::stop()
[
https://issues.apache.org/jira/browse/PROTON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476036#comment-16476036
]
Cliff Jansen commented on PROTON-1833:
--
While I could not reproduce, it is plausible that this was caused by
https://issues.apache.org/jira/browse/PROTON-1844 and is now magically fixed.
> [cpp] Crash on Windows after calling container::stop()
> --
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
> Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
> Labels: crash, windows
> Fix For: proton-c-0.23.0
>
>
> Just creating a proton::container, listening locally on
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and
> getting outside of the scope (object is then destroy) => the crash happen.
> Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {
> {color:#ff}DeleteTimerQueueEx(p->timer_queue,
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(&p->timer_lock);
> DeleteCriticalSection(&p->bind_lock);
> proactor_shutdown(p);
> delete p->reaper;
> WSACleanup();
> pn_collector_free(p->collector);
> free(p);
> }
>
> NOTE:
> A lot of tests failed on windows :
> 1> The following tests FAILED:
> 1> 8 - cpp-container_test (Failed)
> 1> 10 - cpp-reconnect_test (Failed)
> 1> 21 - c-proactor-tests (Failed)
> 1> 23 - c-example-tests (Failed)
> 1> 24 - cpp-example-container (Failed)
> 1> 25 - cpp-example-container-ssl (Failed)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1844) Windows proactor memory corruption on cleanup
[ https://issues.apache.org/jira/browse/PROTON-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1844. -- Resolution: Fixed > Windows proactor memory corruption on cleanup > - > > Key: PROTON-1844 > URL: https://issues.apache.org/jira/browse/PROTON-1844 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Major > Fix For: proton-c-0.23.0 > > > Same code as that affected in in epoll, so same fix required for PROTON-1773 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled
[
https://issues.apache.org/jira/browse/PROTON-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1514.
--
Resolution: Fixed
> [proton-c] When last frame of multi-frame transfer has settled=true, Proton
> still considers delivery as unsettled
> -
>
> Key: PROTON-1514
> URL: https://issues.apache.org/jira/browse/PROTON-1514
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Ganesh Murthy
>Assignee: Cliff Jansen
>Priority: Major
> Labels: framing
> Fix For: proton-c-0.23.0
>
>
> I have a situation where a receiver (proton python's simple_recv.py) is
> receiving a multi-frame transfer from a Dispatch Router. The settled flag is
> false on all the transfer frames except on the last frame which has
> settled=true as seen here -
> {noformat}
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (16351) "g here33227Long string here33228Long
> string here33229Long string here33230Long string here33231Long string
> here33232Long string here33233Long string here33234Long string here33235Long
> string here33236Long string here33237Long string here33238Long string
> here33239Long string here33240Long string here33241Long string here33242Long
> string here33243Long string here33244Long string here33245Long string
> here33246Long string here33247Long string here33248Long string here33249Long
> string here33250Long string here33251Long string here33252Long string
> here33253Long string here33254Long string here33255Long string here33256Long
> string here33257Long string here33258Long string here33259Long string
> here33260Long string here33261Long string here33262Long string here33263Long
> string here33264Long string here33265Long string here33266Long string
> here33267Long string here33268Long string here33269Long string here33270Long
> string here33271Long string here33272Long string here33273Long string
> here33274Long string here33275Lon"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (49053) "ng string here34006Long string
> here34007Long string here34008Long string here34009Long string here34010Long
> string here34011Long string here34012Long string here34013Long string
> here34014Long string here34015Long string here34016Long string here34017Long
> string here34018Long string here34019Long string here34020Long string
> here34021Long string here34022Long string here34023Long string here34024Long
> string here34025Long string here34026Long string here34027Long string
> here34028Long string here34029Long string here34030Long string here34031Long
> string here34032Long string here34033Long string here34034Long string
> here34035Long string here34036Long string here34037Long string here34038Long
> string here34039Long string here34040Long string here34041Long string
> here34042Long string here34043Long string here34044Long string here34045Long
> string here34046Long string here34047Long string here34048Long string
> here34049Long string here34050Long string here34051Long string here34052Long
> string here34053Long string here"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (98106) "1Long string here36342Long string
> here36343Long string here36344Long string here36345Long string here36346Long
> string here36347Long string here36348Long string here36349Long string
> here36350Long string here36351Long string here36352Long string here36353Long
> string here36354Long string here36355Long string here36356Long string
> here36357Long string here36358Long string here36359Long string here36360Long
> string here36361Long string here36362Long string here36363Long string
> here36364Long string here36365Long string here36366Long string here36367Long
> string here36368Long string here36369Long string here36370Long string
> here36371Long string here36372Long string here36373Long string here36374Long
> string here36375Long string here36376Long string here36377Long string
> here36378Long string here36379Long string here36380Long string here36381Long
> string
[jira] [Commented] (PROTON-1770) [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473323#comment-16473323
]
Cliff Jansen commented on PROTON-1770:
--
Just a reminder note. Epoll version consists of many commits:
0774a4c 103cdd5 0666719 b6b3dd6 233855f
> [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Labels: windows
> Fix For: proton-c-0.23.0
>
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(&p->eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1844) Windows proactor memory corruption on cleanup
Cliff Jansen created PROTON-1844: Summary: Windows proactor memory corruption on cleanup Key: PROTON-1844 URL: https://issues.apache.org/jira/browse/PROTON-1844 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.22.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.23.0 Same code as that affected in in epoll, so same fix required for PROTON-1773 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467772#comment-16467772
]
Cliff Jansen commented on PROTON-1842:
--
Thank-you for this additional info.
Yes, these look like the same types of stack traces after a dust up.
If they truly are, for me the pconnection_done thread (T2) got the R socket
event, the last event batch, begin_close and free.
The competing thread (T4) got the RW socket event, then failed in numerous ways
depending on what was in the torn down or reused freed memory.
Catastrophic stuff happens for about 1 in 1 connections for a debug build
on a middle-aged 4c/8t desktop machine.
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: helloworld.cpp, race.tsan, race.vg
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467486#comment-16467486
]
Cliff Jansen commented on PROTON-1842:
--
This test case is quite devilish. Thank-you.
The above fix is necessary but the test case exposes more problems.
The epoll callbacks for socket IO are "mushy". The epoll proactor handles this
quite well (except at tear down as this JIRA has pointed out).
The proactor regularly flips between "wake me when there is socket data to
read" and "wake me when I can read OR write". On any transition, even with
EPOLLONESHOT, it is not possible to know if one or two threads might be awoken,
and if two are, which will get the context lock first.
I am seeing the following calls to pconnection process where the first two are
sequential and the latter two obviously overlap:
event = RW .. rearm(RW) .. wake self
inbound_wake .. rearm(R)
event = R .. segfault on NULL or assert fail on closed fd
event = RW .. begin close .. cleanup .. self delete
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: helloworld.cpp
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1833) qpid-proton cpp windows : Crash
[
https://issues.apache.org/jira/browse/PROTON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16455673#comment-16455673
]
Cliff Jansen commented on PROTON-1833:
--
I built the current master on VS2008 and VS2013 without seeing the test errors
that you see (all 64 bit builds).
Can you recheck your program against master and see if the problem persists?
If it does, can you please attach a small test case with the problem and a
description of the hardware you are running on (i.e. VM or bare metal, N
logical cpus, ) in case it is timing specific and that helps me to reproduce.
I did write a small test program that opens a single listener to 0.0.0.0:5672,
calls container.stop() in the linstener_handler.on_open() callback, and forces
the container destructor immediately on return from container.run(). It ran
fine.
> qpid-proton cpp windows : Crash
> ---
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
> Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
> Fix For: proton-c-0.23.0
>
>
> Just creating a proton::container, listening locally on
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and
> getting outside of the scope (object is then destroy) => the crash happen.
> Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {
> {color:#ff}DeleteTimerQueueEx(p->timer_queue,
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(&p->timer_lock);
> DeleteCriticalSection(&p->bind_lock);
> proactor_shutdown(p);
> delete p->reaper;
> WSACleanup();
> pn_collector_free(p->collector);
> free(p);
> }
>
> NOTE:
> A lot of tests failed on windows :
> 1> The following tests FAILED:
> 1> 8 - cpp-container_test (Failed)
> 1> 10 - cpp-reconnect_test (Failed)
> 1> 21 - c-proactor-tests (Failed)
> 1> 23 - c-example-tests (Failed)
> 1> 24 - cpp-example-container (Failed)
> 1> 25 - cpp-example-container-ssl (Failed)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1800) BlockingConnection descriptor leak
[ https://issues.apache.org/jira/browse/PROTON-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425053#comment-16425053 ] Cliff Jansen commented on PROTON-1800: -- As a workaround, adding client.receiver = None in the finally clause works for me. > BlockingConnection descriptor leak > -- > > Key: PROTON-1800 > URL: https://issues.apache.org/jira/browse/PROTON-1800 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.21.0 >Reporter: Andy Smith >Priority: Major > Attachments: sync_client.py > > > Modified collectd python plugin from using persistent connection to > connection per read. Following change, detected descriptor leak. > Attached modification to sync_client.py exhibits the issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled
[
https://issues.apache.org/jira/browse/PROTON-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410314#comment-16410314
]
Cliff Jansen commented on PROTON-1514:
--
prior to reversion saw errors in qpid-dispatch , system_tests_delivery_abort
proton/proton-c/src/core/engine.c:690: pni_add_work: Assertion
`!delivery->local.settled' failed.
> [proton-c] When last frame of multi-frame transfer has settled=true, Proton
> still considers delivery as unsettled
> -
>
> Key: PROTON-1514
> URL: https://issues.apache.org/jira/browse/PROTON-1514
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Ganesh Murthy
>Assignee: Cliff Jansen
>Priority: Major
> Labels: framing
> Fix For: proton-c-0.22.0
>
>
> I have a situation where a receiver (proton python's simple_recv.py) is
> receiving a multi-frame transfer from a Dispatch Router. The settled flag is
> false on all the transfer frames except on the last frame which has
> settled=true as seen here -
> {noformat}
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (16351) "g here33227Long string here33228Long
> string here33229Long string here33230Long string here33231Long string
> here33232Long string here33233Long string here33234Long string here33235Long
> string here33236Long string here33237Long string here33238Long string
> here33239Long string here33240Long string here33241Long string here33242Long
> string here33243Long string here33244Long string here33245Long string
> here33246Long string here33247Long string here33248Long string here33249Long
> string here33250Long string here33251Long string here33252Long string
> here33253Long string here33254Long string here33255Long string here33256Long
> string here33257Long string here33258Long string here33259Long string
> here33260Long string here33261Long string here33262Long string here33263Long
> string here33264Long string here33265Long string here33266Long string
> here33267Long string here33268Long string here33269Long string here33270Long
> string here33271Long string here33272Long string here33273Long string
> here33274Long string here33275Lon"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (49053) "ng string here34006Long string
> here34007Long string here34008Long string here34009Long string here34010Long
> string here34011Long string here34012Long string here34013Long string
> here34014Long string here34015Long string here34016Long string here34017Long
> string here34018Long string here34019Long string here34020Long string
> here34021Long string here34022Long string here34023Long string here34024Long
> string here34025Long string here34026Long string here34027Long string
> here34028Long string here34029Long string here34030Long string here34031Long
> string here34032Long string here34033Long string here34034Long string
> here34035Long string here34036Long string here34037Long string here34038Long
> string here34039Long string here34040Long string here34041Long string
> here34042Long string here34043Long string here34044Long string here34045Long
> string here34046Long string here34047Long string here34048Long string
> here34049Long string here34050Long string here34051Long string here34052Long
> string here34053Long string here"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (98106) "1Long string here36342Long string
> here36343Long string here36344Long string here36345Long string here36346Long
> string here36347Long string here36348Long string here36349Long string
> here36350Long string here36351Long string here36352Long string here36353Long
> string here36354Long string here36355Long string here36356Long string
> here36357Long string here36358Long string here36359Long string here36360Long
> string here36361Long string here36362Long string here36363Long string
> here36364Long string here36365Long string here36366Long string here36367Long
> string here36368Long string here36369Long string here36370Long string
> here36371Long str
[jira] [Resolved] (PROTON-1788) Thread-safe schedule for 0.16 C++
[ https://issues.apache.org/jira/browse/PROTON-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1788. -- Resolution: Won't Fix See comment regarding further work for generic platforms. This can be re-opened if there is demand for a 0.16.1 or later branch with this capability. > Thread-safe schedule for 0.16 C++ > - > > Key: PROTON-1788 > URL: https://issues.apache.org/jira/browse/PROTON-1788 > Project: Qpid Proton > Issue Type: Wish > Components: cpp-binding >Affects Versions: 0.16.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > Attachments: p1788_0.patch > > > Thread-safe schedule for C++ is introduced in later versions of Proton using > the proactor. > This is a 0.16 based implementation suing the reactor that could be made part > of a 0.16.1 or later release if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1788) Thread-safe schedule for 0.16 C++
[ https://issues.apache.org/jira/browse/PROTON-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391674#comment-16391674 ] Cliff Jansen commented on PROTON-1788: -- p17988_0.patch is a sample implementation that works with pthread. It could be enhanced to cover most platforms by using C++11 threading primitives and/or Windows primitives as used in qpid-cpp. It is unlikely to become part of a release without further user demand and work to make it more platform agnostic. > Thread-safe schedule for 0.16 C++ > - > > Key: PROTON-1788 > URL: https://issues.apache.org/jira/browse/PROTON-1788 > Project: Qpid Proton > Issue Type: Wish > Components: cpp-binding >Affects Versions: 0.16.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Minor > Attachments: p1788_0.patch > > > Thread-safe schedule for C++ is introduced in later versions of Proton using > the proactor. > This is a 0.16 based implementation suing the reactor that could be made part > of a 0.16.1 or later release if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1788) Thread-safe schedule for 0.16 C++
[ https://issues.apache.org/jira/browse/PROTON-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1788: - Attachment: p1788_0.patch > Thread-safe schedule for 0.16 C++ > - > > Key: PROTON-1788 > URL: https://issues.apache.org/jira/browse/PROTON-1788 > Project: Qpid Proton > Issue Type: Wish > Components: cpp-binding >Affects Versions: 0.16.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen >Priority: Minor > Attachments: p1788_0.patch > > > Thread-safe schedule for C++ is introduced in later versions of Proton using > the proactor. > This is a 0.16 based implementation suing the reactor that could be made part > of a 0.16.1 or later release if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1788) Thread-safe schedule for 0.16 C++
Cliff Jansen created PROTON-1788: Summary: Thread-safe schedule for 0.16 C++ Key: PROTON-1788 URL: https://issues.apache.org/jira/browse/PROTON-1788 Project: Qpid Proton Issue Type: Wish Components: cpp-binding Affects Versions: 0.16.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Thread-safe schedule for C++ is introduced in later versions of Proton using the proactor. This is a 0.16 based implementation suing the reactor that could be made part of a 0.16.1 or later release if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1745.
--
Resolution: Fixed
Separate issue create for future test:
https://issues.apache.org/jira/browse/PROTON-1750
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1750) Create test for address info on inbound sockets
Cliff Jansen created PROTON-1750: Summary: Create test for address info on inbound sockets Key: PROTON-1750 URL: https://issues.apache.org/jira/browse/PROTON-1750 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.20.0 Reporter: Cliff Jansen PROTON-1745 fixed changed behavior required by qpid-dispatch. It is thought that all proactors currently work correctly. Create test to verify and prevent future regressions. Also review if Doc needs corresponding updating. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16329877#comment-16329877
]
Cliff Jansen commented on PROTON-1745:
--
Try the attached patch and see if that works. If so, we will need more input
as to whether the old/patched behavior should be mandatory, documented and
tested.
Looking at the code, both libuv and win_iocp work the same way as the patch.
For any proactor implementation, I believe that the addrinfo should be
available (or an error generated and never available) by the time a BOUND event
is provided on an incoming connection. So, no objection from me.
Note that this behavior is asymmetric with outgoing connections which may need
to configure some transport property early (SASL?) on BOUND before a final
address (and resulting socket) is successfully opened.
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen updated PROTON-1745:
-
Attachment: p1745_0.diff
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1744) bug in c-proactor-tests
Cliff Jansen created PROTON-1744: Summary: bug in c-proactor-tests Key: PROTON-1744 URL: https://issues.apache.org/jira/browse/PROTON-1744 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.19.0 Reporter: Cliff Jansen Tests assume strict ordering of interleaved events from 2 separate proactor instances. Valid proactor implementations may produce a different order, especially on connection tear-down. See trial epoll proactor at https://github.com/cliffjansen/qpid-proton/tree/less_writes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1702) Fix epoll proactor listener for rearming and overflow per socket
[ https://issues.apache.org/jira/browse/PROTON-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1702. -- Resolution: Fixed > Fix epoll proactor listener for rearming and overflow per socket > > > Key: PROTON-1702 > URL: https://issues.apache.org/jira/browse/PROTON-1702 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.1 > Environment: Linux epoll > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-j-0.19.0 > > > This addresses the comment > // TODO: armed logic should be per socket not per aggregate listener > which is a required step to add logic to safely shutdown a listener > (PROTON-1531). The overflow logic needs similar per socket updating. > Additional issues to address while addressing this code change: > pclosefd - fix deadlock on recursive lock for listener sockets > socket array size to 1 on failure to match realloc > check for need to wakeup listener if pn_listener_accept() not called from > or close to ACCEPT event callback (i.e. not "working"). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1531) C epoll proactor listener cleanup race
[ https://issues.apache.org/jira/browse/PROTON-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1531. -- Resolution: Fixed > C epoll proactor listener cleanup race > -- > > Key: PROTON-1531 > URL: https://issues.apache.org/jira/browse/PROTON-1531 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Cliff Jansen >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > It is possible that closing a listener while an incoming connection is about > to trigger an epoll event on the listener can result in accessing free'd > memory. > The solution is to force an event event to fire via a shutdown() call on the > socket and delay deletion until the callback completes. This strategy is > already in use by the pconnection cleanup logic, which can be used as a > template. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1702) Fix epoll proactor listener for rearming and overflow per socket
Cliff Jansen created PROTON-1702: Summary: Fix epoll proactor listener for rearming and overflow per socket Key: PROTON-1702 URL: https://issues.apache.org/jira/browse/PROTON-1702 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.18.1 Environment: Linux epoll Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-j-0.19.0 This addresses the comment // TODO: armed logic should be per socket not per aggregate listener which is a required step to add logic to safely shutdown a listener (PROTON-1531). The overflow logic needs similar per socket updating. Additional issues to address while addressing this code change: pclosefd - fix deadlock on recursive lock for listener sockets socket array size to 1 on failure to match realloc check for need to wakeup listener if pn_listener_accept() not called from or close to ACCEPT event callback (i.e. not "working"). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1691) Memory leak when creating endpoint objects with a handler
[ https://issues.apache.org/jira/browse/PROTON-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16264587#comment-16264587 ] Cliff Jansen commented on PROTON-1691: -- In theory pn_free(link->context) should result in pn_record_finalize(link->context) which does the same thing as your proposed pn_record_clear(). I think the correct fix is to hunt down who has a rogue (or circular) reference to link->context and keeping it alive. If you are pretty sure it is not your handler, attach a test program to this JIRA and I'll try chasing it down. > Memory leak when creating endpoint objects with a handler > - > > Key: PROTON-1691 > URL: https://issues.apache.org/jira/browse/PROTON-1691 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.1 > Environment: Reproduced on Windows but the code is not platform > specific. >Reporter: Xin Chen > > Using the Python binding, one can provide a handler when creating an Endpoint > object (Connection/Session/Link). This handler object is set in the record > context. In pn_###_finalize methods, the context is not cleared by calling > pn_record_clear. This results in a _cadapter object leaking in Python process > without any references. The fix is simply to call pn_record_clear before > freeing the context. For example, in pn_link_finalize (line 1121 in engine.c), > + pn_record_clear(link->context); > pn_free(link->context); > With this fix the memory does not grow anymore with repeated link > creation/closing. I only use a handler in link endpoint but I think this is > needed for connection and session as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1691) Memory leak when creating endpoint objects with a handler
[ https://issues.apache.org/jira/browse/PROTON-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned PROTON-1691: Assignee: Cliff Jansen > Memory leak when creating endpoint objects with a handler > - > > Key: PROTON-1691 > URL: https://issues.apache.org/jira/browse/PROTON-1691 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.1 > Environment: Reproduced on Windows but the code is not platform > specific. >Reporter: Xin Chen >Assignee: Cliff Jansen > > Using the Python binding, one can provide a handler when creating an Endpoint > object (Connection/Session/Link). This handler object is set in the record > context. In pn_###_finalize methods, the context is not cleared by calling > pn_record_clear. This results in a _cadapter object leaking in Python process > without any references. The fix is simply to call pn_record_clear before > freeing the context. For example, in pn_link_finalize (line 1121 in engine.c), > + pn_record_clear(link->context); > pn_free(link->context); > With this fix the memory does not grow anymore with repeated link > creation/closing. I only use a handler in link endpoint but I think this is > needed for connection and session as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1650) Missing extern "C" {} declaration in proton/netaddr.h
Cliff Jansen created PROTON-1650:
Summary: Missing extern "C" {} declaration in proton/netaddr.h
Key: PROTON-1650
URL: https://issues.apache.org/jira/browse/PROTON-1650
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-j-0.18.0
Environment: C++ consuming C proactor code
Reporter: Cliff Jansen
Priority: Minor
Fix For: proton-c-0.18.1
As per title.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition
[
https://issues.apache.org/jira/browse/PROTON-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-824.
-
Resolution: Fixed
Yes. The last checkin should have been used as the time for resolution/close.
> Windows fails testIdleTimeout with assert p.conn.remote_condition
> -
>
> Key: PROTON-824
> URL: https://issues.apache.org/jira/browse/PROTON-824
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.9
> Environment: Windows Server 2008 or 2012
> Visual studio 2010, x86
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
> Labels: test-failure, windows
>
> {noformat}
> 1: proton_tests.engine.ServerTest.testIdleTimeout .
> fail
> 1: Error during test: Traceback (most recent call last):
> 1: File "D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test",
> line 355, in run
> 1: phase()
> 1: File
> "D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py",
> line 1919 (or so), in testIdleTimeout
> 1: assert p.conn.remote_condition
> 1: AssertionError
> {noformat}
> Playing with Program explicit timeout (trying 10 instead of 3) gets the test
> to pass sometimes. It passes sometimes with 3 as well but normally fails.
> In debugging this it looks like there as no synchronization between what a
> test will show through print statements and what the proton library shows
> through PN_TRACE_FRM statements. Are there any hints to lining these up?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1641) Windows proactor hang on incoming connections
[ https://issues.apache.org/jira/browse/PROTON-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1641. -- Resolution: Fixed > Windows proactor hang on incoming connections > - > > Key: PROTON-1641 > URL: https://issues.apache.org/jira/browse/PROTON-1641 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0, proton-c-0.19.0 > Environment: Windows > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.19.0 > > > Missing lock. Critical section guard required even though system call entry > and exit separate the memory accesses by the two threads. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1641) Windows proactor hang on incoming connections
Cliff Jansen created PROTON-1641: Summary: Windows proactor hang on incoming connections Key: PROTON-1641 URL: https://issues.apache.org/jira/browse/PROTON-1641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0, proton-c-0.19.0 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.19.0 Missing lock. Critical section guard required even though system call entry and exit separate the memory accesses by the two threads. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1534) Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe
[ https://issues.apache.org/jira/browse/PROTON-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1534. -- Resolution: Fixed > Python client BlockingConnection fails cleanup on LinkDetached exception with > socket in close_wait and straggling pipe > -- > > Key: PROTON-1534 > URL: https://issues.apache.org/jira/browse/PROTON-1534 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.10, 0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0, > 0.16.0, 0.17.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > goferd tries to clean up after an interrupted receive operation, but the > LinkDetached exception is not cleared from the BlockingConnection and the > underlying C reactor fails to progress through its cleanup mechanism. > When BlockingConnection.close() is called, the code should muscle through to > full resource cleanup. The application is no longer interested in reactor > events or exceptions. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable
[
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201294#comment-16201294
]
Cliff Jansen commented on PROTON-1556:
--
The last fix is a safe band-aid.
Leaving the JIRA unresolved until more time to revisit if there was a reason
the old copy and swap code was replaced.
> [proton-cpp] ssl_client_options is not self-assignable
> --
>
> Key: PROTON-1556
> URL: https://issues.apache.org/jira/browse/PROTON-1556
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Cliff Jansen
>Priority: Critical
> Fix For: proton-c-0.19.0
>
> Attachments: report-7646dc.html
>
>
> {{ssl_client_options}} probably cannot be self-assigned. See the attached
> report from clang-analyzer, which looks very plausible.
> The problem is that assuming {{x == *this}}, the assignment operator will
> decref and then incref the same value. Assuming the reference count was {{1}}
> to start with, there will be use-after-free.
> This probably does not matter that much in real-world code, but I found some
> quotations that making self assignment work is really important in C++...
> {noformat}
> 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain&x) {
> 59if (impl_) impl_->decref();
> 60impl_ = x.impl_;
> 61server_type_ = x.server_type_;
> 62if (impl_) impl_->incref();
> 63return *this;
> 64}
> {noformat}
> I believe the static analyzer is correct, because when I do not make any
> changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors
> concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get
> {noformat}
> $ valgrind ./ssl -c
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== Memcheck, a memory error detector
> ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==4950== Command: ./ssl -c
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950==
> ==4950== Invalid read of size 4
> ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
> ==4950==by 0x4E715CC:
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&)
> (ssl_domain.cpp:62)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA:
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&)
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950== Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain()
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C:
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> ==4950==
> ==4950== Invalid read of size 4
> ==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
> ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain()
> (ssl_domain.cpp:66)
> ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
> ==4950==by 0x4032F8: main (ssl.cpp:175)
> ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA:
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&)
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950== Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsign
[jira] [Commented] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable
[
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16201283#comment-16201283
]
Cliff Jansen commented on PROTON-1556:
--
I originally thought that fostering greater thread safety was at the
heart of some of the changes to this and surrounding code. I am now
more inclined to think that a simpler explanation is that refcounting
seems error prone here, perhaps because it is special cased for
pn_ssl_doamin_t and looks confusingly like a PN_CLASS object when it
is not.
Things were probably correct back at a4a21be when a copy and swap
mechanism was in place.
A larger refactor (0601711 and e53302d) presumably found the use of
std::swap problematic resulting in an approximation of the current
code.
Since then, several eyes have had to look at this exact code
(including mine) and did not notice the outage.
> [proton-cpp] ssl_client_options is not self-assignable
> --
>
> Key: PROTON-1556
> URL: https://issues.apache.org/jira/browse/PROTON-1556
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Cliff Jansen
>Priority: Critical
> Fix For: proton-c-0.19.0
>
> Attachments: report-7646dc.html
>
>
> {{ssl_client_options}} probably cannot be self-assigned. See the attached
> report from clang-analyzer, which looks very plausible.
> The problem is that assuming {{x == *this}}, the assignment operator will
> decref and then incref the same value. Assuming the reference count was {{1}}
> to start with, there will be use-after-free.
> This probably does not matter that much in real-world code, but I found some
> quotations that making self assignment work is really important in C++...
> {noformat}
> 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain&x) {
> 59if (impl_) impl_->decref();
> 60impl_ = x.impl_;
> 61server_type_ = x.server_type_;
> 62if (impl_) impl_->incref();
> 63return *this;
> 64}
> {noformat}
> I believe the static analyzer is correct, because when I do not make any
> changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors
> concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get
> {noformat}
> $ valgrind ./ssl -c
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950== Memcheck, a memory error detector
> ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==4950== Command: ./ssl -c
> /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/
> ==4950==
> ==4950== Invalid read of size 4
> ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37)
> ==4950==by 0x4E715CC:
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&)
> (ssl_domain.cpp:62)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator delete(void*) (in
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40)
> ==4950==by 0x4E715FA:
> proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&)
> (ssl_domain.cpp:59)
> ==4950==by 0x4032F0: operator= (ssl.hpp:172)
> ==4950==by 0x4032F0: main (ssl.cpp:176)
> ==4950== Block was alloc'd at
> ==4950==at 0x4C2C22F: operator new(unsigned long) (in
> /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain()
> (ssl_domain.cpp:72)
> ==4950==by 0x4E7195C:
> proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> proton::ssl::verify_mode) (ssl_domain.cpp:120)
> ==4950==by 0x4032B9: main (ssl.cpp:175)
> ==4950==
> ==4950== Invalid read of size 4
> ==4950==at 0x4E71619: decref (ssl_domain.cpp:39)
> ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain()
> (ssl_domain.cpp:66)
> ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172)
> ==4950==by 0x4032F8: main (ssl.cpp:175)
> ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd
> ==4950==at 0x4C2D2EB: operator
[jira] [Created] (PROTON-1620) TLS / SSL thread safety with proactor
Cliff Jansen created PROTON-1620: Summary: TLS / SSL thread safety with proactor Key: PROTON-1620 URL: https://issues.apache.org/jira/browse/PROTON-1620 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Reporter: Cliff Jansen ssl_domain objects are semi-global. For example two connections simultaneously creating or releasing their own private pn_ssl_t objects may mess up the refcount of the shared pn_ssl_domain_t object leading to memory corruption or leaks. Windows schannel is further complicated by the OS internal refcounting of its security context thingies. That may get automatically solved by the above, or may require a separate JIRA to track. The same may apply to openssl. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1601) windows proactor fails ipv6 target ":::5672"
[ https://issues.apache.org/jira/browse/PROTON-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1601. -- Resolution: Fixed > windows proactor fails ipv6 target ":::5672" > > > Key: PROTON-1601 > URL: https://issues.apache.org/jira/browse/PROTON-1601 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > fails with "The format of the specified network name is invalid". > Other ipv6 specific tests are OK. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1604) Windows C++ prefers std::endl to newlines
[ https://issues.apache.org/jira/browse/PROTON-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1604. -- Resolution: Fixed > Windows C++ prefers std::endl to newlines > - > > Key: PROTON-1604 > URL: https://issues.apache.org/jira/browse/PROTON-1604 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Visual Studio > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > Using C newline escaped char sequence can result in mysteriously missing > output. > Use std::endl instead of \\n. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1601) windows proactor fails ipv6 target ":::5672"
[ https://issues.apache.org/jira/browse/PROTON-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1601. -- Resolution: Fixed > windows proactor fails ipv6 target ":::5672" > > > Key: PROTON-1601 > URL: https://issues.apache.org/jira/browse/PROTON-1601 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > fails with "The format of the specified network name is invalid". > Other ipv6 specific tests are OK. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1604) Windows C++ prefers std::endl to newlines
Cliff Jansen created PROTON-1604: Summary: Windows C++ prefers std::endl to newlines Key: PROTON-1604 URL: https://issues.apache.org/jira/browse/PROTON-1604 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.18.0 Environment: Visual Studio Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 Using C newline escaped char sequence can result in mysteriously missing output. Use std::endl instead of \\n. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1603) Windows C++ container does not compile multithreaded
Cliff Jansen created PROTON-1603: Summary: Windows C++ container does not compile multithreaded Key: PROTON-1603 URL: https://issues.apache.org/jira/browse/PROTON-1603 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.18.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 For both VS2013 and VS2017 cmake proclaims: HAS_STD_THREAD - Success HAS_STD_MUTEX - Success HAS_STD_ATOMIC - Success yet proactor_container_impl.cpp does not compile PN_CPP_SUPPORTS_THREADS sections. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1601) windows proactor fails ipv6 target ":::5672"
Cliff Jansen created PROTON-1601: Summary: windows proactor fails ipv6 target ":::5672" Key: PROTON-1601 URL: https://issues.apache.org/jira/browse/PROTON-1601 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Environment: windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 fails with "The format of the specified network name is invalid". Other ipv6 specific tests are OK. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1349) C "proactor" implementation on windows
[ https://issues.apache.org/jira/browse/PROTON-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1349: - Attachment: p1349_2.patch Patch for compiling the C broker. > C "proactor" implementation on windows > -- > > Key: PROTON-1349 > URL: https://issues.apache.org/jira/browse/PROTON-1349 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: p1349_2.patch > > > Provide the Windows counterpart to the work in > https://issues.apache.org/jira/browse/PROTON-1344 > Including a thread safe inject. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1564) epoll proactor pn_proactor_release_connection reconnect bugs
Cliff Jansen created PROTON-1564: Summary: epoll proactor pn_proactor_release_connection reconnect bugs Key: PROTON-1564 URL: https://issues.apache.org/jira/browse/PROTON-1564 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Environment: Linux Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: proton-c-0.18.0 The epoll pn_proactor_release_connection function is used as part of a reconnect. Currently the lifecycle reference counting is not restored to its pre-connection state for reuse and locking is required to guard use of the binding reference. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1550) Epoll proactor performance improvement
Cliff Jansen created PROTON-1550: Summary: Epoll proactor performance improvement Key: PROTON-1550 URL: https://issues.apache.org/jira/browse/PROTON-1550 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.18.0 Environment: Linux Reporter: Cliff Jansen Fix For: proton-c-0.18.0 While stress testing and evaluating performance of the epoll proactor there have been indications that as the number of connections increase, the throughput increases more slowly than overall cpu use. Instrumenting and profiling suggest that, at least for applications like qpid-dispatch, there can be a large number of simultaneous pending pn_connection_wake() requests for thread-safe handoff of messages from one connection context to another. As the number of connections rise, the use of adaptive spin locks for this purpose is suspected to be an inefficient strategy, perhaps resulting in a lock convoy. A trial use of one or more lockless queues could yield substantial performance gain or at least better understanding of current hot spots. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1548) C++ proactor_container_impl deadlock in schedule.
Cliff Jansen created PROTON-1548: Summary: C++ proactor_container_impl deadlock in schedule. Key: PROTON-1548 URL: https://issues.apache.org/jira/browse/PROTON-1548 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.18.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: proton-c-0.18.0 Attachments: hang.cpp The proactor container can deadlock on connect(), open_sender(), etc. In the case of the test program, the lock is acquired just before run_timer_jobs() when handling PN_PROACTOR_TIMEOUT. Deadlock occurs in container::impl::connect() when the lock is attempted to be taken a second time. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1538) Epoll proactor unguarded memory access
Cliff Jansen created PROTON-1538: Summary: Epoll proactor unguarded memory access Key: PROTON-1538 URL: https://issues.apache.org/jira/browse/PROTON-1538 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-j-0.18.0 ThreadSanitizer singled out the epoll_event for network sockets to be a risk of out of order access by multiple threads. On inspection it is possible that two threads could try rearming the socket out of order, allowing the wrong events of interest to be registered. Reusing the existing connection context mutex would be costly for guarding this since the system call is frequent and relatively long compared to other acquisitions of the mutex. Adding a new mutex that guards this operation should fix things with negligible performance cost. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1534) Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe
Cliff Jansen created PROTON-1534: Summary: Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe Key: PROTON-1534 URL: https://issues.apache.org/jira/browse/PROTON-1534 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.17.0, 0.16.0, 0.15.0, 0.14.0, 0.13.0, 0.12.0, 0.11.0, 0.10, 0.9 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 goferd tries to clean up after an interrupted receive operation, but the LinkDetached exception is not cleared from the BlockingConnection and the underlying C reactor fails to progress through its cleanup mechanism. When BlockingConnection.close() is called, the code should muscle through to full resource cleanup. The application is no longer interested in reactor events or exceptions. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1496) C epoll proactor needs better timer implementation for connections
[ https://issues.apache.org/jira/browse/PROTON-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1496: - Fix Version/s: proton-c-0.19.0 > C epoll proactor needs better timer implementation for connections > -- > > Key: PROTON-1496 > URL: https://issues.apache.org/jira/browse/PROTON-1496 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: Linux environments with epoll support > Reporter: Cliff Jansen > Fix For: proton-c-0.19.0 > > > The epoll proactor allocates a timerfd per connection. This is a convenience > for the initial implementation and may surprise some applications running > into system limits on file descriptors twice as fast as expected. > The timer is used for heartbeats. It should be possible to write a > per-proactor heartbeat timer that is shared among the connections -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1531) C epoll proactor listener cleanup race
Cliff Jansen created PROTON-1531: Summary: C epoll proactor listener cleanup race Key: PROTON-1531 URL: https://issues.apache.org/jira/browse/PROTON-1531 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 It is possible that closing a listener while an incoming connection is about to trigger an epoll event on the listener can result in accessing free'd memory. The solution is to force an event event to fire via a shutdown() call on the socket and delay deletion until the callback completes. This strategy is already in use by the pconnection cleanup logic, which can be used as a template. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1394. -- Resolution: Fixed > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet > Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch, pn1394_2.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1394) Creating a Container leaks two file descriptors
[
https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100519#comment-16100519
]
Cliff Jansen edited comment on PROTON-1394 at 7/25/17 6:37 PM:
---
Fix for goferd segfault. incremental diff:
{code:none}
diff --git a/proton-c/bindings/python/proton/utils.py
b/proton-c/bindings/python/proton/utils.py
index 5256dbb..d0679ae 100644
--- a/proton-c/bindings/python/proton/utils.py
+++ b/proton-c/bindings/python/proton/utils.py
@@ -137,10 +137,10 @@ class BlockingReceiver(BlockingLink):
def __del__(self):
self.fetcher = None
# The next line causes a core dump if the Proton-C reactor finalizes
-# first. The self.container reference prevents reactor finalization
-# until after it is set to None.
-self.link.handler = None
-self.container = None
+# first. The self.container reference prevents out of order reactor
+# finalization. It may not be set if exception in BlockingLink.__init__
+if hasattr(self, "container"):
+self.link.handler = None # implicit call to reactor
def receive(self, timeout=False):
if not self.fetcher:
{code}
was (Author: cliffjansen):
Fix for goferd segfault. incremental diff:
{code:diff}
diff --git a/proton-c/bindings/python/proton/utils.py
b/proton-c/bindings/python/proton/utils.py
index 5256dbb..d0679ae 100644
--- a/proton-c/bindings/python/proton/utils.py
+++ b/proton-c/bindings/python/proton/utils.py
@@ -137,10 +137,10 @@ class BlockingReceiver(BlockingLink):
def __del__(self):
self.fetcher = None
# The next line causes a core dump if the Proton-C reactor finalizes
-# first. The self.container reference prevents reactor finalization
-# until after it is set to None.
-self.link.handler = None
-self.container = None
+# first. The self.container reference prevents out of order reactor
+# finalization. It may not be set if exception in BlockingLink.__init__
+if hasattr(self, "container"):
+self.link.handler = None # implicit call to reactor
def receive(self, timeout=False):
if not self.fetcher:
{code}
> Creating a Container leaks two file descriptors
> ---
>
> Key: PROTON-1394
> URL: https://issues.apache.org/jira/browse/PROTON-1394
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.16.0
> Reporter: Mike Bonnet
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
> Attachments: fix_container_leak.patch, leakyprotonpipes.py,
> new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch, pn1394_2.patch
>
>
> Creating a Container (Reactor) creates a pipe (two file descriptors). This
> pipe is never freed, even after the Container is stopped and goes out of
> scope. An application that creates many short-lived Containers will quickly
> exhaust file descriptors and Container creation will start failing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1394) Creating a Container leaks two file descriptors
[
https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100519#comment-16100519
]
Cliff Jansen edited comment on PROTON-1394 at 7/25/17 6:36 PM:
---
Fix for goferd segfault. incremental diff:
{code:diff}
diff --git a/proton-c/bindings/python/proton/utils.py
b/proton-c/bindings/python/proton/utils.py
index 5256dbb..d0679ae 100644
--- a/proton-c/bindings/python/proton/utils.py
+++ b/proton-c/bindings/python/proton/utils.py
@@ -137,10 +137,10 @@ class BlockingReceiver(BlockingLink):
def __del__(self):
self.fetcher = None
# The next line causes a core dump if the Proton-C reactor finalizes
-# first. The self.container reference prevents reactor finalization
-# until after it is set to None.
-self.link.handler = None
-self.container = None
+# first. The self.container reference prevents out of order reactor
+# finalization. It may not be set if exception in BlockingLink.__init__
+if hasattr(self, "container"):
+self.link.handler = None # implicit call to reactor
def receive(self, timeout=False):
if not self.fetcher:
{code}
was (Author: cliffjansen):
Fix for goferd segfault. incremental diff:
diff --git a/proton-c/bindings/python/proton/utils.py
b/proton-c/bindings/python/proton/utils.py
index 5256dbb..d0679ae 100644
--- a/proton-c/bindings/python/proton/utils.py
+++ b/proton-c/bindings/python/proton/utils.py
@@ -137,10 +137,10 @@ class BlockingReceiver(BlockingLink):
def __del__(self):
self.fetcher = None
# The next line causes a core dump if the Proton-C reactor finalizes
-# first. The self.container reference prevents reactor finalization
-# until after it is set to None.
-self.link.handler = None
-self.container = None
+# first. The self.container reference prevents out of order reactor
+# finalization. It may not be set if exception in
BlockingLink.__init__
+if hasattr(self, "container"):
+self.link.handler = None # implicit call to reactor
def receive(self, timeout=False):
if not self.fetcher:
> Creating a Container leaks two file descriptors
> ---
>
> Key: PROTON-1394
> URL: https://issues.apache.org/jira/browse/PROTON-1394
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.16.0
> Reporter: Mike Bonnet
>Assignee: Cliff Jansen
> Fix For: proton-c-0.18.0
>
> Attachments: fix_container_leak.patch, leakyprotonpipes.py,
> new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch, pn1394_2.patch
>
>
> Creating a Container (Reactor) creates a pipe (two file descriptors). This
> pipe is never freed, even after the Container is stopped and goes out of
> scope. An application that creates many short-lived Containers will quickly
> exhaust file descriptors and Container creation will start failing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1394: - Attachment: pn1394_2.patch Fix for goferd segfault. incremental diff: diff --git a/proton-c/bindings/python/proton/utils.py b/proton-c/bindings/python/proton/utils.py index 5256dbb..d0679ae 100644 --- a/proton-c/bindings/python/proton/utils.py +++ b/proton-c/bindings/python/proton/utils.py @@ -137,10 +137,10 @@ class BlockingReceiver(BlockingLink): def __del__(self): self.fetcher = None # The next line causes a core dump if the Proton-C reactor finalizes -# first. The self.container reference prevents reactor finalization -# until after it is set to None. -self.link.handler = None -self.container = None +# first. The self.container reference prevents out of order reactor +# finalization. It may not be set if exception in BlockingLink.__init__ +if hasattr(self, "container"): +self.link.handler = None # implicit call to reactor def receive(self, timeout=False): if not self.fetcher: > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch, pn1394_2.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reopened PROTON-1394: -- goferd segfault in BlockingReceiver.__del__ Because the underlying C objects are no longer leaking, old bugs which did not track lifecycle correctly may now suddenly become visible. > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet > Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1460) C "proactor" epoll implementation
[ https://issues.apache.org/jira/browse/PROTON-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1460. -- Resolution: Fixed > C "proactor" epoll implementation > - > > Key: PROTON-1460 > URL: https://issues.apache.org/jira/browse/PROTON-1460 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: Linux systems with epoll >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > Provide a proactor implementation based on epoll and other performant > capabilities (like eventfd) on Linux systems. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1520) C epoll proactor delayed socket writes
[ https://issues.apache.org/jira/browse/PROTON-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1520. -- Resolution: Fixed > C epoll proactor delayed socket writes > -- > > Key: PROTON-1520 > URL: https://issues.apache.org/jira/browse/PROTON-1520 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: epoll (Linux) > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > The epoll proactor currently processes socket output immediately after > processing socket input, and following that processes events (which can > generate more output, including protocol handshakes). This has the > unfortunate effect of requiring an additional system call and thread context > switch to handle this resulting output. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1520) C epoll proactor delayed socket writes
Cliff Jansen created PROTON-1520: Summary: C epoll proactor delayed socket writes Key: PROTON-1520 URL: https://issues.apache.org/jira/browse/PROTON-1520 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.18.0 Environment: epoll (Linux) Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.18.0 The epoll proactor currently processes socket output immediately after processing socket input, and following that processes events (which can generate more output, including protocol handshakes). This has the unfortunate effect of requiring an additional system call and thread context switch to handle this resulting output. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1394: - Attachment: pn1394_1.patch Fix to the previous patch. Found as I was trying to retrofit it to version 0.9. Apologies. Please see pn1394_1.patch > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch, pn1394_1.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1394) Creating a Container leaks two file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1394: - Attachment: pn1394_0.patch Here is an alternate patch that I hope will work fine with older versions of Python and can be backported to older versions of Proton. By also breaking the circular reference in the handler hierarchy, it allows the reactor to free up more than just file descriptors and results in a complete release of Python and C resources according to my testing. It should be noted that weak references to any Wrapper objects (i.e. Reactor and Container) is a dubious strategy since the Python Wrapper object's life may be very short. Hence the use of the reactor's C impl rather than a Python weakref in the ErrorDelegate. None of the handlers are Wrapper objects, so a weakref proxy is used to break that circular reference. > Creating a Container leaks two file descriptors > --- > > Key: PROTON-1394 > URL: https://issues.apache.org/jira/browse/PROTON-1394 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.16.0 >Reporter: Mike Bonnet > Attachments: fix_container_leak.patch, leakyprotonpipes.py, > new_fix_container_leak.patch, pn1394_0.patch > > > Creating a Container (Reactor) creates a pipe (two file descriptors). This > pipe is never freed, even after the Container is stopped and goes out of > scope. An application that creates many short-lived Containers will quickly > exhaust file descriptors and Container creation will start failing. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1496) C epoll proactor needs better timer implementation for connections
Cliff Jansen created PROTON-1496: Summary: C epoll proactor needs better timer implementation for connections Key: PROTON-1496 URL: https://issues.apache.org/jira/browse/PROTON-1496 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.18.0 Environment: Linux environments with epoll support Reporter: Cliff Jansen The epoll proactor allocates a timerfd per connection. This is a convenience for the initial implementation and may surprise some applications running into system limits on file descriptors twice as fast as expected. The timer is used for heartbeats. It should be possible to write a per-proactor heartbeat timer that is shared among the connections -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 59638: PROTON-1493: c-proactor make pn_proactor_interrupt async-signal-safe
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/59638/#review176417 --- Ship it! Ship It! - Cliff Jansen On May 30, 2017, 4:48 p.m., Alan Conway wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/59638/ > --- > > (Updated May 30, 2017, 4:48 p.m.) > > > Review request for qpid, Andrew Stitcher and Cliff Jansen. > > > Repository: qpid-proton-git > > > Description > --- > > pn_proactor_interrupt() will often be used from signal handlers so must be > async-signal-safe. Updated the documentation and modified the implementations > of pn_proactor_interrupt() to use only async-signal-safe calls, no locks. > > > Diffs > - > > examples/c/proactor/broker.c 7d95e7fc49e53cc5e36c62b814d39287005eb59f > proton-c/include/proton/proactor.h 861afbed22df6cb6aa9e18c15cdb7cd9ed64eede > proton-c/src/proactor/epoll.c 7490ecdcaf984ec33d9b26c6f0357c6de2e09d0f > proton-c/src/proactor/libuv.c cf7a31b5711f207541c9e832b06bb13e7051ab69 > > > Diff: https://reviews.apache.org/r/59638/diff/1/ > > > Testing > --- > > proactor self-tests on epoll and libuv proactor > > > Thanks, > > Alan Conway > >
[jira] [Commented] (DISPATCH-777) [system_tests_drain] pn_object_free: corrupted double-linked list
[
https://issues.apache.org/jira/browse/DISPATCH-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026789#comment-16026789
]
Cliff Jansen commented on DISPATCH-777:
---
Trial epoll proactor fix available:
https://issues.apache.org/jira/browse/PROTON-1491
> [system_tests_drain] pn_object_free: corrupted double-linked list
> -
>
> Key: DISPATCH-777
> URL: https://issues.apache.org/jira/browse/DISPATCH-777
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of qpid-proton and qpid-dispatch on debian
> testing:
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher
> Date: Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy
> Date: Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: DISPATCH-777_1.core.zip, DISPATCH-777_2.core.zip,
> DISPATCH-777_3.core.zip
>
>
> Execute the {{system_tests_drain}} test suite in Qpid Dispatch until the
> error appears
> {{ctest -VV -R system_tests_drain --repeat-until-fail 1000}}
> There are several very similar errors possible. It either prints
> {{*** Error in `qdrouterd': corrupted double-linked list: 0x7f45a40103c0
> ***}}
> or
> {{** Error in `qdrouterd': double free or corruption (!prev):
> 0x7f49ac013360 ***}}
> Logs and core files from three failures of the test are attached.
> {noformat}
> 15: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py"
> "-m" "unittest" "-v" "system_tests_drain"
> 15: Test timeout computed to be: 1500
> *** Error in `qdrouterd': double free or corruption (!prev):
> 0x7f49ac013360 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.615: test_drain_support_1_all_messages
> (system_tests_drain.DrainSupportTest) ... ok
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f49bc22df96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x7f49bc22e78e]
> /lib/libqpid-proton-core.so.11(pn_object_free+0x24)[0x7f49bd32a289]
> /lib/libqpid-proton-core.so.11(pn_class_decref+0xca)[0x7f49bd329d8a]
> /lib/libqpid-proton-core.so.11(pn_decref+0x22)[0x7f49bd32a2d2]
> /lib/libqpid-proton-proactor.so.11(+0x42f0)[0x7f49bd1142f0]
> /lib/libqpid-proton-proactor.so.11(+0x4395)[0x7f49bd114395]
> /lib/libqpid-proton-proactor.so.11(+0x4ac5)[0x7f49bd114ac5]
> /lib/libqpid-proton-proactor.so.11(+0x70e5)[0x7f49bd1170e5]
> /lib/libqpid-proton-proactor.so.11(pn_proactor_wait+0x1d)[0x7f49bd117185]
> /main/qpid-dispatch/build/src/libqpid-dispatch.so(+0x55e7a)[0x7f49bd5b8e7a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f49bcefa494]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f49bc29f93f]
> === Memory map:
> 55694d2c5000-55694d2c8000 r-xp fe:06 537578
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c7000-55694d4c8000 r--p 2000 fe:06 537578
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c8000-55694d4c9000 rw-p 3000 fe:06 537578
> /main/qpid-dispatch/build/router/qdrouterd
> 55694eb26000-55694eea3000 rw-p 00:00 0
> [heap]
> 7f49a400-7f49a4021000 rw-p 00:00 0
> 7f49a4021000-7f49a800 ---p 00:00 0
> 7f49a800-7f49a8021000 rw-p 00:00 0
> 7f49a8021000-7f49ac00 ---p 00:00 0
> 7f49ac00-7f49ac072000 rw-p 00:00 0
> 7f49ac072000-7f49b000 ---p 00:00 0
> 7f49b21b2000-7f49b21c8000 r-xp fe:06 394148
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b21c8000-7f49b23c7000 ---p 00016000 fe:06 394148
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c7000-7f49b23c8000 r--p 00015000 fe:06 394148
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c8000-7f49b23c9000 rw-p 00016000 fe:06 394148
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c9000-7f49b23d3000 r-xp fe:06 394180
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b23d3000-7f49b25d3000 ---p a000 fe:06 394180
[jira] [Resolved] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
[ https://issues.apache.org/jira/browse/PROTON-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1491. -- Resolution: Fixed > C epoll proactor has straggling callback after connection teardown > -- > > Key: PROTON-1491 > URL: https://issues.apache.org/jira/browse/PROTON-1491 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.18.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
[ https://issues.apache.org/jira/browse/PROTON-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026763#comment-16026763 ] Cliff Jansen commented on PROTON-1491: -- If an IO callback is in doubt, the current code rearms for (EPOLLIN|EPOLLOUT) before issuing a shutdown to force at least one call back. This second rearm can happen just after a separate IO event launches a callback leaving two simultaneous callbacks. Separate testing shows that the shutdown works as intended without the additional rearm. So removing that fixes the problem. > C epoll proactor has straggling callback after connection teardown > -- > > Key: PROTON-1491 > URL: https://issues.apache.org/jira/browse/PROTON-1491 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.18.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
[ https://issues.apache.org/jira/browse/PROTON-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1491: - Fix Version/s: 0.18.0 > C epoll proactor has straggling callback after connection teardown > -- > > Key: PROTON-1491 > URL: https://issues.apache.org/jira/browse/PROTON-1491 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.18.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
[ https://issues.apache.org/jira/browse/PROTON-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1491: - Affects Version/s: 0.18.0 > C epoll proactor has straggling callback after connection teardown > -- > > Key: PROTON-1491 > URL: https://issues.apache.org/jira/browse/PROTON-1491 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: 0.18.0 > Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
Cliff Jansen created PROTON-1491: Summary: C epoll proactor has straggling callback after connection teardown Key: PROTON-1491 URL: https://issues.apache.org/jira/browse/PROTON-1491 Project: Qpid Proton Issue Type: Bug Reporter: Cliff Jansen -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1491) C epoll proactor has straggling callback after connection teardown
[ https://issues.apache.org/jira/browse/PROTON-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned PROTON-1491: Assignee: Cliff Jansen > C epoll proactor has straggling callback after connection teardown > -- > > Key: PROTON-1491 > URL: https://issues.apache.org/jira/browse/PROTON-1491 > Project: Qpid Proton > Issue Type: Bug > Reporter: Cliff Jansen > Assignee: Cliff Jansen > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1483) proactor/epoll.c:181: ptimer_callback: Assertion
[
https://issues.apache.org/jira/browse/PROTON-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1483.
--
Resolution: Fixed
Assignee: Cliff Jansen
Fix Version/s: 0.18.0
Required changing method to track expected callbacks for expired timers.
Abandoned strict accounting for looser "in doubt" transitions.
> proactor/epoll.c:181: ptimer_callback: Assertion
>
>
> Key: PROTON-1483
> URL: https://issues.apache.org/jira/browse/PROTON-1483
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.18.0
> Environment: Fedora 25
> Master source builds of qpid-proton and qpid-dispatch
> Reporter: Chuck Rolke
>Assignee: Cliff Jansen
> Fix For: 0.18.0
>
> Attachments: A.conf, B.conf
>
>
> Start a dispatch router network of two routers. Send client traffic or not.
> Let it sit for a few minutes.
> {noformat}
> qdrouterd: /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181:
> ptimer_callback: Assertion `exp_count >= pt->skip_count' failed.
> {noformat}
> Either router A or B may fail this way. Looking at one core dump the
> internals show:
> {noformat}
> (gdb) list
> 176 ssize_t l = read(pt->timerfd, &u_exp_count, sizeof(uint64_t));
> 177 (void)l; /* Silence compiler complaints in release build */
> 178 assert(l == sizeof(uint64_t));
> 179 assert(u_exp_count < INT_MAX); // or test and log it?
> 180 int exp_count = (int) u_exp_count;
> 181 assert(exp_count >= pt->skip_count);
> 182 assert(exp_count <= pt->pending_count);
> 183 exp_count -= pt->skip_count;
> 184 pt->skip_count = 0;
> 185 pt->pending_count -= exp_count;
> (gdb) p exp_count
> $1 = 1
> (gdb) p pt->skip_count
> $2 = 2
> (gdb) bt
> #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1 0x7fc51c49d51a in __GI_abort () at abort.c:89
> #2 0x7fc51c493da7 in __assert_fail_base (fmt=,
> assertion=assertion@entry=0x7fc51d45fbc2 "exp_count >= pt->skip_count",
> file=file@entry=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c",
> line=line@entry=181,
> function=function@entry=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041>
> "ptimer_callback") at assert.c:92
> #3 0x7fc51c493e52 in __GI___assert_fail (assertion=0x7fc51d45fbc2
> "exp_count >= pt->skip_count", file=0x7fc51d45fb30
> "/home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c", line=181,
> function=0x7fc51d45fe70 <__PRETTY_FUNCTION__.7041> "ptimer_callback") at
> assert.c:101
> #4 0x7fc51d45b620 in ptimer_callback (pt=0xfd8db8) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:181
> #5 0x7fc51d45ebae in proactor_process (p=0xfd8d40, timeout=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1537
> #6 0x7fc51d45f0ae in proactor_do_epoll (p=0xfd8d40, can_block=true) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1657
> #7 0x7fc51d45f196 in pn_proactor_wait (p=0xfd8d40) at
> /home/chug/git/qpid-proton/proton-c/src/proactor/epoll.c:1680
> #8 0x7fc51d901d6a in thread_run (arg=0xfcfdd0) at
> /home/chug/git/qpid-dispatch/src/server.c:817
> #9 0x7fc51d2416ca in start_thread (arg=0x7fc50fd93700) at
> pthread_create.c:333
> #10 0x7fc51c56df7f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
> {noformat}
> The attached conf files are for the test routers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1460) C "proactor" epoll implementation
Cliff Jansen created PROTON-1460: Summary: C "proactor" epoll implementation Key: PROTON-1460 URL: https://issues.apache.org/jira/browse/PROTON-1460 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.18.0 Environment: Linux systems with epoll Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.18.0 Provide a proactor implementation based on epoll and other performant capabilities (like eventfd) on Linux systems. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1423) Python reconnect on amqp:connection:forced
[ https://issues.apache.org/jira/browse/PROTON-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-1423. -- Resolution: Fixed > Python reconnect on amqp:connection:forced > --- > > Key: PROTON-1423 > URL: https://issues.apache.org/jira/browse/PROTON-1423 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.17.0 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: 0.18.0 > > > This provides the same behaviour for the Python binding as done for the C++ > binding. See > https://issues.apache.org/jira/browse/PROTON-1416 > The AMQP standard (2.8.16) says "The client could retry at some later date". > When describing the amqp:connection:forced error. > We'll interpret this to mean that you should use the configured retry > strategy if we receive this close error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1423) Python reconnect on amqp:connection:forced
Cliff Jansen created PROTON-1423: Summary: Python reconnect on amqp:connection:forced Key: PROTON-1423 URL: https://issues.apache.org/jira/browse/PROTON-1423 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.17.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.18.0 This provides the same behaviour for the Python binding as done for the C++ binding. See https://issues.apache.org/jira/browse/PROTON-1416 The AMQP standard (2.8.16) says "The client could retry at some later date". When describing the amqp:connection:forced error. We'll interpret this to mean that you should use the configured retry strategy if we receive this close error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1312) BlockingConnection leaks Proton-C memory
[ https://issues.apache.org/jira/browse/PROTON-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15886490#comment-15886490 ] Cliff Jansen commented on PROTON-1312: -- Just one: 98e26f. 4408b8 is against my github account for the original pull request. af17de looks like a separate issue associated with PROTON-1312 by typo. > BlockingConnection leaks Proton-C memory > > > Key: PROTON-1312 > URL: https://issues.apache.org/jira/browse/PROTON-1312 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.15.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: leak, reproducer > Fix For: 0.17.0 > > Attachments: ml8.py > > > The attached program leaks the underlying connection (the C proton > object) associated with the BlockingConnection on each loop iteration > on proton 0.9 as used by Satellite. Without the receiver, it cleans > up fine. > On master, the program leaks both the reactor and the connection > associated with the BlockingConnection for each loop. The receiver > creation can be commented out and it still leaks both objects. > Other objects may leak too (presumably session), but I have not > examined further. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7679) Memory leak in DirectExchange
[ https://issues.apache.org/jira/browse/QPID-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved QPID-7679. Resolution: Resolved Fix Version/s: qpid-cpp-1.37.0 > Memory leak in DirectExchange > - > > Key: QPID-7679 > URL: https://issues.apache.org/jira/browse/QPID-7679 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Fix For: qpid-cpp-1.37.0 > > Attachments: Q7679_0.diff, unbind.cpp > > > The Exchange::unbind call for DirectExchange is coded assuming that the > binding actually exists. If the binding does not exist, this has the side > effect of creating a Bindingkey in the BindingKey map that remains in the map > until broker exit. The management count of bindings is not updated so there > is no indication there of the problem. > A well behaved 0_10 program that creates a queue, creates a direct binding, > deletes the binding and then deletes the queue results in a second implicit > unbind when the queue is deleted (usually on the QueueDeleteBody, but if an > autodelete queue, it can also happen on the MessageCancelBody ending a > subscription). > TopicExchange and FanOutExchange explicitly guard against non-existence of > the binding/queue pair on unbind(). Presumably, DirectExchange should do the > same. HeadersExchange doesn't check but doesn't "remember" the pair. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7679) Memory leak in DirectExchange
[ https://issues.apache.org/jira/browse/QPID-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-7679: --- Attachment: Q7679_0.diff Proposed patch > Memory leak in DirectExchange > - > > Key: QPID-7679 > URL: https://issues.apache.org/jira/browse/QPID-7679 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Attachments: Q7679_0.diff, unbind.cpp > > > The Exchange::unbind call for DirectExchange is coded assuming that the > binding actually exists. If the binding does not exist, this has the side > effect of creating a Bindingkey in the BindingKey map that remains in the map > until broker exit. The management count of bindings is not updated so there > is no indication there of the problem. > A well behaved 0_10 program that creates a queue, creates a direct binding, > deletes the binding and then deletes the queue results in a second implicit > unbind when the queue is deleted (usually on the QueueDeleteBody, but if an > autodelete queue, it can also happen on the MessageCancelBody ending a > subscription). > TopicExchange and FanOutExchange explicitly guard against non-existence of > the binding/queue pair on unbind(). Presumably, DirectExchange should do the > same. HeadersExchange doesn't check but doesn't "remember" the pair. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7679) Memory leak in DirectExchange
[ https://issues.apache.org/jira/browse/QPID-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876414#comment-15876414 ] Cliff Jansen commented on QPID-7679: The attached code was tested using AMQP 0-10, but I would expect the same bug to occur with AMQP 1.0. > Memory leak in DirectExchange > - > > Key: QPID-7679 > URL: https://issues.apache.org/jira/browse/QPID-7679 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Attachments: unbind.cpp > > > The Exchange::unbind call for DirectExchange is coded assuming that the > binding actually exists. If the binding does not exist, this has the side > effect of creating a Bindingkey in the BindingKey map that remains in the map > until broker exit. The management count of bindings is not updated so there > is no indication there of the problem. > A well behaved 0_10 program that creates a queue, creates a direct binding, > deletes the binding and then deletes the queue results in a second implicit > unbind when the queue is deleted (usually on the QueueDeleteBody, but if an > autodelete queue, it can also happen on the MessageCancelBody ending a > subscription). > TopicExchange and FanOutExchange explicitly guard against non-existence of > the binding/queue pair on unbind(). Presumably, DirectExchange should do the > same. HeadersExchange doesn't check but doesn't "remember" the pair. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7679) Memory leak in DirectExchange
[ https://issues.apache.org/jira/browse/QPID-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-7679: --- Attachment: unbind.cpp > Memory leak in DirectExchange > - > > Key: QPID-7679 > URL: https://issues.apache.org/jira/browse/QPID-7679 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Cliff Jansen > Assignee: Cliff Jansen > Attachments: unbind.cpp > > > The Exchange::unbind call for DirectExchange is coded assuming that the > binding actually exists. If the binding does not exist, this has the side > effect of creating a Bindingkey in the BindingKey map that remains in the map > until broker exit. The management count of bindings is not updated so there > is no indication there of the problem. > A well behaved 0_10 program that creates a queue, creates a direct binding, > deletes the binding and then deletes the queue results in a second implicit > unbind when the queue is deleted (usually on the QueueDeleteBody, but if an > autodelete queue, it can also happen on the MessageCancelBody ending a > subscription). > TopicExchange and FanOutExchange explicitly guard against non-existence of > the binding/queue pair on unbind(). Presumably, DirectExchange should do the > same. HeadersExchange doesn't check but doesn't "remember" the pair. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
