-
Bug
-
Resolution: Fixed
-
Blocker
-
None
-
Hudson 1.337 (Winstone), Solaris 10 SPARC, Sun JDK 1.6.0_16
We are running Hudson with its embedded Winstone servlet engine. User authentication within Hudson is done via Hudsons LDAP security realm using our corporate ActiveDirectory via LDAP.
After running Hudson a few weeks we're running into OutOfMemory exceptions. Here the culprit is a single winstone.WebAppConfiguration instance holding a lot of winstone.WinStoneSession instances each holding an Acegi RememberMeAuthenticationToken instance with 36k data from the authenticated users AD record.
It seems that Hudson isn't setting Winstones session timeout. Without specifying a session timeout winstone.WebAppConfiguration.makeNewSession() is using a session timeout of -1.
- is related to
-
JENKINS-4512 Hudson consumes 100% CPU
-
- Resolved
-
[JENKINS-5119] Winstone: Memory leak due to default session timeout of -1
Description |
Original:
We are running Hudson with its embedded Winstone servlet engine. User authentication within Hudson is done via Hudsons LDAP security realm using our corporate ActiveDirectory via LDAP. After running Hudson a few weeks we're running into OutOfMemory exceptions. Here the culprit is a single {{winstone.WebAppConfiguration}} instance holding a lot of {{winstone.WinStoneSession}} instances each holding an Acegi {{RememberMeAuthenticationToken}} instance with 36k data from the authenticated users AD record. It seems that Hudson isn't setting Winstones session timeout. Without specifying a session timeout {{winstone.WebAppConfiguration.makeNewSession()}} is using a session timeout of -1 via {{ws.setMaxInactiveInterval(-1)}}. Btw. who is responsible for calling {{winstone.WebAppConfiguration.invalidateExpiredSessions()}}? |
New:
We are running Hudson with its embedded Winstone servlet engine. User authentication within Hudson is done via Hudsons LDAP security realm using our corporate ActiveDirectory via LDAP. After running Hudson a few weeks we're running into OutOfMemory exceptions. Here the culprit is a single {{winstone.WebAppConfiguration}} instance holding a lot of {{winstone.WinStoneSession}} instances each holding an Acegi {{RememberMeAuthenticationToken}} instance with 36k data from the authenticated users AD record. It seems that Hudson isn't setting Winstones session timeout. Without specifying a session timeout {{winstone.WebAppConfiguration.makeNewSession()}} is using a session timeout of -1. |
Attachment | New: VisualVM 1.2.2 4192010 12616 PM.jpg [ 19349 ] |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
Link |
New:
This issue is related to |
Workflow | Original: JNJira [ 135203 ] | New: JNJira + In-Review [ 203329 ] |