[
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: (was: 1.1.0)
1.2.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.2.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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
