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.
