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 e.semog@gmail.com designates
 64.233.166.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=t9PBGH8HbE0fzggiwhiUjrDiTi7AD5Xs9nFIs77HL3gc1LmEBbWMOT8iK9dN4CHAwe
         IMm6o1yUwVoUa4R9maVcWdwraxxNOWOKaCB42wJzkGoL3yCeSj1f6rqfSZJo59koi13x
         VFRrTNNpPNFiEy1GahDwNTMIkLZGky0UHa6Ow=
Message-ID: <5a56ce1b0809081249u30fbf4b7l12ef50444d49bbf0@mail.gmail.com>
Date: Mon, 8 Sep 2008 12:49:13 -0700
From: "Jim Gomes" <e.semog@gmail.com>
To: users@activemq.apache.org
Subject: Re: ActiveMQ+NMS+TCP Connection Problems
In-Reply-To: <7fd310d10809041546h19a21fe4ldb8862bdcf862564@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_75440_13570383.1220903353360"
References: <7fd310d10809041546h19a21fe4ldb8862bdcf862564@mail.gmail.com>

------=_Part_75440_13570383.1220903353360
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Bryan,
I can't answer all of your questions, yet.  But I can answer some of them,
anyway.

1. As far as the ResponseTimeout property goes, that is used for network
timeouts.  It's not a JMS timeout value like TimeToLive.  The
ResponseTimeout is used by the client to wait for a response from the
broker.  Since a network call is inherently a blocking operation (send
request, wait for response), if we never receive a response from a dead/hung
broker, the client will hang as well.  The ResponseTimeout lets client abort
waiting for the response from the broker.  This can be set to whatever
performance constraints your application requires.  In a WAN environment,
this might be set to something fairly high where there is a lot of latency
in network round-trips.  The socket connection is not dropped.  The client
simply stops waiting for the broker to respond and goes into its
error-handling code for a non-response.

2. I see the marshalling code for the KeepAliveInfo, but like you I don't
see how this is turned on or controlled from the client-side.  This would
need more investigation to see if it is enabled via a URI parameter, or if
new code needs to be written to enable its use.

3. Can't answer the server-side socket issue.  Don't know that code.


On Thu, Sep 4, 2008 at 3:46 PM, Bryan Murphy <bmurphy1976@gmail.com> wrote:

> Hey Guys,
> We're still having problems consuming messages from an ActiveMQ service via
> Apache.NMS.  We've fixed a few bugs in the past week, and we're left with
> one outstanding issue where we have one of our consumers in a different
> data-center than the message server.  It appears as if our TCP connections
> are timing out while the system is idle (possibly due to NAT translation
> timeouts) and we're never properly re-establishing connections back to the
> message server.
>
> I've dug around in the in the NMS code a bit, and I have a few questions.
>
> 1. TcpTransport, Connection, and Session have a property called
> "RequestTimeout".  I'm not entirely clear on what this property dose.  What
> times out, and what is a "request"?   What happens when one of these
> requests timeout?  Is the socket dropped and re-opened?
>
> 2. It does not appear that there is any way to turn KeepAlive on via the
> NMS
> client, but I do see code for handling keep alive packets.  The
> documentation here
> http://activemq.apache.org/tcp-transport-reference.htmlseems to imply
> that this is a client side option, but I was wondering if we
> could configure it in the server side and how could we verify that it was
> in
> fact running?
>
> 3. If a client reconnects to the server, does the server forcefully close
> the old socket?  I'm not sure this is happening, but it seems like a
> logical
> thing to do and I was curious what the expected behavior is.
>
> Any other suggestions how we can deal with this?  This channel is
> high-latency, but very low messages, so we don't mind if it takes awhile to
> handle these messages, we just need it to happen.
>
> Thanks,
> Bryan
>

------=_Part_75440_13570383.1220903353360--