activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AMQCPP-267) ResponseCorrelator::request() exception safety concern
Date Tue, 17 Nov 2009 21:13:54 GMT

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

Timothy Bish updated AMQCPP-267:
--------------------------------

    Fix Version/s: 3.1

> 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.


Mime
View raw message