You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2008/12/30 20:24:05 UTC

[jira] Created: (AMQ-2049) Race condition cleaning connection using VMTransport

Race condition cleaning connection using VMTransport
----------------------------------------------------

                 Key: AMQ-2049
                 URL: https://issues.apache.org/activemq/browse/AMQ-2049
             Project: ActiveMQ
          Issue Type: Bug
          Components: Transport
    Affects Versions: 5.3.0
            Reporter: David Jencks
            Assignee: David Jencks
             Fix For: 5.3.0


This problem arises when the server side has a RegionBroker installed and there is a configured clientID for the connection.

ActiveMQConnection.ensureConnectionInfoSent sends the ConnectionInfo object with the configured clientID off to the server.  Currently this results in the same ConnectionInfo object in the AMQConnection and the TransportConnection.

Now when you get to AMQConnection.cleanup() it asynchronously sends a message to the broker to clean up and immediately sets the configured clientID to null.  When the RegionBroker processes the remove message the clientID is no longer set (assuming bad luck in thread scheduling) and it complains:

    public void removeConnection(ConnectionContext context, ConnectionInfo info, Throwable error) throws Exception {
        String clientId = info.getClientId();
        if (clientId == null) {
            throw new InvalidClientIDException("No clientID specified for connection disconnect request");
        }

One fix for this is to copy the connectionInfo before sending it to the broker.  This is a small but unnecessary cost for non-vm transports but works.
Another fix might be to send the close message synchronously so it's processed before the clientID is nulled out.

I'm committing the "copy" solution but IMO this should be reviewed by experts.


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

[jira] Resolved: (AMQ-2049) Race condition cleaning connection using VMTransport

Posted by "David Jencks (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQ-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks resolved AMQ-2049.
-------------------------------

    Resolution: Fixed

rev 730226 solves this by copying.  Review would be great.  I also added a TODO about a question in AMQConnection.. line 1336

> Race condition cleaning connection using VMTransport
> ----------------------------------------------------
>
>                 Key: AMQ-2049
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2049
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.3.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: 5.3.0
>
>
> This problem arises when the server side has a RegionBroker installed and there is a configured clientID for the connection.
> ActiveMQConnection.ensureConnectionInfoSent sends the ConnectionInfo object with the configured clientID off to the server.  Currently this results in the same ConnectionInfo object in the AMQConnection and the TransportConnection.
> Now when you get to AMQConnection.cleanup() it asynchronously sends a message to the broker to clean up and immediately sets the configured clientID to null.  When the RegionBroker processes the remove message the clientID is no longer set (assuming bad luck in thread scheduling) and it complains:
>     public void removeConnection(ConnectionContext context, ConnectionInfo info, Throwable error) throws Exception {
>         String clientId = info.getClientId();
>         if (clientId == null) {
>             throw new InvalidClientIDException("No clientID specified for connection disconnect request");
>         }
> One fix for this is to copy the connectionInfo before sending it to the broker.  This is a small but unnecessary cost for non-vm transports but works.
> Another fix might be to send the close message synchronously so it's processed before the clientID is nulled out.
> I'm committing the "copy" solution but IMO this should be reviewed by experts.

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