You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Olivier Langlois (JIRA)" <ji...@apache.org> on 2009/11/17 16:37:52 UTC
[jira] Created: (AMQCPP-267) ResponseCorrelator::request()
exception safety concern
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
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.
[jira] Resolved: (AMQCPP-267) ResponseCorrelator::request()
exception safety concern
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AMQCPP-267) ResponseCorrelator::request()
exception safety concern
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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.