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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
