On 09.01.2010 12:13, Mark Thomas wrote:
On 08/01/2010 23:07, Robin Wilson wrote:
OK, I made the following changes (1 at a time) to 'server.xml', and retested:
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
processExpiresFrequency="1"
notifyListenersOnReplication="true"/>
No discernable difference was noted on the retest (NOTE: I have measured the
sessions vs. the number of 'threads requesting pages', and I think that the
sessions are actually expiring - just _much_ slower than my load generator is
creating them. So I'm creating 100,000 sessions in 'n' time period, and in that
same time period only 6,000 are being expired and removed (the ratio seems
pretty constant - ~94% of the sessions created are staying around).
Then I made this change to 'server.xml':
<Engine
name="tomcat"
backgroundProcessorDelay="1"
defaultHost="localhost">
Again, no discernable difference in behavior.
So, new question - is there a way to tell Tomcat to clear out larger numbers of sessions
at once? (Assuming they are past their "inactivity duration" period?) Even when
I shut off the load generators, it only clears the sessions at a rate of a few thousand
every second.
Given it works when the load is reduced, it looks like the expiration
logic is correct. One thing that would give you a bit more information
is setting the log level for org.apache.catalina.session.ManagerBase to
debug.
I wonder if you are simply creating sessions faster than the single
background thread can clear them out. If that is the case, how realistic
is your load? I'm happy to try a fix a genuine issue but I don't think
there is much benefit in making changes to address an artificial problem.
Seconding Mark: it seems for those "1 second idle timeout" sessions you
are not using the session at all. So why are you generating a huge
number of sessions you are never going to use?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
