Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com
 designates 209.85.213.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <JIRA.12686325.1387915536607.41314.1396330096039@arcas>
References: <JIRA.12686325.1387915536607@arcas>
	<JIRA.12686325.1387915536607.41314.1396330096039@arcas>
Date: Tue, 1 Apr 2014 10:11:15 +0100
Message-ID: 
 <CAH+vQmMpVBXUKmhXCaPZtmTrExKL6nC7-403xhF4f9m=BK0eGQ@mail.gmail.com>
Subject: Re: [jira] [Commented] (AMQ-4955) TCP Connections and related thread
 leak.
From: Gary Tully <gary.tully@gmail.com>
To: dev@activemq.apache.org
Content-Type: multipart/alternative; boundary=089e01182d0ad3185004f5f78c6e

--089e01182d0ad3185004f5f78c6e
Content-Type: text/plain; charset=ISO-8859-1

I think it should cause the connection to die. The subs currently don't
deal with a dispatch failure wrt stats and redelivery so the only safe
thing to do is termination.
On 1 Apr 2014 06:28, "Arthur Naseef (JIRA)" <jira@apache.org> wrote:

>
>     [
> https://issues.apache.org/jira/browse/AMQ-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956124#comment-13956124]
>
> Arthur Naseef commented on AMQ-4955:
> ------------------------------------
>
> Reading back through the comments, I see the issue being raised now -- the
> eaten IOException for all commands except MessageDispatch.
>
> I think the right thing to do here is to always re-throw the exception.
>  Can anyone think of a case in which an IOException on
> Broker.preProcessDispatch() or TransportConnection.dispatch() could have a
> non-fatal meaning?
>
> > TCP Connections and related thread leak.
> > ----------------------------------------
> >
> >                 Key: AMQ-4955
> >                 URL: https://issues.apache.org/jira/browse/AMQ-4955
> >             Project: ActiveMQ
> >          Issue Type: Bug
> >          Components: Broker
> >    Affects Versions: 5.8.0
> >         Environment: Windows 2008 R2, Jdk 1.7.40
> >            Reporter: Murali Mogalayapalli
> >            Assignee: Arthur Naseef
> >         Attachments: AMQ4955Test.java, TCP-Connection.jpg,
> ThreadStack.jpg, activemq.xml
> >
> >
> > TCP Connections and related thread leak.
> > Scenario
> > Active MQ version 5.8
> > NMS Client version 1.6
> > OS - Windows 2008 R2
> > JDK - 1.7.x
> > activemq.xml is attached
> > If a client connectivity gets lost between the time the initial socket
> is created and the exchange of the wire format, the active MQ server's
> Client's server thread gets blocked in socket read hanging out the TCP
> connection and the related thread
> > Here are the steps to recreate
> > 1. Configure the Active MQ server with the activemq.xml attached.
> > 2. Start the client in a debugger and have a break point at a place in
> such a way that the client can be disconnected after the socket is
> established.
> > 3. Once the breakpoint is hit, disconnect the client machine from the
> network
> > 4. Kill the client- This basically simulates a situation where the
> socket tear down packets are not reached the active mq server.
> > 5. Open the JConsole. Look for the hanging TCP connection and the
> related thread.
> > Is there an configurable option in Active MQ to sweep and close the
> connections, on regular interval, that still didn't finish the wire
> protocol negotiation?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)
>

--089e01182d0ad3185004f5f78c6e--