You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ken Giusti (JIRA)" <ji...@apache.org> on 2019/05/03 20:58:00 UTC
[jira] [Resolved] (DISPATCH-1330) Q2 stall due to incorrect msg
buffer ref count decrement on link detach
[ https://issues.apache.org/jira/browse/DISPATCH-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ken Giusti resolved DISPATCH-1330.
----------------------------------
Resolution: Fixed
> Q2 stall due to incorrect msg buffer ref count decrement on link detach
> -----------------------------------------------------------------------
>
> Key: DISPATCH-1330
> URL: https://issues.apache.org/jira/browse/DISPATCH-1330
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
> Affects Versions: 1.7.0, 1.6.0
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Priority: Major
> Fix For: 1.8.0
>
>
> Very rarely the test_40_drop_rx_client_multicast_large_message (system_tests_edge_router.RouterTest) will hang.
> On examination it turns out that very large mcast message is stuck in the Q2 holdoff=true state.
> The message buffers are supposed to be discarded as the senders advance. However in this case all senders are at the end of the buffer list having sent all data.
> The refcounts of the preceding buffers are all stuck at 1 - this is incorrect as the refcount should've hit 0 and the buffers should be freed.
> It turns out that a sender was detached *after* the buffer refcounts were incremented for it, but *before* the msg's cursor was set. This prevented the cleanup code from walking the list of unsent buffers decrement the refcounts on detach.
> Kudos to Fernando Giorgetti for finding this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org