You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by lyall <Ly...@The-Pearces.com> on 2009/05/18 07:12:30 UTC
Durable Subscriber and unclean disconnection
I am using ActiveMQ 5.2.0 on Windows 2003 Server.
Out of the box config.
If a client to a topic disconnects, due to failure, or in my case,
re-deployment of a BPEL process, it cannot re-connect as ActiveMQ says that
it is still connected.
I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole slew of new
problems, including which interfaces it listens on and trying to establish
connections with itself if I attempt to force particular interfaces - at
least 5.2.0 works, except for this reconnection point.
How can I work around this? Can I?
...Lyall
--
View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by lyall <Ly...@The-Pearces.com>.
Further experimentation has ensued and here are my results.
I was using the free edition of PC-Tools Firewall Plus on Windows 2003
Server Enterprise, R2.
I figured that if I blocked the JAVA process, that would completely disable
ActiveMQ from talking to other instances. This was not the case, the
multicasts where still going out, which caused confusion because the
multicasts said the blocked ActiveMQ was alive but it could not be reached.
I created 2 advanced rules, one to block the multicast and one to block
normal connections, which created the expected disconnection scenario.
The two now seem to disconnect and re-connect nicely, although, I did notice
the transport connector cleaned up quite quickly, but the subscriber
channels took a while longer - maybe it's just my lack of understanding -
maybe the channels can have multiple transports, hence a different cleanup
cycle.
Thanks to those who have offered assistance.
...Lyall
--
View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23627612.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by lyall <Ly...@The-Pearces.com>.
I tried keepAlive=true and found something interesting.
I have ActiveMQ in 2 separate Windows VM's.
Basically, I am trying to simulate breaking the connection between the two
ActiveMQ's but each continuing to operate, independently, re-discovering and
re-connecting to each other when the network connection is restored.
On one VM, I have a free firewall installed which allows me to deny the java
VM access to the network.
I did this.
ActiveMQ had been communicating, quite nicely between themselves, using auto
discovery. Upon denial of access, things seemed to disconnect ok.
When I re-enabled access, they refused to talk to each other, with constant
connection failure and re-tries, with a repeat cycle of around every 10
seconds.
I restarted both instances to get things back on an even keel.
Simply stopping and re-starting ActiveMQ is fine, it's the abrupt failure
scenario which appears to be the problem.
Additionally, I am not entirely sure that the the firewall stops the
multicast broadcasts, so I think the broadcasts are being received but the
connections are failing. At least that is how I am interpreting the
output/logs.
I need to do some more testing on this, including some WireShark monitoring.
...Lyall
rajdavies wrote:
>
> I should have explained - that although this is client-side
> configuration - there is a handshake between the client and broker on
> initialization. The lowest value of maxInactivityDuration is used by
> both peers of the transport (client and broker). So if your client
> bounced - or the network connection between the client and broker
> bounced - the broker would be able to detect that.
>
> cheers,
>
> Rob
> On 19 May 2009, at 00:51, lyall wrote:
>
>>
>> Thanks Rob.
>>
>> I had a look at those, but they appear to address the Client
>> configuration.
>> My problem is if the Client unexpectedly goes away and comes back, the
>> durable subscriber is unable to re-connect because ActiveMQ 5.2 says
>> that
>> they are already connected.
>> I will admit, I have yet to test if I have 'keepAlive=true' in my
>> client
>> configuration, whether that will cause a cleanup in the ActiveMQ
>> server - I
>> will keep this thread informed as to the status.
>>
>> ...Lyall
>>
>>
>> rajdavies wrote:
>>>
>>> Have you disabled the maxInactivityDuration by setting it to zero ?
>>> If you have - your broker may not detect the transport socket has
>>> expired - and cleanly closed the connection.
>>> See - http://activemq.apache.org/configuring-wire-formats.html
>>>
>>> cheers,
>>>
>>> Rob
>>>
>>> On 18 May 2009, at 10:32, lyall wrote:
>>>
>>>>
>>>> Thank you Gary.
>>>>
>>>> I had found another post regarding this same 'disconnected durable
>>>> subscriber' issue.
>>>> Simply saying 'BPEL should correctly disconnect', does not help if
>>>> the BPEL
>>>> server should happen to fail - power, hardware, network disconnect,
>>>> etc. The
>>>> new connection needs to replace the old, if it can be shown that the
>>>> old is
>>>> dead. I have no idea if this is possible.
>>>>
>>>> Regarding the 'connecting to itself', I will attempt to obtain more
>>>> info,
>>>> maybe the Snapshot version, once I get the wildcard setting done,
>>>> does not
>>>> have the problems with regard to durable subscribers. It's entirely
>>>> possible
>>>> my bumbling attempts at configuration introduced the problem itself.
>>>> I will
>>>> have another crack and get back.
>>>>
>>>> ...Lyall
>>>>
>>>>
>>>>
>>>>
>>>> Gary Tully wrote:
>>>>>
>>>>> seems like a bpel process un/re-deployment logic should be doing an
>>>>> unsubscribe to remove the durable subscription.
>>>>>
>>>>> Failing this, an activemq feature where a configuration option on a
>>>>> durable
>>>>> subscriber could specify an inactivityTimeout after which time an
>>>>> inactive
>>>>> durable subscription would expire could help here. No such feature
>>>>> exists
>>>>> at
>>>>> the moment though.
>>>>>
>>>>> On localhost listens and multiple interfaces with the 5.3-SNAPSHOT,
>>>>> some
>>>>> details can be found in the AMQ-2094 jira issue
>>>>> <https://issues.apache.org/activemq/browse/AMQ-2094>for that change
>>>>> of
>>>>> behavior. To listen on all interfaces (the old behaviour) you
>>>>> need to
>>>>> specify the wildcard address.
>>>>> Could you comment on that issue with your feedback w.r.t
>>>>> connections to
>>>>> its
>>>>> self so we can get to the bottom of it? thanks.
>>>>>
>>>>> 2009/5/18 lyall <Ly...@the-pearces.com>
>>>>>
>>>>>>
>>>>>> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
>>>>>> Out of the box config.
>>>>>> If a client to a topic disconnects, due to failure, or in my case,
>>>>>> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ
>>>>>> says
>>>>>> that
>>>>>> it is still connected.
>>>>>>
>>>>>> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole
>>>>>> slew of
>>>>>> new
>>>>>> problems, including which interfaces it listens on and trying to
>>>>>> establish
>>>>>> connections with itself if I attempt to force particular
>>>>>> interfaces - at
>>>>>> least 5.2.0 works, except for this reconnection point.
>>>>>>
>>>>>> How can I work around this? Can I?
>>>>>>
>>>>>> ...Lyall
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
>>>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://blog.garytully.com
>>>>>
>>>>> Open Source SOA
>>>>> http://FUSESource.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23594092.html
>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23607343.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23614457.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by keneida <ke...@o2.pl>.
rajdavies wrote:
>
> I should have explained - that although this is client-side
> configuration - there is a handshake between the client and broker on
> initialization. The lowest value of maxInactivityDuration is used by
> both peers of the transport (client and broker).
>
Just to be sure. If client has 0 and broker 60 the lowest is 0 and it will
be used. But 0 means disabling the inactivity monitor so in this case
should it select it instead of 60?
--
View this message in context: http://old.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p27432881.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by Rob Davies <ra...@gmail.com>.
I should have explained - that although this is client-side
configuration - there is a handshake between the client and broker on
initialization. The lowest value of maxInactivityDuration is used by
both peers of the transport (client and broker). So if your client
bounced - or the network connection between the client and broker
bounced - the broker would be able to detect that.
cheers,
Rob
On 19 May 2009, at 00:51, lyall wrote:
>
> Thanks Rob.
>
> I had a look at those, but they appear to address the Client
> configuration.
> My problem is if the Client unexpectedly goes away and comes back, the
> durable subscriber is unable to re-connect because ActiveMQ 5.2 says
> that
> they are already connected.
> I will admit, I have yet to test if I have 'keepAlive=true' in my
> client
> configuration, whether that will cause a cleanup in the ActiveMQ
> server - I
> will keep this thread informed as to the status.
>
> ...Lyall
>
>
> rajdavies wrote:
>>
>> Have you disabled the maxInactivityDuration by setting it to zero ?
>> If you have - your broker may not detect the transport socket has
>> expired - and cleanly closed the connection.
>> See - http://activemq.apache.org/configuring-wire-formats.html
>>
>> cheers,
>>
>> Rob
>>
>> On 18 May 2009, at 10:32, lyall wrote:
>>
>>>
>>> Thank you Gary.
>>>
>>> I had found another post regarding this same 'disconnected durable
>>> subscriber' issue.
>>> Simply saying 'BPEL should correctly disconnect', does not help if
>>> the BPEL
>>> server should happen to fail - power, hardware, network disconnect,
>>> etc. The
>>> new connection needs to replace the old, if it can be shown that the
>>> old is
>>> dead. I have no idea if this is possible.
>>>
>>> Regarding the 'connecting to itself', I will attempt to obtain more
>>> info,
>>> maybe the Snapshot version, once I get the wildcard setting done,
>>> does not
>>> have the problems with regard to durable subscribers. It's entirely
>>> possible
>>> my bumbling attempts at configuration introduced the problem itself.
>>> I will
>>> have another crack and get back.
>>>
>>> ...Lyall
>>>
>>>
>>>
>>>
>>> Gary Tully wrote:
>>>>
>>>> seems like a bpel process un/re-deployment logic should be doing an
>>>> unsubscribe to remove the durable subscription.
>>>>
>>>> Failing this, an activemq feature where a configuration option on a
>>>> durable
>>>> subscriber could specify an inactivityTimeout after which time an
>>>> inactive
>>>> durable subscription would expire could help here. No such feature
>>>> exists
>>>> at
>>>> the moment though.
>>>>
>>>> On localhost listens and multiple interfaces with the 5.3-SNAPSHOT,
>>>> some
>>>> details can be found in the AMQ-2094 jira issue
>>>> <https://issues.apache.org/activemq/browse/AMQ-2094>for that change
>>>> of
>>>> behavior. To listen on all interfaces (the old behaviour) you
>>>> need to
>>>> specify the wildcard address.
>>>> Could you comment on that issue with your feedback w.r.t
>>>> connections to
>>>> its
>>>> self so we can get to the bottom of it? thanks.
>>>>
>>>> 2009/5/18 lyall <Ly...@the-pearces.com>
>>>>
>>>>>
>>>>> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
>>>>> Out of the box config.
>>>>> If a client to a topic disconnects, due to failure, or in my case,
>>>>> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ
>>>>> says
>>>>> that
>>>>> it is still connected.
>>>>>
>>>>> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole
>>>>> slew of
>>>>> new
>>>>> problems, including which interfaces it listens on and trying to
>>>>> establish
>>>>> connections with itself if I attempt to force particular
>>>>> interfaces - at
>>>>> least 5.2.0 works, except for this reconnection point.
>>>>>
>>>>> How can I work around this? Can I?
>>>>>
>>>>> ...Lyall
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
>>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://blog.garytully.com
>>>>
>>>> Open Source SOA
>>>> http://FUSESource.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23594092.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23607343.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Durable Subscriber and unclean disconnection
Posted by lyall <Ly...@The-Pearces.com>.
Thanks Rob.
I had a look at those, but they appear to address the Client configuration.
My problem is if the Client unexpectedly goes away and comes back, the
durable subscriber is unable to re-connect because ActiveMQ 5.2 says that
they are already connected.
I will admit, I have yet to test if I have 'keepAlive=true' in my client
configuration, whether that will cause a cleanup in the ActiveMQ server - I
will keep this thread informed as to the status.
...Lyall
rajdavies wrote:
>
> Have you disabled the maxInactivityDuration by setting it to zero ?
> If you have - your broker may not detect the transport socket has
> expired - and cleanly closed the connection.
> See - http://activemq.apache.org/configuring-wire-formats.html
>
> cheers,
>
> Rob
>
> On 18 May 2009, at 10:32, lyall wrote:
>
>>
>> Thank you Gary.
>>
>> I had found another post regarding this same 'disconnected durable
>> subscriber' issue.
>> Simply saying 'BPEL should correctly disconnect', does not help if
>> the BPEL
>> server should happen to fail - power, hardware, network disconnect,
>> etc. The
>> new connection needs to replace the old, if it can be shown that the
>> old is
>> dead. I have no idea if this is possible.
>>
>> Regarding the 'connecting to itself', I will attempt to obtain more
>> info,
>> maybe the Snapshot version, once I get the wildcard setting done,
>> does not
>> have the problems with regard to durable subscribers. It's entirely
>> possible
>> my bumbling attempts at configuration introduced the problem itself.
>> I will
>> have another crack and get back.
>>
>> ...Lyall
>>
>>
>>
>>
>> Gary Tully wrote:
>>>
>>> seems like a bpel process un/re-deployment logic should be doing an
>>> unsubscribe to remove the durable subscription.
>>>
>>> Failing this, an activemq feature where a configuration option on a
>>> durable
>>> subscriber could specify an inactivityTimeout after which time an
>>> inactive
>>> durable subscription would expire could help here. No such feature
>>> exists
>>> at
>>> the moment though.
>>>
>>> On localhost listens and multiple interfaces with the 5.3-SNAPSHOT,
>>> some
>>> details can be found in the AMQ-2094 jira issue
>>> <https://issues.apache.org/activemq/browse/AMQ-2094>for that change
>>> of
>>> behavior. To listen on all interfaces (the old behaviour) you need to
>>> specify the wildcard address.
>>> Could you comment on that issue with your feedback w.r.t
>>> connections to
>>> its
>>> self so we can get to the bottom of it? thanks.
>>>
>>> 2009/5/18 lyall <Ly...@the-pearces.com>
>>>
>>>>
>>>> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
>>>> Out of the box config.
>>>> If a client to a topic disconnects, due to failure, or in my case,
>>>> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ
>>>> says
>>>> that
>>>> it is still connected.
>>>>
>>>> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole
>>>> slew of
>>>> new
>>>> problems, including which interfaces it listens on and trying to
>>>> establish
>>>> connections with itself if I attempt to force particular
>>>> interfaces - at
>>>> least 5.2.0 works, except for this reconnection point.
>>>>
>>>> How can I work around this? Can I?
>>>>
>>>> ...Lyall
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
>>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>> --
>>> http://blog.garytully.com
>>>
>>> Open Source SOA
>>> http://FUSESource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23594092.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23607343.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by Rob Davies <ra...@gmail.com>.
Have you disabled the maxInactivityDuration by setting it to zero ?
If you have - your broker may not detect the transport socket has
expired - and cleanly closed the connection.
See - http://activemq.apache.org/configuring-wire-formats.html
cheers,
Rob
On 18 May 2009, at 10:32, lyall wrote:
>
> Thank you Gary.
>
> I had found another post regarding this same 'disconnected durable
> subscriber' issue.
> Simply saying 'BPEL should correctly disconnect', does not help if
> the BPEL
> server should happen to fail - power, hardware, network disconnect,
> etc. The
> new connection needs to replace the old, if it can be shown that the
> old is
> dead. I have no idea if this is possible.
>
> Regarding the 'connecting to itself', I will attempt to obtain more
> info,
> maybe the Snapshot version, once I get the wildcard setting done,
> does not
> have the problems with regard to durable subscribers. It's entirely
> possible
> my bumbling attempts at configuration introduced the problem itself.
> I will
> have another crack and get back.
>
> ...Lyall
>
>
>
>
> Gary Tully wrote:
>>
>> seems like a bpel process un/re-deployment logic should be doing an
>> unsubscribe to remove the durable subscription.
>>
>> Failing this, an activemq feature where a configuration option on a
>> durable
>> subscriber could specify an inactivityTimeout after which time an
>> inactive
>> durable subscription would expire could help here. No such feature
>> exists
>> at
>> the moment though.
>>
>> On localhost listens and multiple interfaces with the 5.3-SNAPSHOT,
>> some
>> details can be found in the AMQ-2094 jira issue
>> <https://issues.apache.org/activemq/browse/AMQ-2094>for that change
>> of
>> behavior. To listen on all interfaces (the old behaviour) you need to
>> specify the wildcard address.
>> Could you comment on that issue with your feedback w.r.t
>> connections to
>> its
>> self so we can get to the bottom of it? thanks.
>>
>> 2009/5/18 lyall <Ly...@the-pearces.com>
>>
>>>
>>> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
>>> Out of the box config.
>>> If a client to a topic disconnects, due to failure, or in my case,
>>> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ
>>> says
>>> that
>>> it is still connected.
>>>
>>> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole
>>> slew of
>>> new
>>> problems, including which interfaces it listens on and trying to
>>> establish
>>> connections with itself if I attempt to force particular
>>> interfaces - at
>>> least 5.2.0 works, except for this reconnection point.
>>>
>>> How can I work around this? Can I?
>>>
>>> ...Lyall
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>> --
>> http://blog.garytully.com
>>
>> Open Source SOA
>> http://FUSESource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23594092.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Durable Subscriber and unclean disconnection
Posted by lyall <Ly...@The-Pearces.com>.
Thank you Gary.
I had found another post regarding this same 'disconnected durable
subscriber' issue.
Simply saying 'BPEL should correctly disconnect', does not help if the BPEL
server should happen to fail - power, hardware, network disconnect, etc. The
new connection needs to replace the old, if it can be shown that the old is
dead. I have no idea if this is possible.
Regarding the 'connecting to itself', I will attempt to obtain more info,
maybe the Snapshot version, once I get the wildcard setting done, does not
have the problems with regard to durable subscribers. It's entirely possible
my bumbling attempts at configuration introduced the problem itself. I will
have another crack and get back.
...Lyall
Gary Tully wrote:
>
> seems like a bpel process un/re-deployment logic should be doing an
> unsubscribe to remove the durable subscription.
>
> Failing this, an activemq feature where a configuration option on a
> durable
> subscriber could specify an inactivityTimeout after which time an inactive
> durable subscription would expire could help here. No such feature exists
> at
> the moment though.
>
> On localhost listens and multiple interfaces with the 5.3-SNAPSHOT, some
> details can be found in the AMQ-2094 jira issue
> <https://issues.apache.org/activemq/browse/AMQ-2094>for that change of
> behavior. To listen on all interfaces (the old behaviour) you need to
> specify the wildcard address.
> Could you comment on that issue with your feedback w.r.t connections to
> its
> self so we can get to the bottom of it? thanks.
>
> 2009/5/18 lyall <Ly...@the-pearces.com>
>
>>
>> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
>> Out of the box config.
>> If a client to a topic disconnects, due to failure, or in my case,
>> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ says
>> that
>> it is still connected.
>>
>> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole slew of
>> new
>> problems, including which interfaces it listens on and trying to
>> establish
>> connections with itself if I attempt to force particular interfaces - at
>> least 5.2.0 works, except for this reconnection point.
>>
>> How can I work around this? Can I?
>>
>> ...Lyall
>> --
>> View this message in context:
>> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> http://blog.garytully.com
>
> Open Source SOA
> http://FUSESource.com
>
>
--
View this message in context: http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23594092.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Durable Subscriber and unclean disconnection
Posted by Gary Tully <ga...@gmail.com>.
seems like a bpel process un/re-deployment logic should be doing an
unsubscribe to remove the durable subscription.
Failing this, an activemq feature where a configuration option on a durable
subscriber could specify an inactivityTimeout after which time an inactive
durable subscription would expire could help here. No such feature exists at
the moment though.
On localhost listens and multiple interfaces with the 5.3-SNAPSHOT, some
details can be found in the AMQ-2094 jira issue
<https://issues.apache.org/activemq/browse/AMQ-2094>for that change of
behavior. To listen on all interfaces (the old behaviour) you need to
specify the wildcard address.
Could you comment on that issue with your feedback w.r.t connections to its
self so we can get to the bottom of it? thanks.
2009/5/18 lyall <Ly...@the-pearces.com>
>
> I am using ActiveMQ 5.2.0 on Windows 2003 Server.
> Out of the box config.
> If a client to a topic disconnects, due to failure, or in my case,
> re-deployment of a BPEL process, it cannot re-connect as ActiveMQ says that
> it is still connected.
>
> I tried 5.3.snapshot (as at 18-May-2009) but that bought a whole slew of
> new
> problems, including which interfaces it listens on and trying to establish
> connections with itself if I attempt to force particular interfaces - at
> least 5.2.0 works, except for this reconnection point.
>
> How can I work around this? Can I?
>
> ...Lyall
> --
> View this message in context:
> http://www.nabble.com/Durable-Subscriber-and-unclean-disconnection-tp23591185p23591185.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source SOA
http://FUSESource.com