Re: [5.0] Removing session recycling code
I agree that session recycling can be a security problem but am concerned that removing recycling will significantly increase GC overhead. I would like to see some before and after GC data from testing where 1000's of sessions get used per hour. Testing with different versions of the JVM would be needed since GC performance varies a great deal between JVM's. Regards, Glenn Remy Maucherat wrote: Hi, I'd like to completely remove session recycling code from TC 5, as it is a potentially dangerous feature (which has been disabled in TC 4.1.x) and does not bring any actual performance improvement while using memory. The biggest impact of the change is the removal of the recycled array list for base manager, which can break existing TC 4 managers. OTOH, using that is unsafe, and fixing an affected manager is very easy (just remove whatever recylcling code was used). I plan to keep Session.recycle around (nulling out references can help GC, esp since there could be a lot of session objects - with all their children - waiting to be GCed). Comments ? Remy - 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]
[5.0] Removing session recycling code
Hi, I'd like to completely remove session recycling code from TC 5, as it is a potentially dangerous feature (which has been disabled in TC 4.1.x) and does not bring any actual performance improvement while using memory. The biggest impact of the change is the removal of the recycled array list for base manager, which can break existing TC 4 managers. OTOH, using that is unsafe, and fixing an affected manager is very easy (just remove whatever recylcling code was used). I plan to keep Session.recycle around (nulling out references can help GC, esp since there could be a lot of session objects - with all their children - waiting to be GCed). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Removing session recycling code
I'd like to completely remove session recycling code from TC 5, as it is a potentially dangerous feature (which has been disabled in TC 4.1.x) and does not bring any actual performance improvement while using memory. The biggest impact of the change is the removal of the recycled array list for base manager, which can break existing TC 4 managers. OTOH, using that is unsafe, and fixing an affected manager is very easy (just remove whatever recylcling code was used). I plan to keep Session.recycle around (nulling out references can help GC, esp since there could be a lot of session objects - with all their children - waiting to be GCed). Comments ? If it can't be used safely at all my gut instinct would be to remove it to prevent something from blowing up in peoples faces. It also sounds like a performance enhancement which has gone wrong, so it's a prime candidate for removal in my opinion. (But then what do I know :) erm +1 is it? Kev -- To be governed is to be watched over, inspected, spied on, directed, legislated... - Pierre-Joseph Proudhon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Removing session recycling code
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, July 07, 2003 2:54 PM Subject: [5.0] Removing session recycling code Hi, I'd like to completely remove session recycling code from TC 5, as it is a potentially dangerous feature (which has been disabled in TC 4.1.x) and does not bring any actual performance improvement while using memory. The biggest impact of the change is the removal of the recycled array list for base manager, which can break existing TC 4 managers. OTOH, using that is unsafe, and fixing an affected manager is very easy (just remove whatever recylcling code was used). I plan to keep Session.recycle around (nulling out references can help GC, esp since there could be a lot of session objects - with all their children - waiting to be GCed). Comments ? Having put so much work into getting the session recycling code working in 3.3, I'm +1 for not seeing that headache again ;-). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Removing session recycling code
+1 The session is a long-lived object, so the improvement on recycling is minor. Costin Remy Maucherat wrote: Hi, I'd like to completely remove session recycling code from TC 5, as it is a potentially dangerous feature (which has been disabled in TC 4.1.x) and does not bring any actual performance improvement while using memory. The biggest impact of the change is the removal of the recycled array list for base manager, which can break existing TC 4 managers. OTOH, using that is unsafe, and fixing an affected manager is very easy (just remove whatever recylcling code was used). I plan to keep Session.recycle around (nulling out references can help GC, esp since there could be a lot of session objects - with all their children - waiting to be GCed). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
