You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <qp...@incubator.apache.org> on 2010/05/27 20:33:37 UTC

[jira] Resolved: (QPID-2631) Race in qpid::client::Bounds causes (rare) deadlock

     [ https://issues.apache.org/jira/browse/QPID-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gordon Sim resolved QPID-2631.
------------------------------

    Resolution: Fixed

> Race in qpid::client::Bounds causes (rare) deadlock
> ---------------------------------------------------
>
>                 Key: QPID-2631
>                 URL: https://issues.apache.org/jira/browse/QPID-2631
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Client
>    Affects Versions: 0.5, 0.6
>            Reporter: Gordon Sim
>            Assignee: Gordon Sim
>             Fix For: 0.7
>
>
> There is a race condition in the use of Bounds in SessionImpl::sendFrame. This function sends the frame first, then calls
> Bounds::expand(). But it's possible the network thread calls Bounds::reduce() between sending the frame and calling expand. If the Bounds::current value is 0
> that reduce() is lost. If enough reduce() calls are lost in this way eventually we will deadlock.
> In investigating this it also became clear that the connection frames weren't correctly accounted for (i.e. the bounds are never expended for connection frames, though they are included in the byte count passed in on reduce()). Though this shouldn't actually cause any problem it is logically incorrect, unintuitive and could mask problems that are hard to diagnose.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org