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.
