You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Gary Tully (Created) (JIRA)" <ji...@apache.org> on 2012/03/30 00:01:25 UTC

[jira] [Created] (AMQ-3792) use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use

use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use
-----------------------------------------------------------------------------------------------------------------------

                 Key: AMQ-3792
                 URL: https://issues.apache.org/jira/browse/AMQ-3792
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.5.1
            Reporter: Gary Tully
            Assignee: Gary Tully
             Fix For: 5.6.0


Chucking an javax.jms.InvalidClientIDException is currently conditional on the connection not being fault tolerant and not being a network connector which seems incorrect.
In both cases, a duplicate connection is still a duplicate and we should wait till it is cleaned up/disposed.

A failover variant of the test from https://issues.apache.org/jira/browse/AMQ-463 demonstrates.

This change was introduced in http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java?annotate=633800 but it looks like suppression of a duplicate connectionId in TransportConnector is sufficient for the reconnect case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (AMQ-3792) use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use

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

Gary Tully resolved AMQ-3792.
-----------------------------

    Resolution: Fixed

fixed in http://svn.apache.org/viewvc?rev=1307142&view=rev
                
> use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3792
>                 URL: https://issues.apache.org/jira/browse/AMQ-3792
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.1
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>              Labels: InvalidClientIDException, failover
>             Fix For: 5.6.0
>
>
> Chucking an javax.jms.InvalidClientIDException is currently conditional on the connection not being fault tolerant and not being a network connector which seems incorrect.
> In both cases, a duplicate connection is still a duplicate and we should wait till it is cleaned up/disposed.
> A failover variant of the test from https://issues.apache.org/jira/browse/AMQ-463 demonstrates.
> This change was introduced in http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java?annotate=633800 but it looks like suppression of a duplicate connectionId in TransportConnector is sufficient for the reconnect case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (AMQ-3792) use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use

Posted by "SuoNayi (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AMQ-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461423#comment-13461423 ] 

SuoNayi commented on AMQ-3792:
------------------------------

With the current solution,when using the connection to create session the InvalidClientIDException will be thrown but the underlying failover transport doesnot take action.
For creating session successfully, you have to recreate a new connection instance(close the old one),this is not good for the shared connection style such as Spring JMS.
We would like the transparent reconnect transport insteand of creating new connection.
                
> use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3792
>                 URL: https://issues.apache.org/jira/browse/AMQ-3792
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.1
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>              Labels: InvalidClientIDException, failover
>             Fix For: 5.6.0
>
>
> Chucking an javax.jms.InvalidClientIDException is currently conditional on the connection not being fault tolerant and not being a network connector which seems incorrect.
> In both cases, a duplicate connection is still a duplicate and we should wait till it is cleaned up/disposed.
> A failover variant of the test from https://issues.apache.org/jira/browse/AMQ-463 demonstrates.
> This change was introduced in http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java?annotate=633800 but it looks like suppression of a duplicate connectionId in TransportConnector is sufficient for the reconnect case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-3792) use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use

Posted by "SuoNayi (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AMQ-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461417#comment-13461417 ] 

SuoNayi commented on AMQ-3792:
------------------------------

when client receives InvalidClientIDException it does not take action, should it stop the underlying transport and do reconnect logic?
or for broker when it detects the duplicate clientID it should not only tell the client but also stop the transport?


                
> use of the failover transport incorrectly suppresses javax.jms.InvalidClientIDException when clientId is already in use
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3792
>                 URL: https://issues.apache.org/jira/browse/AMQ-3792
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.1
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>              Labels: InvalidClientIDException, failover
>             Fix For: 5.6.0
>
>
> Chucking an javax.jms.InvalidClientIDException is currently conditional on the connection not being fault tolerant and not being a network connector which seems incorrect.
> In both cases, a duplicate connection is still a duplicate and we should wait till it is cleaned up/disposed.
> A failover variant of the test from https://issues.apache.org/jira/browse/AMQ-463 demonstrates.
> This change was introduced in http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java?annotate=633800 but it looks like suppression of a duplicate connectionId in TransportConnector is sufficient for the reconnect case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira