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.
