activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Kallen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AMQ-844) tcp connections hang
Date Wed, 26 Jul 2006 00:20:23 GMT
    [ https://issues.apache.org/activemq/browse/AMQ-844?page=comments#action_36638 ] 
            
Ian Kallen commented on AMQ-844:
--------------------------------

We got to the bottom of this. It turned out that there were still some client processes running
activemq-3.1-M5 on the network hitting the 4.0.x servers. When took them offline (and then
fired them back up with 4.0.2 jars), everything stabilized. If backwards compatibility isn't
handled, it'd be nice if there was a graceful degradation; having the servers opaquely cease
to be responsive to *any* clients due to the presence of some other old clients was pretty
troublesome.

> tcp connections hang
> --------------------
>
>                 Key: AMQ-844
>                 URL: https://issues.apache.org/activemq/browse/AMQ-844
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>    Affects Versions: 4.0.2
>         Environment: Tried with j2sdk1.4.2_06 and jdk1.5.0_05 on redhat enterprise linux
4 (2.6 kernel).
>            Reporter: Ian Kallen
>            Priority: Minor
>
> This problem readily occurs running the standard examples:
> ant -Durl=tcp://10.10.3.73:61616?trace=true -Dmax=100 consumer  
> ant -Durl=tcp://10.10.3.73:61616 -Dmax=10 producer 
> ...run the producer side for 2-5 iterations before is just hangs. Once it's in that state,
all subsequent client connections hang (i.e. control-C out of either consumer or producer
and restart the connection: hangs).
> Upping and lowering soTimeout and other connection parameters has so far proven fruitless.
Switching JVMs, up'ing from 4.0.1 to 4.0.2-SNAPSHOT (on both client and server), and including/excluding
"-Ddurable=true" made no difference (all orignal test attempts were with durable messages
but in the end, not incluing that had no effect on whether or not the clients eventually hang).
The config on the server looks like this:
> <beans xmlns="http://activemq.org/config/1.0">
>   <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
>   <broker useJmx="true">
>     <persistenceAdapter>
>       <journaledJDBC journalLogFiles="5" dataDirectory="../activemq-data" 
>           dataSource="#postgres-ds"/>
>     </persistenceAdapter>
>     <transportConnectors>
>        <transportConnector name="default" uri="tcp://10.10.3.73:61616?trace=true"
/>
>     </transportConnectors>
>   </broker>
>   <bean id="postgres-ds" class="org.postgresql.ds.PGPoolingDataSource">
>     <property name="serverName" value="localhost"/>
>     <property name="databaseName" value="activemq"/>
>     <property name="portNumber" value="0"/>
>     <property name="user" value="activemq"/>
>     <property name="password" value="activemq"/>
>     <property name="dataSourceName" value="postgres"/>
>     <property name="initialConnections" value="5"/>
>     <property name="maxConnections" value="50"/>
>   </bean>
> </beans> 
> FWIW, this doesn't happen when running the same tests on a laptop (MacOS tiger) with
clients on loopback. Bug is "Minor" but (since is't only exhibited by a small group of us)without
being able validate the client connections, this is a not show-stopper for production use
of activemq.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message