txs a lot, will check it out! LieGrue, strub
> Am 10.03.2015 um 08:12 schrieb Sebastian Gebhardt > <[email protected]>: > > The hint to TomEE was excellent. I adopted the solution, see issue OWB-1041. > Thanks a lot > > Am 09.03.2015 um 08:49 schrieb Sebastian Gebhardt: >> I am using owb version 1.2.6. Yesterday I created a minimal example >> demonstrating my problem. It is attached. >> >> 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, >>> strub >>> >>>> Am 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, >>>> strub >>>> >>>> >>>>> Am 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, >>>>>> strub >>>>>> >>>>>> >>>>>>> Am 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
