tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject Re: Tomcat 4 Replication problems
Date Thu, 11 Sep 2003 18:34:22 GMT
>Could you elaborate more on where you are increasing the amount of sleep?
>It would seem to me that the right thing to do is to not start processing
>requests until the session manager has completely initialized, that way
>Tomcat starts handling requests as soon as it is ready.  In the case of
>the InMemoryReplicationManager, it should not complete initialization
>until after it either realizes there are no other Tomcats to synchronize
>with or it pulls the current sessions from one of the other Tomcats in the
>replication group.

The replication in T4 is a back port, hence it doesn't have the capabilities
to delay the startup of tomcat in any other way than putting a sleep on the
start thread.

So this is what would happen

1. Tomcat is starting up.
2. It creates your replicated context
3. The replicated contexts starts up the replication membership and session
replication in a separate thread
4. Tomcat goes on, and opens up the listen port

With a sleep in this would happen

1. Tomcat is starting up.
2. It creates your replicated context
3. The replicated contexts starts up the replication membership and session
replication in a separate thread
4. The context puts a sleep on the start thread so that the replication
logic can receive all the sessions from another machine before Tomcat starts
listening
5. Tomcat goes on, and opens up the listen port

Filip

----- Original Message -----
From: "David Rees" <dbr@greenhydrant.com>
To: "Filip Hanik" <mail@filip.net>
Cc: <tomcat-user@jakarta.apache.org>
Sent: Thursday, September 11, 2003 11:21 AM
Subject: Re: Tomcat 4 Replication problems


Filip Hanik said:
> If the session hasn't replicated to node 2 from node 1 by the time the
> second request comes in it is one of these problems:
>
> For your #1
> 1. Your sessions are way to big
> 2. You are not using the useDirtyFlag="true" flag, instead you have it set
> to false, hence replicating way too much.
> 3. Your network is to slow
> 4. My implementation sucks

1. Well, the session when established consists of about a half a dozen
strings with names and values ranging between 5-30 bytes, so I wouldn't
say the sessions are large.

2. useDirtyFlag is set to true.

3. LAN which is on a lightly used 100mbit lan.  The client and two Tomcat
machines are on the same LAN on the same switch.  All are hooked up to the
same 10/100 switch and are running at 100mbit.  If the client was on a
slower network, then yes, this wouldn't be a problem.

4. Can't vouch for this one since I haven't reviewed the source myself.  ;-)

Again, I don't think #1 is a huge issue as it is easily solved by using
sticky sessions with mod_jk.

> For your #2
> Yes, this is a problem. Tomcat starts listening for requests before the
> server is updated. The way around this is to put a longer sleep (right now
> it sleeps two seconds) before the continuation of the code. If you want I
> can add that in for you, or I can send you the source and you can fix it
> yourself.

Could you elaborate more on where you are increasing the amount of sleep?
It would seem to me that the right thing to do is to not start processing
requests until the session manager has completely initialized, that way
Tomcat starts handling requests as soon as it is ready.  In the case of
the InMemoryReplicationManager, it should not complete initialization
until after it either realizes there are no other Tomcats to synchronize
with or it pulls the current sessions from one of the other Tomcats in the
replication group.

-Dave


Mime
View raw message