You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2009/11/17 22:15:52 UTC

[jira] Resolved: (AMQCPP-267) ResponseCorrelator::request() exception safety concern

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

Timothy Bish resolved AMQCPP-267.
---------------------------------

    Resolution: Fixed

Resolved in trunk

> ResponseCorrelator::request() exception safety concern
> ------------------------------------------------------
>
>                 Key: AMQCPP-267
>                 URL: https://issues.apache.org/activemq/browse/AMQCPP-267
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 3.0.1
>            Reporter: Olivier Langlois
>            Assignee: Timothy Bish
>            Priority: Trivial
>             Fix For: 3.1
>
>   Original Estimate: 10 minutes
>  Remaining Estimate: 10 minutes
>
> It seems to me that since the function oneway() and futureResponse::getResponse() can throw exceptions, the code should make sure that the requestMap is cleared in all cases.
> This risk is low but nevertheless I would not rely on an external software component good behavior to ensure the client invariants. This is especially true since the precaution is extremely simple.
> I would propose something like:
> try
> {
>         // Send the request.
>         next->oneway( command );
>         // Get the response.
>         response = futureResponse->getResponse( timeout );
> }
> catch(...)
> {
>         // Perform cleanup on the map.
>         synchronized( &mapMutex )
>        {
>             // We do not want memory corruption by accessing freed
>             // futureResponse objects by accident in onCommand() - get this thing out
>             // of the map.
>             requestMap.erase( command->getCommandId() );
>         }
>        throw;
> }
> synchronized( &mapMutex ){
>     // We've done our waiting - get this thing out
>     // of the map.
>     requestMap.erase( command->getCommandId() );
> }

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