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
