why would that help? 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] > >