From users-return-15835-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Thu Sep 04 22:47:04 2008 Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 22229 invoked from network); 4 Sep 2008 22:47:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Sep 2008 22:47:04 -0000 Received: (qmail 81329 invoked by uid 500); 4 Sep 2008 22:47:00 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 81313 invoked by uid 500); 4 Sep 2008 22:47:00 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 81302 invoked by uid 99); 4 Sep 2008 22:47:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Sep 2008 15:47:00 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bmurphy1976@gmail.com designates 209.85.134.188 as permitted sender) Received: from [209.85.134.188] (HELO mu-out-0910.google.com) (209.85.134.188) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Sep 2008 22:46:02 +0000 Received: by mu-out-0910.google.com with SMTP id i2so123103mue.6 for ; Thu, 04 Sep 2008 15:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=D2H3KPW3h86lGSVl86Ox1DVSVtpu3/yQ8VT1ZRMwaxs=; b=oznv9zLZrRDpR7biv7LXiN0CxsSstZASpdHNB9ZW8D00mo+g72ohRlYOlDjSVt0w/k lO4CjB9YaewQ57s6BHUx4YR1UmKn/rGyYQf9eqe/88evYXMGisyDHtFx8AuB/D5Ow3mx 2Wzvi/Qj8i5gYMzfKfvcrtFypBTyoSiGA8gO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=J9NbU2QumUTpL3P/pTChB/b1Y/vEwQzSAxURlSVGPW2P1PueoMBiTy7Hx3FeMDcAwQ 0sfFf5/XCyWKM8MUqGJ8jgIFwrmtiqz77lKrM9eEf0d0Rosc+dBPNsW/GqegFFAJKLC5 jm44kQvt3MFYjX4qpZcouSDBWn8lOumLVix4Q= Received: by 10.103.213.19 with SMTP id p19mr7400961muq.70.1220568392073; Thu, 04 Sep 2008 15:46:32 -0700 (PDT) Received: by 10.103.134.10 with HTTP; Thu, 4 Sep 2008 15:46:32 -0700 (PDT) Message-ID: <7fd310d10809041546h19a21fe4ldb8862bdcf862564@mail.gmail.com> Date: Thu, 4 Sep 2008 17:46:32 -0500 From: "Bryan Murphy" To: users@activemq.apache.org Subject: ActiveMQ+NMS+TCP Connection Problems MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_24886_9319996.1220568392075" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_24886_9319996.1220568392075 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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_24886_9319996.1220568392075--