[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] Resolved: (AMQ-2308)
From:       "Gary Tully (JIRA)" <jira () apache ! org>
Date:       2009-06-29 11:46:07
Message-ID: 1378551749.1246275967341.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/activemq/browse/AMQ-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Gary Tully resolved AMQ-2308.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 5.3.0

patch applied with thanks.

> org.apache.activemq.broker.ft.TransactedTopicMasterSlaveTest test hang on Solaris
> ---------------------------------------------------------------------------------
> 
> Key: AMQ-2308
> URL: https://issues.apache.org/activemq/browse/AMQ-2308
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Environment: Solaris - jdk15 32 bit - also jdk16 64 bit
> Reporter: Peter Jones
> Assignee: Gary Tully
> Fix For: 5.3.0
> 
> Attachments: TransactedTopicMasterSlaveTest.patch.txt
> 
> 
> Seeing the TransactedTopicMasterSlaveTest hang when run on Solaris.  After \
> examining jstack output for the hanging test and discussing with Gary Tully, he had \
> the following suggestion: {quote}
> Hi Peter,
> this looks like an example of http://issues.apache.org/activemq/browse/AMQ-1993 but \
> this time on the client side. It seems like a write that results in the first \
> reconnect attempt does not terminate but it should be aborting as there is no \
> listening or reading thread. I guess there is no back log because the next write is \
> blocked by the transport reconnect mutex. Some combination of low level tcp retries \
> should be able to be configured at the OS level, and I guess the defaults should be \
> less than 1 hour so I would expect this test to eventually complete, however, the \
> OS level timeouts and retries may be contingent on a backlog reaching a minimum and \
> currently there will be only one outstanding write due the the locking around the \
> reconnect logic. This being the case, some code needs to implement the timeout. The \
> solution from http://issues.apache.org/activemq/browse/AMQ-1993 may be a good \
> approach here. It will timeout a write call. However the solution is currently only \
> applicable to server side sockets, it needs to be extended to support a client \
> connection. I think all that is needed is to move the additional configuration code \
> from: org.apache.activemq.transport.TransportFactory.serverConfigure(Transport, \
> WireFormat, HashMap) to compositeConfigure that is called for all transports (both \
> client and server) {quote}
> Indeed, this fixes the problem.  I've attached a patch against trunk which resolves \
> the issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[prev in list] [next in list] [prev in thread] [next in thread]