Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of rajdavies@gmail.com
 designates 209.85.221.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=xHqw7vAMAoy/b3AiXBp2fm2tkM8dSLZkWzuqjIzzDK/d2G8//pQWDRcis7N4qup0dS
         4bZtkTd0bvoNOmvlZJfAsIiJGpZMtlgtB/z1HeoNMgTk3X8H4tHFQwO3Z1Wf3s+wZCOB
         hwSisCSkTnC0MGDc2ev6q7qq2raqqGpepSNHg=
Message-Id: <8BD05122-44DB-45AE-847C-2FF6DAB5C63F@gmail.com>
From: Rob Davies <rajdavies@gmail.com>
To: users@activemq.apache.org
In-Reply-To: <23607343.post@talk.nabble.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Durable Subscriber and unclean disconnection
Date: Tue, 19 May 2009 06:47:34 +0100
References: <23591185.post@talk.nabble.com>
 <3a73c17c0905180215k2b4e4359kfaf2284089fde882@mail.gmail.com>
 <23594092.post@talk.nabble.com>
 <E151EBE5-ED20-4C4A-A840-18D9ABA0ADBD@gmail.com>
 <23607343.post@talk.nabble.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 <Lyall@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.
>