You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by mdblack98 <md...@yahoo.com> on 2013/04/13 15:58:32 UTC

client already connected from durable topic subscribers

Broker: localhost - Client: mblack3 already connected from
tcp://10.40.245.19:4688

I'm trying to make my client as robust as possible so I'm testing crashes at
different stages of processing.

This is the one thing that's slowing down developing this a lot.  When the
client crashes the subscription still shows under "Active Durable Topic
Subscribers".  And I haven't yet figured out how long it takes to time
out...but it seems like several hours at least....yuck....

Trying to restart the client gives the "already connected" which makes sense
as the ActiveMQ server hasn't timed out the dead client yet.

So....
#1 Can the client ask for the active subscriber to close that "Client ID"
when reconnecting?
#2 Can the client set the timeout so when the client just "disappears"  the
broker will timeout fairly soon?
#3 Is there some other solution for the client?

I don't want the subscription to be deleted....just the active client to be
closed.

I've tried:
failover -- says it's reconnecting but still get's the "already connected"
error.
keepalive -- doesn't seem to matter -- but I guess that doesn't impact the
broker timeout.

I don't want to modify the broker side...may not have any control over
it...so this should be a client choice.






--
View this message in context: http://activemq.2283324.n4.nabble.com/client-already-connected-from-durable-topic-subscribers-tp4665913.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: client already connected from durable topic subscribers

Posted by mdblack98 <md...@yahoo.com>.
I figured this was a common problem as there are tons of google references
but none for just a simple client (all seem to be3rd party apps with 3rd
party fixes to it).

tcp://10.2.100.209:61616?keepAlive=true

I don’t have access to the broker config – as I said – no control over it.

Broker is ActiveMQ 5.7.0





--
View this message in context: http://activemq.2283324.n4.nabble.com/client-already-connected-from-durable-topic-subscribers-tp4665913p4665915.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: client already connected from durable topic subscribers

Posted by Timothy Bish <ta...@gmail.com>.
On 04/13/2013 09:58 AM, mdblack98 wrote:
> Broker: localhost - Client: mblack3 already connected from
> tcp://10.40.245.19:4688
>
> I'm trying to make my client as robust as possible so I'm testing crashes at
> different stages of processing.
>
> This is the one thing that's slowing down developing this a lot.  When the
> client crashes the subscription still shows under "Active Durable Topic
> Subscribers".  And I haven't yet figured out how long it takes to time
> out...but it seems like several hours at least....yuck....
>
> Trying to restart the client gives the "already connected" which makes sense
> as the ActiveMQ server hasn't timed out the dead client yet.
>
> So....
> #1 Can the client ask for the active subscriber to close that "Client ID"
> when reconnecting?
> #2 Can the client set the timeout so when the client just "disappears"  the
> broker will timeout fairly soon?
> #3 Is there some other solution for the client?
>
> I don't want the subscription to be deleted....just the active client to be
> closed.
>
> I've tried:
> failover -- says it's reconnecting but still get's the "already connected"
> error.
> keepalive -- doesn't seem to matter -- but I guess that doesn't impact the
> broker timeout.
>
> I don't want to modify the broker side...may not have any control over
> it...so this should be a client choice.
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/client-already-connected-from-durable-topic-subscribers-tp4665913.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Its generally impossible to answer questions like these until you share 
some actual information like broker version, broker config, client uri 
string.

-- 
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/