From dev-return-10782-apmail-activemq-dev-archive=activemq.apache.org@activemq.apache.org Wed May 21 19:31:16 2008 Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 44842 invoked from network); 21 May 2008 19:31:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 May 2008 19:31:15 -0000 Received: (qmail 4163 invoked by uid 500); 21 May 2008 19:31:16 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 4134 invoked by uid 500); 21 May 2008 19:31:16 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 4122 invoked by uid 99); 21 May 2008 19:31:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 12:31:16 -0700 X-ASF-Spam-Status: No, hits=-1998.5 required=10.0 tests=ALL_TRUSTED,WEIRD_PORT X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 May 2008 19:30:38 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7F75D234C120 for ; Wed, 21 May 2008 12:30:54 -0700 (PDT) Message-ID: <433135074.1211398254520.JavaMail.jira@brutus> Date: Wed, 21 May 2008 12:30:54 -0700 (PDT) From: "Anthony Enache (JIRA)" To: dev@activemq.apache.org Subject: [jira] Issue Comment Edited: (AMQNET-87) CLONE -Strange Disconnect issues with .Net and VS2005 In-Reply-To: <2004862671.1211393094370.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/activemq/browse/AMQNET-87?page=3Dcom.atlass= ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D4= 2934#action_42934 ]=20 aenache edited comment on AMQNET-87 at 5/21/08 12:29 PM: ---------------------------------------------------------------- I believe this issue is likely related to a problem that I've found and res= olved with the attached patch. Environment: =09 Windows XP, VS2005, grabbed Apache.NMS SVN head as of 5= /21, using ActiveMQ 5.1 on server. Problem: Commands are issued asynchronously to the broker by client thread= s. Client requests eventually are handled by the transport layer ResponseC= orrelator.Request() method. This method invokes an asynchronous send of th= e user command to the broker and receives back a FutureResponse object whic= h it uses to block indefinitely ( wait time is -1 ) pending receipt of a re= ply from the broker. Replies are received in the method OnCommand() which = sets the FutureResponse signaling the blocked client thread to wake and con= tinue. Unfortunately, in the event of a network issue where the client can= no longer communicate with the broker, OnCommand() will never be called, c= ausing client threads to block indefinitely. The chances that OnCommand() will never be called in the event of a network= ing issue increase greatly if the client has registered an exception handle= r for the connection. In my particular usage pattern, my handler closes th= e broken connection and spawns a separate thread to attempt to reconnect. = Since the connection has been closed, threads pending a FutureResponse are = effectively leaked by my application.=20 All of this will probably become a non issue once the failover transport is= implemented, but for now, I've attached a patch that can be used to get ar= ound the problem.=20 My approach is to have the ResponseCorrelator override the TransportFilter.= OnException() method to iterate through the requestMap holding pending Futu= reResponse objects, and provide a BrokerError response to each, thereby cau= sing the latch to count down and client threads to proceed.=20 Hopefully, someone finds the patch useful. was (Author: aenache): I believe this issue is likely related to a problem that I've found and= resolved with the attached patch. Environment: =09 Windows XP, VS2005, grabbed Apache.NMS SVN head as of 5= /21, using ActiveMQ 5.1 on server. Problem: Upon broker connection problems, sending threads block indefinite= ly if the connection is closed. In my case, I register an exception handle= r with the connection that closes bad connections and cleans up ancillary o= bjects created from that connection ( session, consumers, producers, etc. )= I then spawn a new thread that attempts to reestablish the connection to= the broker. As mentioned in the cloned description, from a client perspec= tive, the thread that is attempting to send a message to a queue registers = no exception. This is due to the fact that it is pending a response receip= t in ResponseCorrelator.cs:94 : Response response =3D future.Response; Since the connection has been closed, no response will ever be forthcoming,= the FutureResponse latch never counts down, and the calling thread never c= omes back from the wait. So, we have a thread leak and no exception is gen= erated that a client could handle. My approach to fixing / working around the problem is to have the ResponseC= orrelator override the TransportFilter.OnException() method to iterate thro= ugh the requestMap holding pending FutureResponse objects, and provide a Br= okerError response to each, thereby causing the latch to count down and cli= ent threads to proceed.=20 I've attached a patch of this fix. Hopefully, it's useful. =20 > CLONE -Strange Disconnect issues with .Net and VS2005 > ----------------------------------------------------- > > Key: AMQNET-87 > URL: https://issues.apache.org/activemq/browse/AMQNET-87 > Project: ActiveMQ .Net > Issue Type: Bug > Components: ActiveMQ Client > Environment: Windows XP, VS2005, grabbed head of .Net client as o= f 2/12, useing ActiveMQ 4.1 on server > Reporter: Anthony Enache > Assignee: James Strachan > Fix For: 1.1 > > Attachments: ResponseCorrelator.patch > > > I have a strange issue. I'm testing bad network conditions, where the cl= ient looses connectivity to the server. If the server is remote, and the c= lient is inside my lan, and my lan looses internet connection, at least 1 t= ime in 3 when the consumer gets created (or at least throws no error messag= es), but doesn't actually consume messages off of the queue. This leads to= no error message that I can catch, but the client never recieving another = message. For reasons that escape me, this happens FAR more frequently when= you run this program OUTSIDE of vs2005. When I run through the debugger, = or even through a "Release" build inside vs2005, this very rarely occurs. = Also, though this is much more minor, when the client does manage to reconn= ect cleanly, I get 2 messages for each one I send, as if the consumer prior= to the internet connection loss isn't being deleted. However, once I star= t and stop the Connection, I get just one message recieved per message sent= . I'll show this in step form below. Thanks for your assistance! > Jamie > Steps: > 1. Run a standard ActiveMQ server on a remote point > 2. Run a client inside your lan (Fixing IP address and port for where t= he server resides) > 3. Click "start" on the app, you'll see the messages your recieving star= t scrolling down > 4. Yank the cord from your router that gives you an external internet co= nnection > 5. After about 8 seconds, the text will tell you the disconnect occured,= then replug in the cord > 6. Click "start" again. might need to do it more then once, as sometime= s it's slow to get a good connection again > 7. At least 1 in 3 times after you click "start" it'll clear the text, b= ut you'll never see another message, even if you "stop" and "start" again (= leaving the cord alone) > 8. The rest of the time you'll see 2 messages appear for each one sent, = after clicking "stop" and "start" again, you'll see normal behavior. =20 > I've attached both the client project I'm using for testing. I was using= the stock ActiveMQ 4.1 server, only changing the IP Address of the TCP con= nection to point to the correct address. --=20 This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.