You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ted Ross (JIRA)" <ji...@apache.org> on 2017/11/01 14:33:01 UTC
[jira] [Updated] (DISPATCH-863) Excessive locking between message
receive and send
[ https://issues.apache.org/jira/browse/DISPATCH-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ted Ross updated DISPATCH-863:
------------------------------
Fix Version/s: 1.1.0
> Excessive locking between message receive and send
> --------------------------------------------------
>
> Key: DISPATCH-863
> URL: https://issues.apache.org/jira/browse/DISPATCH-863
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
> Affects Versions: 1.0.0
> Reporter: Chuck Rolke
> Priority: Major
> Fix For: 1.1.0
>
>
> Support for streaming messages (commit c9262728) introduced locking between message receive and message send.
> Before streaming:
> * message_receive creates the message buffer list with no locks
> * message_send sends messages with no locks
> * When all copies of the message are sent then the last sender deletes the message content including all buffers
> With streaming:
> * message_receive takes the content lock (per buffer) as each buffer is added
> * message_send takes the content lock (per buffer) as each buffer is consumed. This happens once for each message copy.
> * message_send possibly frees the buffer if all message copies have sent that buffer.
> * When all copies of the message are sent then the last sender deletes the message content. All buffers are already freed.
> There may be a problem with all those locks:
> * *Lock ownership* If the message is being streamed to N destinations then the buffer lock will have contention from N I/O threads and the mutex ownership will surely bounce from thread to thread.
> * *Lock per buffer add/remove* If a 1 Mbyte message is streamed to N destinations then the buffer lock will be taken 2000 times by message_receive and (N * 2000) times by message_send.
> With some careful design lock usage could be greatly reduced or even eliminated.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org