Johan Compagner wrote:
why would that help?
Did'nt state it would, was just currious..
the first finally block is on the RequestCycle that only lives in 1 thread
and has all the state in one thread.
the second (in wicket filter) does only reset thread locals which are single
threaded by nature.
I did see one thing that could go wrong
we also call Response.close() and if that one some how fails, this could
happen i think in maybe certain situations
then the thread locals are not reset
I fixed that with an extra try catch block
johan
On Wed, Apr 9, 2008 at 1:53 PM, Nino Saturnino Martinez Vazquez Wael <
[EMAIL PROTECTED]> wrote:
Do you synchronize those final blocks?
Johan Compagner wrote:
could you change that method that it checks this after the fact?
and then see if there is an error for that thread before? for example
also
log the url call so that we can see
what kind of request did let one thread local be there?
Which one is it by the way?
is it app, session or request cycle?
i just checked our code and we have finally blocks pretty much every
where
in WicketFilter.doGet
and in RequestCycle.steps
And i have no idea how those can be jumped over.
johan
On Wed, Apr 9, 2008 at 12:22 PM, Niels Bo <[EMAIL PROTECTED]>
wrote:
We have kind of the same problem.
It looks like Application and Session are not always cleared from the
request thread, and to test this I have just deployed a subclassed
WicketServlet with these checks (and also as a workaround):
protected void service(HttpServletRequest req, HttpServletResponse
resp)
throws ServletException, IOException {
if(Application.exists()) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
"Application on Thread");
Application.unset();
}
if(Session.exists()) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
"Session on Thread");
Session.unset();
}
if(RequestCycle.get() != null) {
LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED,
"RequestCycle on Thread");
RequestCycle.get().detach();
}
super.service(req, resp); // call WicketServlet
}
Our logs show that it actually happens that both Application and
Session
are
already attached to the thread before the request is processed.
I have only seen it once or twice in our development environment, but
it
happens a few times every hour on the production server.
Niels
--
View this message in context:
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16583880.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
