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]
>
>
