Adam
Wow - 2.8 million sessions, kudos. Your usage sounds higher than most of
us hence why this hasn't plagued more of us sooner.
It looks like there is already a JIRA issue for this:
https://issues.apache.org/jira/browse/FELIX-2687
There is a patch mentioned, but I couldn't actually see it or vouch for
it's provenance.
I'll add your comments to it, might help jog some memories. If I get a
gap in my project work I may take a look and see if it's a quickie to do.
Regards
-- Rob Walker
On 06/10/2011 11:16 PM, McKenzie, Adam wrote:
Hi Everyone,
I am having a problem in my application that too many sessions are remaining
open instead of closing after turning inactive when using the Jetty
HttpService. This eventually leads to the application grounding to a halt after
~2.8 million sessions are made. I have manually set the maxInactiveInterval on
one of the HttpServletRequests REST endpoints to a short period and have
verified that if I create 10,000 requests the sessions are disposed of
properly. Fixing it this manual way seems like a bad solution considering there
is at least 200 places where requests are handled and this number will increase
over time creating a risk of forgetting to set the default timeout value.
Based upon this former email on the mailing list
(http://www.mail-archive.com/[email protected]/msg19839.html) and the lack
of the configuration property in the documentation
(http://felix.apache.org/site/apache-felix-http-service.html) I assume there is
no way to set this value in a configuration file similar to web.xml? Is there a
way that I can from a HttpServletRequest get access to the SessionManager or
some other object that will enable me to set a default timeout value for all
sessions? I also don't see a way to do this by grabbing the HttpService during
a bundle activation through the context.
Thanks!
Adam McKenzie
ITS, University of Saskatchewan
Rm 61 Physics, 116 Science Place
Saskatoon SK S7N 5E2 Canada
(306) 966-2453
--
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
