tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Rossbach ...@objektpark.de>
Subject Re: session replication errors
Date Sat, 12 Nov 2005 12:43:38 GMT
Hey Olve,

I found a bug inside pushMessage and I hopefully fix it. Please checkout 
the tomcat svn head,
build a tomcat,  made a test and report the results

Many thanks that you report the problem,
Peter

Peter Rossbach schrieb:

> Hey Olve,
>
> I look more deeply inside the code and find that 
> o.a.c.cluster.tcp.DataSender.checkKeepAlive and sendMessage are both 
> synchronized messages.
> That means that we currently don't close the socket as we transfer a 
> message. But this not means that I found
> the bug! ...
>
> I also look at your config and see that you configure two 
> ClusterSessionListener, please remove one!
>
> <ClusterListener
> className="org.apache.catalina.cluster.session.ClusterSessionListener"/>
>
> Thanks
> Peter
>
> Olve Hansen schrieb:
>
>> Hi,
>> First I must congratulate on the improvements of the clustering docs!
>> Now I don't have to guess nearly as much as before when trying to set up
>> clustering. :-)
>>
>> But I still have some troubles regarding clustering.
>> We have a webapp clustered over three tomcats, all on the same machine,
>> load balanced by mod_jk in an Apache frontend, using sticky lb, session
>> replication by fastasyncqueue.
>> It seems OK - no session dropouts in sticky mode, we can turn on and off
>> tomcats as we please.
>>
>> But, in the logs, we see numerous:
>> SEVERE: TCP Worker thread in cluster caught 'java.io.IOException:
>> Connection reset by peer' closing channel
>> java.io.IOException: Connection reset by peer
>> at sun.nio.ch.FileDispatcher.read0(Native Method)
>> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
>> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
>> at sun.nio.ch.IOUtil.read(IOUtil.java:206)
>> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
>> at
>> o.a.c.cluster.tcp.TcpReplicationThread.drainChannel(TcpReplicationThread.java:125)

>>
>> at
>> o.a.c.cluster.tcp.TcpReplicationThread.run(TcpReplicationThread.java:69)
>>
>> I am trying to track these down, as they are marked as SEVERE. The
>> tomcats sits on a Red Hat Linux server. It is configured with two
>> networks, one open to the world, and firewalled, the other is internal,
>> and is fully open. The internal net is used for clustering, db-access,
>> and mod_jk connections.
>>
>> How severe are these? Can they be a result of two near concurrent
>> requests, and the second request cancels the serialisation of the first
>> session object? If not, where should I start to look?
>>
>> Log files and cluster setup follows:
>>
>>  
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message