Hi,
it seems that all the HTTP plugins (presence and userservice) are generating memory leaks. Launching a profiler (JProfiler) it reports a new instance of the serlvet every HTTP request get by Jetty.
Has anybody experienced the same?
Mirko
is this an actual leak or just normal behavior? GC will eventually come along and free-up any refrenced objects that are no longer in scope…
I’ve found the problem and it’s a session leak. A session is created every HTTP request (actually don’t know who is doing that)and never invalidated. I’ve also checked the default settings and I’ve found no session timeout conf. So it seems that sessions for plugins are never cleaned. As far as they are stateless plugins it would be better to invalidate the session right before the doGet/doPost return.
I’ve modfiied both Presence and userService plugin and now they’re no more reporting memory problems after load tests.
Please consider providing a patch.
I went deep and found out that there’s no session timeout set for jetty and the default is -1 (not sure…). So, as sessions never expires and there’s no expicit invalidation HTTP sessions live forever (tested with JProfiler).
I’ve also tested calling login.jsp with curl. It generates a session that never expires. The problem seems to be wider than a plugin problem.
The fix could be simply adding a session-timeout configuration to 30 or adding a maxinactiveinterval to some value just after session creation.
What do you think?
Hi all,
I’ve double checked and I found out that sessions time out in 30 mins. Now, after 30 mins the sessions are invalidated but i think it should be better for those stateless plugins to invalidate the session just after the request.
What do you think?
perhaps… but if it requires plugins to do something special, then it likely won’t get done (lazy coders, we all are. )… Instead, if this is necessary, then it should get handled by the core program via some sort of session manager object imho. I don’t know the openfire codebase, so not sure what can be done.
Id say give it a go, test it out locally by compiling openfire with your changes, and run it for a while to see if the issue is fixed, and if stability is not compromised. if it all looks good, post a patch and it will be reviewed