[
https://issues.apache.org/jira/browse/QPID-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17348557#comment-17348557
]
Clifford Jansen commented on QPID-8527:
---------------------------------------
This can be hard to reproduce since if a connection is busy enough to use up a
timeslice, it usually will do so in the middle of much activity and new inbound
bytes will unstick qpidd.
Reproducer at
[https://bugzilla.redhat.com/show_bug.cgi?id=1945534#c14]
It helps to have background activity competing for cpu usage. The bug can
happen with a single client but more clients makes it happen sooner.
> Hang in qpidd failing to resume read activity on TLS connections.
> -----------------------------------------------------------------
>
> Key: QPID-8527
> URL: https://issues.apache.org/jira/browse/QPID-8527
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: qpid-cpp-1.39.0
> Environment: Posix only.
> Reporter: Clifford Jansen
> Assignee: Clifford Jansen
> Priority: Major
>
> The Posix AsynchIO implementation imposes a timeslice on read and write
> activity to promote resource fairness between AMQP connections.
> This mechanism relies on the poller to reschedule the suspended read activity
> which it does when it sees unread bytes on the socket. This works for normal
> TCP sockets. It can fail for TLS connections if the TLS layer (libnss) has
> buffered bytes that are "hidden" from the poller.
> The write side doesn't get starved or fail to notice when a socket is
> unblocked for writing in the TLS case.
> Posix only. The Windows implementation relies on the read and write
> completions being fairly evenly distributed between connections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
