[
https://issues.apache.org/jira/browse/PROTON-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812391#comment-16812391
]
ASF subversion and git services commented on PROTON-2027:
---------------------------------------------------------
Commit d4a6971af2c64b7d9e8aa31a1e807690d4f26a7e in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=d4a6971 ]
PROTON-2027: Make disconnect work like other wake mechanisms (eg.
pn_connection_wake) and check for closing status. Count disconnects correctly
for competing closes.
> 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
