You can simply run the app using the maven tomcat7 plugin mvn clean tomcat7:run
I have extended the WebBeansConfigurationListener. It is a MBean, so you can inspect the size of the SessionContextManager's map and print out it's key set (e. g. by using jconsole). I also extended the log statements, including the original session id in the log statement of the sessionDestroyed() method.
After a login (manager/manager) and logout to the app, there are still 3 entries left in the map.
Am 07.03.2015 um 15:54 schrieb Mark Struberg:
yes, probably the best short term solution is to switch to tomee until we get this fixed in the owb tomcat integration. TomEE contains OWB in pretty much the latest version. LieGrue, strubAm 07.03.2015 um 12:49 schrieb Romain Manni-Bucau <[email protected]>: From the phone - so sorry to be too concise - but in tomee we had this issue and used update session id feature to fix it Le 7 mars 2015 11:47, "Mark Struberg" <[email protected]> a écrit : Which version of owb are you using? 1.2.x or 1.5.x snapshot? I might totally rework all our session handling in the current trunk. We will ship a release in the next few weeks. LieGrue, strubAm 06.03.2015 um 13:42 schrieb Sebastian Gebhardt <[email protected]>: Hi Mark! I added the WebBeansConfigurationListener to the web.xml and also use the openwebbeans-tomcat7 plugin. The tomcat parameter changeSessionIdOnAuthentication is not explicitly changed, so the default value true should be active. My starting point was a heap dump resulting from an OutOfMemoryError of the application. Inspecting the dump, I noticed the sessionContexts Map of the SessionContextManager. The map was about 2,5 GB. During my debugging sessions I detected two WebBeansConfigurationListener.sessionCreated() calls for a login. The second call only creates a copy of the first one (attributes are the same of the first session). But I never expected a WebBeansConfigurationListener.sessionDestroyed() call for the first session. Thanks Am 06.03.2015 um 13:19 schrieb Mark Struberg:Hi Sebastian! I think it should all work out of the box. How did you setup OWB in tomcat? Are you using the webbeans-tomcat7 + context.xml or are you simply adding the WebBeansConfigurationListener in your web.xml? In any case, please debug into WebBeansConfigurationListener#sessionDestroyed(). (You can also debug into sessionCreated() to be sure the listener is properly registered). This is a standard HttpSessionListener and must get invoked by the container. What tomcat feature do you use to force a new sessionId? changeSessionIdOnAuthentication ? Maybe we need to add support for those or provide a better mapping. If you give me a few hints how your application looks like in regards to session handling then I’ll investigate it. We are short before a release anyway. LieGrue, strubAm 06.03.2015 um 12:54 schrieb Sebastian Gebhardt <[email protected]>: Hello! My application uses owb and runs in a tomcat 7. The user are authenticated by the container. During the authentication the session id changes (to prevent session fixation attacks). This leads to a second call to SessionContextManager.addNewSessionContext(). But the SessionContext created in the first call is never destroyed/removed. So the SessionContextManager's map of session contexts grows. Finally this leads to an OutOfMemoryException. Is there something I have misconfigured? Thanks!-- Sebastian Gebhardt Email: [email protected] PGP-Public Key: http://www.bfeater.de/bfeater_pubkey.asc
-- Sebastian Gebhardt Email: [email protected] PGP-Public Key: http://www.bfeater.de/bfeater_pubkey.asc
outofmemerror.tar.gz
Description: application/gzip
