Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 5:19 PM, Robin Wilson wrote: Your point is well taken about not creating the short-duration sessions, but alas, Tapestry is the chosen framework - and it uses the session as a mechanism to pass (more-or-less) global values between components of the page creation process. So ripping out that capability in Tapestry would require a massive change to our infrastructure. I know virtualy nothing about Tapestry, but this page (http://tapestry.apache.org/tapestry4.1/usersguide/state.html) has the following nugget: Tapestry defers creation of the HttpSession until one of two things happens: When a session-scoped application state object is first created, or when the first persistent page property is recorded. At this point, Tapestry will create the HttpSession to hold the object or property. This would seem to indicate that you do have some control over the creation of sessions: by avoiding session-scoped application state objects and persistent page properties, you ought to avoid session creation. Another option would be to enable session stickiness and disable session replication: this improves performance across the board, while inconveniencing anyone who happens to have been using a server that gets failed-over to another server. Your notes on the clustering (changes to DeltaManager) are right on target. So we adjusted when the DeltaManager creates the session until the end of processing, so that we know the timeout before we attempt to replicate it to other cluster members. That way, we already know the actual timeout duration before we decide whether to replicate. Sounds good. All of this would be unnecessary if there was some sort of session cleanup process that could dump expired sessions en masse every so often. Near as we can tell, each session has to be individually expired, which is why it lags so far behind the creation process. You can always call session.invalidate() on a session that you already know will be useless. You could even do this in a Filter: any session that is worth keeping around could contain a key like KEEP_ME. If that flag exists, then allow the DeltaManager to replicate the session. Otherwise, call invalidate() and kill the session immediately. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktN4OoACgkQ9CaO5/Lv0PC4MQCdFG4J4jCfNhcapr4sb7+cA9k2 lXEAoJ8wOKpSdF9hTcbag6tZPibgVKvp =ywoI -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
The sensible approach would be 1. Refactor DeltaManager and BackupManager to defer the session creation message until the request is complete 2. Then simply swap out the ReplicationValve with an implementation that makes sense Filip On 01/12/2010 11:42 AM, Robin Wilson wrote: REPOSTING this so it won't be on the other thread - sorry about that. Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
This is more-or-less what we've done. It seems to work for our situation. We've added some variables to the DeltaManager config, so we can control the behavior as well. We can now set the minimum threshold for a session duration, where sessions less than this threshold will not get replicated in any case. (From my perspective, this just makes sense - if the session duration is small enough, and your system is busy enough - replicating make introduce more delay than the session has to live. For example, in our load testing, we're seeing session replication lagging behind session creation by several seconds. If a given session is shorter than the lag, it would never make sense to replicate it anyway.) -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] Sent: Wednesday, January 13, 2010 2:12 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration The sensible approach would be 1. Refactor DeltaManager and BackupManager to defer the session creation message until the request is complete 2. Then simply swap out the ReplicationValve with an implementation that makes sense Filip On 01/12/2010 11:42 AM, Robin Wilson wrote: REPOSTING this so it won't be on the other thread - sorry about that. Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
On 12/01/2010 16:47, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Robin, please post a new message when starting a new thread. When you reply, even if you edit the subject line content, the In-Reply-To header is still set so, in a threaded email view you have responded to a different thread. (See Thread-hijacking.) p -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
REPOSTING this so it won't be on the other thread - sorry about that. Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine a scenario like this: 0. Your web.xml configures the default session timeout to be 1 second 1. Upon session creation, DeltaManager is notified that a session has been created and will need to be replicated 2. DeltaManager sees that the sessionDurationMinThreshold is only 5s, and so it decides not to replicate that session throughout the cluster 3. Your code (still during the request that created the session) determines that this will be a useful session and changes the timeout, say, to 30 minutes Result: a useful session is never replicated Conversely, the opposite situation could occur if your default timeout is 30 minutes and you intentionally reduce the timeout for sessions expected to be useless: in this case, replication occurs all the time. Beware! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM5B4ACgkQ9CaO5/Lv0PDj5wCfZ4CGx2XZbq+qsFx9/GVK6eCy 6HQAoJvD81ghtJl7L9KGCvKyTXN9LF0j =2nq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Thanks for your response, here are my answers to your questions... In our test environment, we have a 2 server cluster, but our front-end Apache server is only hitting one of them. Regardless of that fact, all sessions created on either server get replicated to the other. So as they are created on the single test path, they get replicated to the second tomcat server. With only 2 cluster members, this isn't really a big deal (except for the load generators being able to create sessions faster than Tomcat can get rid of them). However, in our production environment we have 4 cluster members, so it only takes 1/4 of the load on each server to max out all 4 servers in terms of session creation speed. Keep in mind that during this situation, the _only_ problem we're seeing is that the sessions eventually fill up the heap. Performance remains good until the heap fills up and we start thrashing on Full GCs. (Clearly, more memory will help - by extending the duration we can sustain of peak loads, but a better solution will be to stop creating sessions for stuff that doesn't need it.) Your point is well taken about not creating the short-duration sessions, but alas, Tapestry is the chosen framework - and it uses the session as a mechanism to pass (more-or-less) global values between components of the page creation process. So ripping out that capability in Tapestry would require a massive change to our infrastructure. Your notes on the clustering (changes to DeltaManager) are right on target. So we adjusted when the DeltaManager creates the session until the end of processing, so that we know the timeout before we attempt to replicate it to other cluster members. That way, we already know the actual timeout duration before we decide whether to replicate. All of this would be unnecessary if there was some sort of session cleanup process that could dump expired sessions en masse every so often. Near as we can tell, each session has to be individually expired, which is why it lags so far behind the creation process. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 12, 2010 3:06 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
On 12/01/2010 21:05, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no need to pass them off to the other members of the cluster. One could argue that sessions limited to that length of time are not necessary at all. Why bother creating them in the first place? The question I have, is there anything we should watch out for in making this adjustment to the DeltaManager? We will test this pretty heavily before we deploy it to our production environment, but I'm worried about things we should be looking for in that testing (other than just validating that our useful session data can be available across multiple cluster members). Give some of the cluster gurus on the list a chance to read your question. Feel free to start your implementation: I'm guessing it's a pretty simple change to simply ignore sessions with low timeouts. Depending on how to set up your sessions, you may not be able to prevent the replication (or replication of useful sessions may not occur). I've never looked at the code for the DeltaManager, but I can imagine a scenario like this: 0. Your web.xml configures the default session timeout to be 1 second 1. Upon session creation, DeltaManager is notified that a session has been created and will need to be replicated 2. DeltaManager sees that the sessionDurationMinThreshold is only 5s, and so it decides not to replicate that session throughout the cluster 3. Your code (still during the request that created the session) determines that this will be a useful session and changes the timeout, say, to 30 minutes Result: a useful session is never replicated Conversely, the opposite situation could occur if your default timeout is 30 minutes and you intentionally reduce the timeout for sessions expected to be useless: in this case, replication occurs all the time. Beware! If you can't stop the session from being created, storing a value in the session to indicate whether the session should be replicated might be easier to manage monitor than juggling variable session times. p - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktM5B4ACgkQ9CaO5/Lv0PDj5wCfZ4CGx2XZbq+qsFx9/GVK6eCy 6HQAoJvD81ghtJl7L9KGCvKyTXN9LF0j =2nq7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration
Did you think about a possibility instead of get rid of the session overwriting the manager - getting rid of the data stored in session? If I understand correctly Tapestry needs the session for the page creation time ,which means that you don't need all the data stored there after the page was created (i would call it request context),right? You could _maybe_ do even better - look into Tapestry maybe it's data is marked in some way (i would guess it would ,for example with some prefix in attribute's name). And clean ,this only data ,after each request . I guess you can overwrite the Tomcat's Session (maybe will break the replication) or just configure a filter for this job. This is really simple ,the question is, will Tapestry work if you just throw away it's data after each request. Since I am not a Tapestry Guru i can't say . Hope this helps. Evgeny On Wed, Jan 13, 2010 at 12:19 AM, Robin Wilson rwil...@kingsisle.comwrote: Thanks for your response, here are my answers to your questions... In our test environment, we have a 2 server cluster, but our front-end Apache server is only hitting one of them. Regardless of that fact, all sessions created on either server get replicated to the other. So as they are created on the single test path, they get replicated to the second tomcat server. With only 2 cluster members, this isn't really a big deal (except for the load generators being able to create sessions faster than Tomcat can get rid of them). However, in our production environment we have 4 cluster members, so it only takes 1/4 of the load on each server to max out all 4 servers in terms of session creation speed. Keep in mind that during this situation, the _only_ problem we're seeing is that the sessions eventually fill up the heap. Performance remains good until the heap fills up and we start thrashing on Full GCs. (Clearly, more memory will help - by extending the duration we can sustain of peak loads, but a better solution will be to stop creating sessions for stuff that doesn't need it.) Your point is well taken about not creating the short-duration sessions, but alas, Tapestry is the chosen framework - and it uses the session as a mechanism to pass (more-or-less) global values between components of the page creation process. So ripping out that capability in Tapestry would require a massive change to our infrastructure. Your notes on the clustering (changes to DeltaManager) are right on target. So we adjusted when the DeltaManager creates the session until the end of processing, so that we know the timeout before we attempt to replicate it to other cluster members. That way, we already know the actual timeout duration before we decide whether to replicate. All of this would be unnecessary if there was some sort of session cleanup process that could dump expired sessions en masse every so often. Near as we can tell, each session has to be individually expired, which is why it lags so far behind the creation process. -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 12, 2010 3:06 PM To: Tomcat Users List Subject: Re: More on Tomcat Sessions - limiting cluster session replication to sessions that will last longer than 'n' duration -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin, On 1/12/2010 1:42 PM, Robin Wilson wrote: Earlier this week I posted a question about how to prevent sessions from being created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch of '1-second' sessions we're creating during a load test because the sessions eventually fill up the heap. (They are being created faster than Tomcat can clean them out - even though they expire faster than we create them.) Well, they are eligible for expiration faster than they are being created. That session expiration thread can't be running /all/ the time :) So, my lead developer thinks he has found a way to alleviate our problems (at least for our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to other cluster members unless they have a duration longer than a 'threshold' we set. Aah... I didn't realize that you were experiencing a session replication storm in your test setup. I thought you were only using a single app server for load testing. Did I misunderstand? We are altering the DeltaManager to make this change, so that simply creating a session doesn't automatically guarantee that it is replicated to other nodes in the cluster. The session duration will also have to be greater than a sessionDurationMinThreshold value we will set in the 'server.xml' file for the new DeltaManager. The idea is that sessions created that have very short durations are really 'transient' anyway, so there is no
