subject:"Invoulentary session sharing\/leakage in Wicket 1.3.x"

I know all that, but i dont know how this could happen in wicket. I
think it is user code because if you have a bufferedresponse that has
a string buffer filled then it is very strange that the output stream
is already used, i am very curios how both can be used by wicket in
the same request, wicket only uses outputstream itself for resources
and a redirect to buffer (the actual redirect) the last part this
really cant happen because there shouldnt be anything in the response.

The first part cant also happen because we dont render a page or
something if a resource request target is the response target..

So it seems to me that that it is usercode that writes directly to the
stream and let wicket still do something


On 5/5/08, lars vonk <[EMAIL PROTECTED]> wrote:
> Hi Johan,
>
> This exception occurs if you obtained the servletresponse via the
> ServletResponse.getOutputStream() and are *trying *to obtained the writer
> via ServletResponse.getWriter() at the same time. According to the javadoc
> of ServletRespone you can either use getOutputStream or getWriter to write
> the body:
>
> Either this method or [EMAIL PROTECTED] #getOutputStream} may be called to 
> write the
> > body, not both.
> >
>
> Jetty tracks this using an inner flag. This flag is only reset on the
> ServletResponse.reset()  method, which I believe is called at the end of the
> servletrequestcycle.
>
> If I look at Wicket's the WebResponse class I see several
> ServletResponse.getWriter *and* ServletResponse.getOutputStream calls. You
> can't mix those two when writing the servletresponse.
>
> Maybe this helps with tracking where it goes wrong.
>
> Cheers Lars
>
> PS. The exception would have been IllegalStateException("WRITER') if you
> obtained the ServletResponse.getWriter() and are *trying* to obtain the
> ServletResponse.getOutputStream at the same time.
>
> On Mon, May 5, 2008 at 4:39 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
>
> > it was really a pretty rare exception
> >
> > 285154 [btpool0-9] ERROR org.mortbay.log - /undefined
> > java.lang.IllegalStateException: STREAM
> >   at org.mortbay.jetty.Response.getWriter(Response.java:585)
> >   at
> > org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:355)
> >   at org.apache.wicket.protocol.http.BufferedWebResponse.close
> > (BufferedWebResponse.java:73)
> >   at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter
> > .java:371)
> >   at
> > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter
> > .java:194)
> >   at
> >
> >
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
> >
> > i have no idea how this exception can happen.
> > It seems that there is already streamed something but then close does find
> > also some stuff and wants to write it..
> >
> > That did result in an exception on close() so the unset wasnt called.
> >
> > johan
> >
> >
> >
> > On Mon, May 5, 2008 at 3:34 PM, Erik van Oosten <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Isn't this problem serious enough to release 1.3.4?
> > >
> > > Regards,
> > >Erik.
> > >
> > >
> > > Johan Compagner wrote:
> > > > the only thing we found was the finalize block that could be skipped
> > > because
> > > > of an exception again in that block
> > > >
> > > > That is fixed in current 1.3.x branch (and 1.4)
> > > >
> > > >
> > >
> > > --
> > > Erik van Oosten
> > > http://day-to-day-stuff.blogspot.com/
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread lars vonk

Hi Johan,

This exception occurs if you obtained the servletresponse via the
ServletResponse.getOutputStream() and are *trying *to obtained the writer
via ServletResponse.getWriter() at the same time. According to the javadoc
of ServletRespone you can either use getOutputStream or getWriter to write
the body:

Either this method or [EMAIL PROTECTED] #getOutputStream} may be called to 
write the
> body, not both.
>

Jetty tracks this using an inner flag. This flag is only reset on the
ServletResponse.reset()  method, which I believe is called at the end of the
servletrequestcycle.

If I look at Wicket's the WebResponse class I see several
ServletResponse.getWriter *and* ServletResponse.getOutputStream calls. You
can't mix those two when writing the servletresponse.

Maybe this helps with tracking where it goes wrong.

Cheers Lars

PS. The exception would have been IllegalStateException("WRITER') if you
obtained the ServletResponse.getWriter() and are *trying* to obtain the
ServletResponse.getOutputStream at the same time.

On Mon, May 5, 2008 at 4:39 PM, Johan Compagner <[EMAIL PROTECTED]>
wrote:

> it was really a pretty rare exception
>
> 285154 [btpool0-9] ERROR org.mortbay.log - /undefined
> java.lang.IllegalStateException: STREAM
>   at org.mortbay.jetty.Response.getWriter(Response.java:585)
>   at
> org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:355)
>   at org.apache.wicket.protocol.http.BufferedWebResponse.close
> (BufferedWebResponse.java:73)
>   at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter
> .java:371)
>   at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter
> .java:194)
>   at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
>
> i have no idea how this exception can happen.
> It seems that there is already streamed something but then close does find
> also some stuff and wants to write it..
>
> That did result in an exception on close() so the unset wasnt called.
>
> johan
>
>
>
> On Mon, May 5, 2008 at 3:34 PM, Erik van Oosten <[EMAIL PROTECTED]>
> wrote:
>
> > Isn't this problem serious enough to release 1.3.4?
> >
> > Regards,
> >Erik.
> >
> >
> > Johan Compagner wrote:
> > > the only thing we found was the finalize block that could be skipped
> > because
> > > of an exception again in that block
> > >
> > > That is fixed in current 1.3.x branch (and 1.4)
> > >
> > >
> >
> > --
> > Erik van Oosten
> > http://day-to-day-stuff.blogspot.com/
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread Eelco Hillenius

On Mon, May 5, 2008 at 8:20 AM, Iman Rahmatizadeh
<[EMAIL PROTECTED]> wrote:
> I'm also experiencing this with jetty. Is everybody else the same ?

It would be great if we would have this reproducible as a test case or
something. I created wicket-threadtest in the past because we needed
to reproduce similar problems. If someone would pick up writing a
similar test (or even a patch on wicket-threadtest), we'd be more
certain that once we found the problem we fix it properly.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread Iman Rahmatizadeh

I'm also experiencing this with jetty. Is everybody else the same ?

Iman

On Mon, May 5, 2008 at 6:09 PM, Johan Compagner <[EMAIL PROTECTED]>
wrote:

> it was really a pretty rare exception
>
> 285154 [btpool0-9] ERROR org.mortbay.log - /undefined
> java.lang.IllegalStateException: STREAM
>   at org.mortbay.jetty.Response.getWriter(Response.java:585)
>   at
> org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:355)
>   at org.apache.wicket.protocol.http.BufferedWebResponse.close
> (BufferedWebResponse.java:73)
>   at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter
> .java:371)
>   at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter
> .java:194)
>   at
>
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
>
> i have no idea how this exception can happen.
> It seems that there is already streamed something but then close does find
> also some stuff and wants to write it..
>
> That did result in an exception on close() so the unset wasnt called.
>
> johan
>
>
>
> On Mon, May 5, 2008 at 3:34 PM, Erik van Oosten <[EMAIL PROTECTED]>
> wrote:
>
> > Isn't this problem serious enough to release 1.3.4?
> >
> > Regards,
> >Erik.
> >
> >
> > Johan Compagner wrote:
> > > the only thing we found was the finalize block that could be skipped
> > because
> > > of an exception again in that block
> > >
> > > That is fixed in current 1.3.x branch (and 1.4)
> > >
> > >
> >
> > --
> > Erik van Oosten
> > http://day-to-day-stuff.blogspot.com/
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

it was really a pretty rare exception

285154 [btpool0-9] ERROR org.mortbay.log - /undefined
java.lang.IllegalStateException: STREAM
   at org.mortbay.jetty.Response.getWriter(Response.java:585)
   at
org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:355)
   at org.apache.wicket.protocol.http.BufferedWebResponse.close
(BufferedWebResponse.java:73)
   at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter
.java:371)
   at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter
.java:194)
   at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)

i have no idea how this exception can happen.
It seems that there is already streamed something but then close does find
also some stuff and wants to write it..

That did result in an exception on close() so the unset wasnt called.

johan



On Mon, May 5, 2008 at 3:34 PM, Erik van Oosten <[EMAIL PROTECTED]>
wrote:

> Isn't this problem serious enough to release 1.3.4?
>
> Regards,
>Erik.
>
>
> Johan Compagner wrote:
> > the only thing we found was the finalize block that could be skipped
> because
> > of an exception again in that block
> >
> > That is fixed in current 1.3.x branch (and 1.4)
> >
> >
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread Martijn Dashorst

On 5/5/08, Erik van Oosten <[EMAIL PROTECTED]> wrote:
> Isn't this problem serious enough to release 1.3.4?

The core developers have not found any problems with 1.3.1, 1.3.2,
1.3.3 on their production boxes. There is no evidence this solves the
problem, so IMO there is no need to release 1.3.4 immediately.

Martijn

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread Erik van Oosten

Isn't this problem serious enough to release 1.3.4?

Regards,
Erik.


Johan Compagner wrote:
> the only thing we found was the finalize block that could be skipped because
> of an exception again in that block
>
> That is fixed in current 1.3.x branch (and 1.4)
>
>   

--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

we (matej) tested there solution locally but couldnt reproduce it at all

johan

On Mon, May 5, 2008 at 1:58 PM, lars vonk <[EMAIL PROTECTED]> wrote:

> But did it fix Edvin Syse his problem? The last thing he reported was that
> his problem still persists.
>
> I see this problem 10-20 times every day still..
> >
> > -- Edvin
> >
>
>
> Lars
>
> On Mon, May 5, 2008 at 1:41 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
>
> > the only thing we found was the finalize block that could be skipped
> > because
> > of an exception again in that block
> >
> > That is fixed in current 1.3.x branch (and 1.4)
> >
> > On Mon, May 5, 2008 at 12:32 PM, Leena <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > What was the resolution? I am facing the same problem in my
> > > application...using wicket 1.3.1.
> > > Is it a problem in Wicket? If so, is there any workaround?
> > >
> > > +Leena
> > >
> > >
> > > Edvin Syse wrote:
> > > >
> > > > The problem is still there and now it is getting serious for my
> > > business.
> > > > Would any of the core committers be willing to look at my
> > > > application? I'll pay USD 2500 as a onetime fee for looking at
> this..
> > > (Or
> > > > name your hour-price)
> > > >
> > > > -- Edvin
> > > >
> > > >
> -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p17057591.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]
> > >
> > >
> >
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread lars vonk

But did it fix Edvin Syse his problem? The last thing he reported was that
his problem still persists.

I see this problem 10-20 times every day still..
>
> -- Edvin
>


Lars

On Mon, May 5, 2008 at 1:41 PM, Johan Compagner <[EMAIL PROTECTED]>
wrote:

> the only thing we found was the finalize block that could be skipped
> because
> of an exception again in that block
>
> That is fixed in current 1.3.x branch (and 1.4)
>
> On Mon, May 5, 2008 at 12:32 PM, Leena <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > What was the resolution? I am facing the same problem in my
> > application...using wicket 1.3.1.
> > Is it a problem in Wicket? If so, is there any workaround?
> >
> > +Leena
> >
> >
> > Edvin Syse wrote:
> > >
> > > The problem is still there and now it is getting serious for my
> > business.
> > > Would any of the core committers be willing to look at my
> > > application? I'll pay USD 2500 as a onetime fee for looking at this..
> > (Or
> > > name your hour-price)
> > >
> > > -- Edvin
> > >
> > > -----
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p17057591.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]
> >
> >
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

the only thing we found was the finalize block that could be skipped because
of an exception again in that block

That is fixed in current 1.3.x branch (and 1.4)

On Mon, May 5, 2008 at 12:32 PM, Leena <[EMAIL PROTECTED]> wrote:

>
>
> What was the resolution? I am facing the same problem in my
> application...using wicket 1.3.1.
> Is it a problem in Wicket? If so, is there any workaround?
>
> +Leena
>
>
> Edvin Syse wrote:
> >
> > The problem is still there and now it is getting serious for my
> business.
> > Would any of the core committers be willing to look at my
> > application? I'll pay USD 2500 as a onetime fee for looking at this..
> (Or
> > name your hour-price)
> >
> > -- Edvin
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p17057591.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]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-05-05 Thread Leena



What was the resolution? I am facing the same problem in my
application...using wicket 1.3.1.
Is it a problem in Wicket? If so, is there any workaround?

+Leena


Edvin Syse wrote:
> 
> The problem is still there and now it is getting serious for my business.
> Would any of the core committers be willing to look at my 
> application? I'll pay USD 2500 as a onetime fee for looking at this.. (Or
> name your hour-price)
> 
> -- Edvin
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p17057591.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-17 Thread Igor Vaynberg

yes, well. hopefully for 1.5 we consolidate all these into just one
threadlocal, and one try/finally in filter should take care of this
mess for good.

-igor

On Thu, Apr 17, 2008 at 12:28 AM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> in some i seen parts of it in one or 2 mails
>  But maybe those are not logged somehow or looked over i dont know
>
>  johan
>
>
>
>  On Thu, Apr 17, 2008 at 9:18 AM, Igor Vaynberg <[EMAIL PROTECTED]>
>
>
> wrote:
>
>  > but if that was indeed what was happening to him wouldnt there be
>  > stack traces in the log?
>  >
>  > -igor
>  >
>  >
>  > On Wed, Apr 16, 2008 at 11:55 PM, Johan Compagner <[EMAIL PROTECTED]>
>  > wrote:
>  > > 1 of our finally blocks calls first a response.close() without
>  > >  try/catch around that and then unset the threadlocals, i think the
>  > >  response.close does somehow in some situations throws an exception, i
>  > >  dont know which one but i build a try catch around it.
>  > >
>  > >
>  > >
>  > >  On 4/17/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>  > >  > we dont even know if it is something in wicket that is causing this
>  > >  > yet...johan what exactly did you find out?
>  > >  >
>  > >  > -igor
>  > >  >
>  > >  >
>  > >  > On Wed, Apr 16, 2008 at 4:34 PM, Ned Collyer <[EMAIL PROTECTED]>
>  > wrote:
>  > >  > >
>  > >  > >
>  > >  > >  Edvin Syse wrote:
>  > >  > >  >
>  > >  > >  > No, it has not. Johan said he fixed a bug that might have been
>  > this
>  > >  > >  > problem, but I haven't been able to confirm it yet, as the fix
>  > is in
>  > >  > >  > 1.3-SNAPSHOT, and I ran into some issues when deploying with the
>  > >  > >  > snapshot-version.
>  > >  > >  >
>  > >  > >  > I see this problem 10-20 times every day still..
>  > >  > >  >
>  > >  > >  > -- Edvin
>  > >  > >  >
>  > >  > >
>  > >  > >  I hope we see a non snapshot release soon.  This sounds like a
>  > doozy of a
>  > >  > >  bug - show stopper for everyone!
>  > >  > >  --
>  > >  > >  View this message in context:
>  > >  >
>  > 
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]
>  > >  > >
>  > >  > >
>  > >  >
>  > >  > -
>  > >  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > >  > For additional commands, e-mail: [EMAIL PROTECTED]
>  > >  >
>  > >  >
>  > >
>  > >  -
>  > >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > >  For additional commands, e-mail: [EMAIL PROTECTED]
>  > >
>  > >
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-17 Thread Johan Compagner

in some i seen parts of it in one or 2 mails
But maybe those are not logged somehow or looked over i dont know

johan



On Thu, Apr 17, 2008 at 9:18 AM, Igor Vaynberg <[EMAIL PROTECTED]>
wrote:

> but if that was indeed what was happening to him wouldnt there be
> stack traces in the log?
>
> -igor
>
>
> On Wed, Apr 16, 2008 at 11:55 PM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> > 1 of our finally blocks calls first a response.close() without
> >  try/catch around that and then unset the threadlocals, i think the
> >  response.close does somehow in some situations throws an exception, i
> >  dont know which one but i build a try catch around it.
> >
> >
> >
> >  On 4/17/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >  > we dont even know if it is something in wicket that is causing this
> >  > yet...johan what exactly did you find out?
> >  >
> >  > -igor
> >  >
> >  >
> >  > On Wed, Apr 16, 2008 at 4:34 PM, Ned Collyer <[EMAIL PROTECTED]>
> wrote:
> >  > >
> >  > >
> >  > >  Edvin Syse wrote:
> >  > >  >
> >  > >  > No, it has not. Johan said he fixed a bug that might have been
> this
> >  > >  > problem, but I haven't been able to confirm it yet, as the fix
> is in
> >  > >  > 1.3-SNAPSHOT, and I ran into some issues when deploying with the
> >  > >  > snapshot-version.
> >  > >  >
> >  > >  > I see this problem 10-20 times every day still..
> >  > >  >
> >  > >  > -- Edvin
> >  > >  >
> >  > >
> >  > >  I hope we see a non snapshot release soon.  This sounds like a
> doozy of a
> >  > >  bug - show stopper for everyone!
> >  > >  --
> >  > >  View this message in context:
> >  >
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]
> >  > >
> >  > >
> >  >
> >  > -
> >  > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  > For additional commands, e-mail: [EMAIL PROTECTED]
> >  >
> >  >
> >
> >  -
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-17 Thread Igor Vaynberg

but if that was indeed what was happening to him wouldnt there be
stack traces in the log?

-igor


On Wed, Apr 16, 2008 at 11:55 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> 1 of our finally blocks calls first a response.close() without
>  try/catch around that and then unset the threadlocals, i think the
>  response.close does somehow in some situations throws an exception, i
>  dont know which one but i build a try catch around it.
>
>
>
>  On 4/17/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>  > we dont even know if it is something in wicket that is causing this
>  > yet...johan what exactly did you find out?
>  >
>  > -igor
>  >
>  >
>  > On Wed, Apr 16, 2008 at 4:34 PM, Ned Collyer <[EMAIL PROTECTED]> wrote:
>  > >
>  > >
>  > >  Edvin Syse wrote:
>  > >  >
>  > >  > No, it has not. Johan said he fixed a bug that might have been this
>  > >  > problem, but I haven't been able to confirm it yet, as the fix is in
>  > >  > 1.3-SNAPSHOT, and I ran into some issues when deploying with the
>  > >  > snapshot-version.
>  > >  >
>  > >  > I see this problem 10-20 times every day still..
>  > >  >
>  > >  > -- Edvin
>  > >  >
>  > >
>  > >  I hope we see a non snapshot release soon.  This sounds like a doozy of 
> a
>  > >  bug - show stopper for everyone!
>  > >  --
>  > >  View this message in context:
>  > 
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]
>  > >
>  > >
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread Johan Compagner

What where those issues again? There isnt that many things changed as
far a i know so it would be nice to see whats wrong for you with the
snapshot so that we can look at this before a release

On 4/16/08, Edvin Syse <[EMAIL PROTECTED]> wrote:
> No, it has not. Johan said he fixed a bug that might have been this problem,
> but I haven't been able to confirm it yet, as the fix is in
> 1.3-SNAPSHOT, and I ran into some issues when deploying with the
> snapshot-version.
>
> I see this problem 10-20 times every day still..
>
> -- Edvin
>
> StephenP skrev:
> > Has a JIRA issue been created to track this fix?
> >
> > Thanks,
> > Stephen
> >
> >
> >
> >
> > Yes, it seems to be an error in Wicket.
> > Johan says it should be fixed it in the latest shapshot version, but I
> have
> > not tried it yet.
> >
> > But I will probably keep the workaround code as an extra protection.
> >
> > Niels
> >
> > Anything new on this issue?
> >
> > /Gwyn
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread Johan Compagner

1 of our finally blocks calls first a response.close() without
try/catch around that and then unset the threadlocals, i think the
response.close does somehow in some situations throws an exception, i
dont know which one but i build a try catch around it.

On 4/17/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> we dont even know if it is something in wicket that is causing this
> yet...johan what exactly did you find out?
>
> -igor
>
>
> On Wed, Apr 16, 2008 at 4:34 PM, Ned Collyer <[EMAIL PROTECTED]> wrote:
> >
> >
> >  Edvin Syse wrote:
> >  >
> >  > No, it has not. Johan said he fixed a bug that might have been this
> >  > problem, but I haven't been able to confirm it yet, as the fix is in
> >  > 1.3-SNAPSHOT, and I ran into some issues when deploying with the
> >  > snapshot-version.
> >  >
> >  > I see this problem 10-20 times every day still..
> >  >
> >  > -- Edvin
> >  >
> >
> >  I hope we see a non snapshot release soon.  This sounds like a doozy of a
> >  bug - show stopper for everyone!
> >  --
> >  View this message in context:
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread Igor Vaynberg

we dont even know if it is something in wicket that is causing this
yet...johan what exactly did you find out?

-igor


On Wed, Apr 16, 2008 at 4:34 PM, Ned Collyer <[EMAIL PROTECTED]> wrote:
>
>
>  Edvin Syse wrote:
>  >
>  > No, it has not. Johan said he fixed a bug that might have been this
>  > problem, but I haven't been able to confirm it yet, as the fix is in
>  > 1.3-SNAPSHOT, and I ran into some issues when deploying with the
>  > snapshot-version.
>  >
>  > I see this problem 10-20 times every day still..
>  >
>  > -- Edvin
>  >
>
>  I hope we see a non snapshot release soon.  This sounds like a doozy of a
>  bug - show stopper for everyone!
>  --
>  View this message in context: 
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread Ned Collyer



Edvin Syse wrote:
> 
> No, it has not. Johan said he fixed a bug that might have been this
> problem, but I haven't been able to confirm it yet, as the fix is in 
> 1.3-SNAPSHOT, and I ran into some issues when deploying with the
> snapshot-version.
> 
> I see this problem 10-20 times every day still..
> 
> -- Edvin
> 

I hope we see a non snapshot release soon.  This sounds like a doozy of a
bug - show stopper for everyone!
-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16735844.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread Edvin Syse

No, it has not. Johan said he fixed a bug that might have been this problem, but I haven't been able to confirm it yet, as the fix is in 
1.3-SNAPSHOT, and I ran into some issues when deploying with the snapshot-version.


I see this problem 10-20 times every day still..

-- Edvin

StephenP skrev:

Has a JIRA issue been created to track this fix?

Thanks,
Stephen




Yes, it seems to be an error in Wicket.
Johan says it should be fixed it in the latest shapshot version, but I have
not tried it yet.

But I will probably keep the workaround code as an extra protection.

Niels 


Anything new on this issue?

/Gwyn




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-16 Thread StephenP


Has a JIRA issue been created to track this fix?

Thanks,
Stephen




Yes, it seems to be an error in Wicket.
Johan says it should be fixed it in the latest shapshot version, but I have
not tried it yet.

But I will probably keep the workaround code as an extra protection.

Niels 

Anything new on this issue?

/Gwyn


-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16718246.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-13 Thread Edvin Syse


Yes I did - didn't help.

-- Edvin

On Apr 13, 2008, at 3:42, "Ryan Holmes" <[EMAIL PROTECTED]> wrote:


Did you try HttpSessionStore?
-Ryan

On Mon, Apr 7, 2008 at 2:00 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:


is it really the wicket session or a page?




I believe it's the session, but I'm not sure. The "hijacker" is  
able to
navigate through all pages as the hijacked user.. And on the top of  
every

page there is a logout button and text saying "Logout ".

I'm not running in a clustered environment, just plain Jetty 6.1.7 in
setuid mode.

I'm using the SecondLevelCacheSessionStore, but I'm thinking about  
trying

with the HttpSessionStore now to see if it makes any difference.

I refer to the session object with a static getter everywhere (I  
think)

using MySession.get().etc..

-- Edvin


On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]>  
wrote:


Today I deployed an application based on Wicket 1.3.3 that has  
close to
10.000 users. After a couple of hours we started getting reports  
from

users
saying that even upon requesting the login-page, they were already
logged in
as an arbitrary user.

The users they were logged in as had previously performed a  
succesful

login.

It seems like the wicket-sessions bleed over between different
http-sessions. I tried changing from HybridUrlCodingStrategy to
mounting the
pages with the normal mountBookmarkablePage() method, but the  
results

are
the same. I also tried downgrading to 1.3.2 with the same results.

Can anyone think of a logical mistake I might have made?

Sincerely,
Edvin Syse

--- 
--

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-12 Thread Ryan Holmes

Did you try HttpSessionStore?
-Ryan

On Mon, Apr 7, 2008 at 2:00 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> is it really the wicket session or a page?
> >
>
> I believe it's the session, but I'm not sure. The "hijacker" is able to
> navigate through all pages as the hijacked user.. And on the top of every
> page there is a logout button and text saying "Logout ".
>
> I'm not running in a clustered environment, just plain Jetty 6.1.7 in
> setuid mode.
>
> I'm using the SecondLevelCacheSessionStore, but I'm thinking about trying
> with the HttpSessionStore now to see if it makes any difference.
>
> I refer to the session object with a static getter everywhere (I think)
> using MySession.get().etc..
>
> -- Edvin
>
>
> > On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
> >
> >  Today I deployed an application based on Wicket 1.3.3 that has close to
> > > 10.000 users. After a couple of hours we started getting reports from
> > > users
> > > saying that even upon requesting the login-page, they were already
> > > logged in
> > > as an arbitrary user.
> > >
> > > The users they were logged in as had previously performed a succesful
> > > login.
> > >
> > > It seems like the wicket-sessions bleed over between different
> > > http-sessions. I tried changing from HybridUrlCodingStrategy to
> > > mounting the
> > > pages with the normal mountBookmarkablePage() method, but the results
> > > are
> > > the same. I also tried downgrading to 1.3.2 with the same results.
> > >
> > > Can anyone think of a logical mistake I might have made?
> > >
> > > Sincerely,
> > > Edvin Syse
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-12 Thread Niels Bo


Yes, it seems to be an error in Wicket.
Johan says it should be fixed it in the latest shapshot version, but I have
not tried it yet.

But I will probably keep the workaround code as an extra protection.

Niels 

Gwyn wrote:
> 
> Anything new on this issue?
> 
> /Gwyn
> 
> On Wed, Apr 9, 2008 at 5:55 PM, Niels Bo <[EMAIL PROTECTED]> wrote:
>>
>>  ok, I can put a try-catch(Throwable t) around the service() and log that
>>  together with the request-url.
>>  But since it is a production server, I am not able to get it deployed
>> until
>>  tomorrow evening, and right now we are doing ok with the workaround.
>>
>>  Niels
>>
>>
>>
>>
>>  Johan Compagner wrote:
>>  >
>>  > if there was an error before that
>>  > that should then be logged just before you log that there is a wrong
>> state
>>  >
>>  > The way you do it now is in reverse
>>  >
>>  > the wrong state was already set in X number of request back
>>  > so when you log it, You can;'t really tie it to a a specific request
>> that
>>  > did go wrong.
>>  >
>>  > If you log it later after the service method. Then you know that it
>> did
>>  > happen for that request
>>  > And most likely there should be some error before that.. Because i
>> dont
>>  > see
>>  > another way
>>  > how it would be possible when the normal flow without exceptions would
>>  > happen.
>>  >
>>  > johan
>>  >
>>  >
>>  > On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo <[EMAIL PROTECTED]>
>> wrote:
>>  >
>>  >>
>>  >> Hi
>>  >> How can I check/log if there are "error for that thread"?
>>  >> Niels
>>  >>
>>  >>
>>  >> 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
>>  >> >
>>  >>
>>  >> --
>>  >> View this message in context:
>>  >>
>> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.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]
>>  >>
>>  >>
>>  >
>>  >
>>
>>  --
>>  View this message in context:
>> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16590574.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]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16656648.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-11 Thread Gwyn Evans

Anything new on this issue?

/Gwyn

On Wed, Apr 9, 2008 at 5:55 PM, Niels Bo <[EMAIL PROTECTED]> wrote:
>
>  ok, I can put a try-catch(Throwable t) around the service() and log that
>  together with the request-url.
>  But since it is a production server, I am not able to get it deployed until
>  tomorrow evening, and right now we are doing ok with the workaround.
>
>  Niels
>
>
>
>
>  Johan Compagner wrote:
>  >
>  > if there was an error before that
>  > that should then be logged just before you log that there is a wrong state
>  >
>  > The way you do it now is in reverse
>  >
>  > the wrong state was already set in X number of request back
>  > so when you log it, You can;'t really tie it to a a specific request that
>  > did go wrong.
>  >
>  > If you log it later after the service method. Then you know that it did
>  > happen for that request
>  > And most likely there should be some error before that.. Because i dont
>  > see
>  > another way
>  > how it would be possible when the normal flow without exceptions would
>  > happen.
>  >
>  > johan
>  >
>  >
>  > On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo <[EMAIL PROTECTED]> wrote:
>  >
>  >>
>  >> Hi
>  >> How can I check/log if there are "error for that thread"?
>  >> Niels
>  >>
>  >>
>  >> 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
>  >> >
>  >>
>  >> --
>  >> View this message in context:
>  >> 
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.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]
>  >>
>  >>
>  >
>  >
>
>  --
>  View this message in context: 
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16590574.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]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


ok, I can put a try-catch(Throwable t) around the service() and log that
together with the request-url.
But since it is a production server, I am not able to get it deployed until
tomorrow evening, and right now we are doing ok with the workaround.

Niels
 

Johan Compagner wrote:
> 
> if there was an error before that
> that should then be logged just before you log that there is a wrong state
> 
> The way you do it now is in reverse
> 
> the wrong state was already set in X number of request back
> so when you log it, You can;'t really tie it to a a specific request that
> did go wrong.
> 
> If you log it later after the service method. Then you know that it did
> happen for that request
> And most likely there should be some error before that.. Because i dont
> see
> another way
> how it would be possible when the normal flow without exceptions would
> happen.
> 
> johan
> 
> 
> On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo <[EMAIL PROTECTED]> wrote:
> 
>>
>> Hi
>> How can I check/log if there are "error for that thread"?
>> Niels
>>
>>
>> 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
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.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]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16590574.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-09 Thread Nino Saturnino Martinez Vazquez Wael




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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

if there was an error before that
that should then be logged just before you log that there is a wrong state

The way you do it now is in reverse

the wrong state was already set in X number of request back
so when you log it, You can;'t really tie it to a a specific request that
did go wrong.

If you log it later after the service method. Then you know that it did
happen for that request
And most likely there should be some error before that.. Because i dont see
another way
how it would be possible when the normal flow without exceptions would
happen.

johan


On Wed, Apr 9, 2008 at 3:28 PM, Niels Bo <[EMAIL PROTECTED]> wrote:

>
> Hi
> How can I check/log if there are "error for that thread"?
> Niels
>
>
> 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
> >
>
> --
> View this message in context:
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.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]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Hi
How can I check/log if there are "error for that thread"?
Niels


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
> 

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585768.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

where are the values stored?
do you really see the same page ?

For example place in a private field of the page the session.getId()
when you create the page
then when you do your test is the id in both sides the same??

johan


On Wed, Apr 9, 2008 at 2:56 PM, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:

>
> I am sorry to report that we see the same problem. We run a page in IE,
> enter
> some values, ajax-submit, open the same page in Firefox, and the values
> are
> already there.
>
> Does the serialization ignore the user session? We store values in
> CompoundPropertyModel.
>
> As for the other posters, this is critical for us.
>
> We are using the april 6 snapshot from
>
> http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-SNAPSHOT/
>
> We need that snapshot because it has the StreamCorrupted fix. We can't use
> 1.3.3 final because it doesn't have that fix.
>
> Please advise.
>
> Wolfgang Gehner
>
>
> Niels Bo wrote:
> >
> > Yes, I can do that.
> >
> > It is both Application and Session at the same time.
> > RequestCycle I have never seen it happen for.
> >
> > Niels
> >
> >
> > 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]
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585349.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]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-09 Thread kman


have you tried with a different servlet container for instance tomcat?
i've experienced the same session problems with a custom webapp deployed on
jetty some time ago.
the sessionid was used to track the session and we had the same problem as
you describe in a single instance of jetty.
-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585502.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-09 Thread Wolfgang Gehner


I am sorry to report that we see the same problem. We run a page in IE, enter
some values, ajax-submit, open the same page in Firefox, and the values are
already there. 

Does the serialization ignore the user session? We store values in
CompoundPropertyModel.

As for the other posters, this is critical for us.

We are using the april 6 snapshot from
http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-SNAPSHOT/

We need that snapshot because it has the StreamCorrupted fix. We can't use
1.3.3 final because it doesn't have that fix.

Please advise.

Wolfgang Gehner


Niels Bo wrote:
> 
> Yes, I can do that.
> 
> It is both Application and Session at the same time.
> RequestCycle I have never seen it happen for.
> 
> Niels
> 
> 
> 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]
>>>
>>>
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585349.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

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

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Yes, I can do that.

It is both Application and Session at the same time.
RequestCycle I have never seen it happen for.

Niels


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

-- 
View this message in context: 
http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585336.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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-09 Thread Nino Saturnino Martinez Vazquez Wael


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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

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

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

this can happen at some level..

for example if you have somewhere in the code that an error code is set as a
response
and that error code is mounted to a error page in the app server
then there are 2 request at the same time for the same thread to wicket..

I worked around that last weekend. But in this case the request
cycle/session can still be there or must be there.

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

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


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]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-08 Thread Matej Knopp

sorry, this was supposed to go off the list, please don't reply here :)

-Matej

On Tue, Apr 8, 2008 at 11:19 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  We (Johan and me - wicket committers) can look at your application as
>  this problem seems to be quite serious. What would be the best way to
>  get the application running so that we can see it also we would need
>  to see some source code.
>
>  -Matej
>
>
>
>  On Tue, Apr 8, 2008 at 10:53 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
>  > The problem is still there and now it is getting serious for my business.
>  > Would any of the core committers be willing to look at my application? I'll
>  > pay USD 2500 as a onetime fee for looking at this.. (Or name your
>  > hour-price)
>  >
>  >
>  >
>  >  -- Edvin
>  >
>  >  -
>  >  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>
>
>
>
> --
>  Resizable and reorderable grid components.
>  http://www.inmethod.com
>



-- 
Resizable and reorderable grid components.
http://www.inmethod.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-08 Thread Matej Knopp

Hi,

We (Johan and me - wicket committers) can look at your application as
this problem seems to be quite serious. What would be the best way to
get the application running so that we can see it also we would need
to see some source code.

-Matej

On Tue, Apr 8, 2008 at 10:53 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
> The problem is still there and now it is getting serious for my business.
> Would any of the core committers be willing to look at my application? I'll
> pay USD 2500 as a onetime fee for looking at this.. (Or name your
> hour-price)
>
>
>
>  -- Edvin
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
Resizable and reorderable grid components.
http://www.inmethod.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-08 Thread Johan Compagner

we can look at somehow, but what do you have in mind?
is it something that we can test/debug somehow easily?

johan

On Tue, Apr 8, 2008 at 10:53 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> The problem is still there and now it is getting serious for my business.
> Would any of the core committers be willing to look at my application? I'll
> pay USD 2500 as a onetime fee for looking at this.. (Or name your
> hour-price)
>
>
> -- Edvin
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

The problem is still there and now it is getting serious for my business. Would any of the core committers be willing to look at my 
application? I'll pay USD 2500 as a onetime fee for looking at this.. (Or name your hour-price)


-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


This wasn't it. I found out that IndexedParamUrlCodingStrategy did the same 
thing so I changed to that one and still get the error.. sigh...

-- Edvin

Edvin Syse skrev:
Here goes the other one I think there might be a problem with, since it 
deals with PageMaps etc, and I'm not all that familiar with them. I 
didn't write much of this code, just changed what I needed to get it to 
work the way I wanted:


/**
 * Url coding strategy for pages that encode number based
 * parameters without having the numbers in the url.
 *
 * The parameters are given on the form /param0-value/param1-value/ etc. 
and the

 * paramnames are "0", "1" etc.
 *
 *
 */
public class NumberedRequestTargetUrlCodingStrategy extends 
AbstractRequestTargetUrlCodingStrategy {

/** bookmarkable page class. */
protected final WeakReference/*  */bookmarkablePageClassRef;

/** page map name. */
private final String pageMapName;

public NumberedRequestTargetUrlCodingStrategy(final String mountPath,
final Class bookmarkablePageClass, String pageMapName) {
super(mountPath);

if (bookmarkablePageClass == null) {
throw new IllegalArgumentException(
"Argument bookmarkablePageClass must be not null");
}

this.bookmarkablePageClassRef = new 
WeakReference(bookmarkablePageClass);

this.pageMapName = pageMapName;
}

/**
 * @see 
org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy#decode(org.apache.wicket.request.RequestParameters) 


 */
public IRequestTarget decode(RequestParameters requestParameters) {
final String parametersFragment = requestParameters.getPath()
.substring(getMountPath().length());
final PageParameters parameters = new 
PageParameters(decodeParameters(

parametersFragment, requestParameters.getParameters()));
String pageMapName = (String) parameters
.remove(WebRequestCodingStrategy.PAGEMAP);
if (requestParameters.getPageMapName() == null) {
requestParameters.setPageMapName(pageMapName);
} else {
pageMapName = requestParameters.getPageMapName();
}

// do some extra work for checking whether this is a normal 
request to a
// bookmarkable page, or a request to a stateless page (in which 
case a

// wicket:interface parameter should be available
final String interfaceParameter = (String) parameters
.remove(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME);

if (interfaceParameter != null) {

WebRequestCodingStrategy.addInterfaceParameters(interfaceParameter,

requestParameters);
return new 
BookmarkableListenerInterfaceRequestTarget(pageMapName,

(Class) bookmarkablePageClassRef.get(),
parameters,
requestParameters.getComponentPath(),
requestParameters.getInterfaceName(),
1);
} else {
return new BookmarkablePageRequestTarget(pageMapName,
(Class) bookmarkablePageClassRef.get(), parameters);
}
}

/**
 * @see 
org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy#encode(org.apache.wicket.IRequestTarget) 


 */
public final CharSequence encode(final IRequestTarget requestTarget) {
if (!(requestTarget instanceof IBookmarkablePageRequestTarget)) {
throw new IllegalArgumentException(
"This encoder can only be used with " + "instances of "
+ 
IBookmarkablePageRequestTarget.class.getName());

}

final AppendingStringBuffer url = new AppendingStringBuffer(40);
url.append(getMountPath());
final IBookmarkablePageRequestTarget target = 
(IBookmarkablePageRequestTarget) requestTarget;


PageParameters pageParameters = target.getPageParameters();
String pagemap = pageMapName != null ? pageMapName : target
.getPageMapName();
if (pagemap != null) {
if (pageParameters == null) {
pageParameters = new PageParameters();
}
pageParameters.put(WebRequestCodingStrategy.PAGEMAP, pagemap);
}
appendParameters(url, pageParameters);
return url;
}

/**
 * @see 
org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy#matches(org.apache.wicket.IRequestTarget) 


 */
public boolean matches(IRequestTarget requestTarget) {
if (requestTarget instanceof IBookmarkablePageRequestTarget) {
IBookmarkablePageRequestTarget target = 
(IBookmarkablePageRequestTarget) requestTarget;

if (((Class) bookmarkablePageClassRef.get()).equals(target
.getPageClass())) {
if (this.pageMapName == null) {
return true;

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

Here goes the other one I think there might be a problem with, since it deals with PageMaps etc, and I'm not all that familiar with them. I 
didn't write much of this code, just changed what I needed to get it to work the way I wanted:


/**
 * Url coding strategy for pages that encode number based
 * parameters without having the numbers in the url.
 *
 * The parameters are given on the form /param0-value/param1-value/ etc. and the
 * paramnames are "0", "1" etc.
 *
 *
 */
public class NumberedRequestTargetUrlCodingStrategy extends 
AbstractRequestTargetUrlCodingStrategy {
/** bookmarkable page class. */
protected final WeakReference/*  */bookmarkablePageClassRef;

/** page map name. */
private final String pageMapName;

public NumberedRequestTargetUrlCodingStrategy(final String mountPath,
final Class bookmarkablePageClass, String pageMapName) {
super(mountPath);

if (bookmarkablePageClass == null) {
throw new IllegalArgumentException(
"Argument bookmarkablePageClass must be not 
null");
}

this.bookmarkablePageClassRef = new 
WeakReference(bookmarkablePageClass);
this.pageMapName = pageMapName;
}

/**
 * @see 
org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy#decode(org.apache.wicket.request.RequestParameters)
 */
public IRequestTarget decode(RequestParameters requestParameters) {
final String parametersFragment = requestParameters.getPath()
.substring(getMountPath().length());
final PageParameters parameters = new 
PageParameters(decodeParameters(
parametersFragment, 
requestParameters.getParameters()));
String pageMapName = (String) parameters
.remove(WebRequestCodingStrategy.PAGEMAP);
if (requestParameters.getPageMapName() == null) {
requestParameters.setPageMapName(pageMapName);
} else {
pageMapName = requestParameters.getPageMapName();
}

// do some extra work for checking whether this is a normal 
request to a
// bookmarkable page, or a request to a stateless page (in 
which case a
// wicket:interface parameter should be available
final String interfaceParameter = (String) parameters

.remove(WebRequestCodingStrategy.INTERFACE_PARAMETER_NAME);

if (interfaceParameter != null) {

WebRequestCodingStrategy.addInterfaceParameters(interfaceParameter,
requestParameters);
return new 
BookmarkableListenerInterfaceRequestTarget(pageMapName,
(Class) bookmarkablePageClassRef.get(),
parameters,
requestParameters.getComponentPath(),
requestParameters.getInterfaceName(),
1);
} else {
return new BookmarkablePageRequestTarget(pageMapName,
(Class) bookmarkablePageClassRef.get(), 
parameters);
}
}

/**
 * @see 
org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy#encode(org.apache.wicket.IRequestTarget)
 */
public final CharSequence encode(final IRequestTarget requestTarget) {
if (!(requestTarget instanceof IBookmarkablePageRequestTarget)) 
{
throw new IllegalArgumentException(
"This encoder can only be used with " + 
"instances of "
+ 
IBookmarkablePageRequestTarget.class.getName());
}

final AppendingStringBuffer url = new AppendingStringBuffer(40);
url.append(getMountPath());
final IBookmarkablePageRequestTarget target = 
(IBookmarkablePageRequestTarget) requestTarget;

PageParameters pageParameters = target.getPageParameters();
String pagemap = pageMapName != null ? pageMapName : target
.getPageMapName();
if (pagemap != null) {
if (pageParameters == null) {
pageParameters = new PageParameters();
}
pageParameters.put(WebRequestCodingStrategy.PAGEMAP, 
pagemap);
}
appendParameters(url, pageParameters);
return url;
}

/**

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Matthew Young wrote:

log.error(Session.get().getId() + " " + Session.get().hashCode() + " " +

currentIp + " C: " + currentCustomer != null ? currentCustomer.getFullName()
: "nocustomer");

You should put parent around ?:.  The '+' op is evaluated before "!=".  Your
statement is effectively this:


Thanks, I found out earlier and have redeployed with parenthesis. I've also swapped out Session.get().getId()/hashCode() with just 
getId()/hashCode() since I'm IN the session when I'm doing this :)


I would also like to submit some more code that might have something to do with the problem First up is my RequestCycleProcessor which I 
override in the Application#init method:


@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new TornadoRequestCycleProcessor();
}

The point of this is to "mount" pages directly on /. What it does is basically pass some url's (starting with css/gfx or js to a 
WebExternalResourceRequestTarget, or else sends the parameteres to a another page that will know how to get data from the database based on 
the parameteres and display the correct page.


It's based on a tip from Igor a while back, so probably it's safe unless I 
managed to severely fuck it up :)

I'll post another email with my custom UrlCodingStrategy as well.

Here is the code:

public class TornadoRequestCycleProcessor extends WebRequestCycleProcessor {

@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
return new TornadoRequestCodingStrategy();
}


private static class TornadoRequestCodingStrategy extends 
WebRequestCodingStrategy {
private final TornadoUrlCodingStrategy strat = new 
TornadoUrlCodingStrategy();

@Override
public IRequestTargetUrlCodingStrategy 
urlCodingStrategyForPath(String path) {
IRequestTargetUrlCodingStrategy target = 
super.urlCodingStrategyForPath(path);
if (target == null) {
target = strat;
}

return target;
}
}

private static class TornadoUrlCodingStrategy extends 
BookmarkablePageRequestTargetUrlCodingStrategy {

public TornadoUrlCodingStrategy() {
super("/", PageModule.class, null);
}

@Override
public IRequestTarget decode(RequestParameters 
requestParameters) {
String path = requestParameters.getPath();
if(path.startsWith("css") || path.startsWith("gfx") || 
path.startsWith("js"))
return new WebExternalResourceRequestTarget("/" 
+ requestParameters.getPath());

if(requestParameters.getParameters().size() > 0) {
StringBuilder args = new StringBuilder("?");
Object[] keys = 
requestParameters.getParameters().keySet().toArray();
Object[] values = 
requestParameters.getParameters().values().toArray();
int size = 
requestParameters.getParameters().size();
for(int i = size-1; i > -1; i--) {
Object[] valueMap = (Object[]) 
values[i];
args.append(keys[i] + "=" + 
valueMap[0]);
if(i > 0)
args.append("&");
}
path = path + args.toString();
}

return new BookmarkablePageRequestTarget(PageModule.class, new 
PageParameters("0=" + path));
}
}

}

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-08 Thread Matthew Young

>log.error(Session.get().getId() + " " + Session.get().hashCode() + " " +
currentIp + " C: " + currentCustomer != null ? currentCustomer.getFullName()
: "nocustomer");

You should put parent around ?:.  The '+' op is evaluated before "!=".  Your
statement is effectively this:

   ("C:" + currentCustomer) != null ? currentCustomer.getFullName() :
"nocustomer"

So != null is always true and you get NPE on currentCustomer.getFullName()

Do this:

"C:" + (currentCustomer != null ? currentCustomer.getFullName() :
"nocustomer"));

then you are safe.

On Tue, Apr 8, 2008 at 8:01 AM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> I think I have something... Look at the attached stacktrace. It seems I
> get an NPE on the line where I do:
>
> log.error(Session.get().getId() + " " + Session.get().hashCode() + " " +
> currentIp + " C: " + currentCustomer != null ? currentCustomer.getFullName()
> : "nocustomer");
>
> I think that Session.get() returns null somehow.. That's not supposed to
> happen, is it?
>
> -- Edvin
>
>
>
> 16:54:20,902 ERROR [RequestCycle] [btpool0-9]
> org.mortbay.jetty.EofException
> org.apache.wicket.WicketRuntimeException: org.mortbay.jetty.EofException
>at
> org.apache.wicket.protocol.http.request.WebErrorCodeResponseTarget.respond(WebErrorCodeResponseTarget.java:96)
>at
> org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
>at
> org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)
>at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
>at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330)
>at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
>at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358)
>at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
>at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
>at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
>at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
>at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
>at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
>at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>at org.mortbay.jetty.Server.handle(Server.java:324)
>at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
>at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
>at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> Caused by: org.mortbay.jetty.EofException
>at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760)
>at
> org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566)
>at
> org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:910)
>at
> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:650)
>at
> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:577)
>at
> org.mortbay.util.ByteArrayISO8859Writer.writeTo(ByteArrayISO8859Writer.java:103)
>at
> org.mortbay.jetty.handler.ErrorHandler.handle(ErrorHandler.java:55)
>at
> org.mortbay.jetty.servlet.ErrorPageErrorHandler.handle(ErrorPageErrorHandler.java:117)
>at org.mortbay.jetty.Response.sendError(Response.java:274)
>at org.mortbay.jetty.Response.sendError(Response.java:340)
>at
> org.apache.wicket.protocol.http.request.WebErrorCodeResponseTarget.respond(WebErrorCodeResponseTarget.java:91)
>... 24 more
> Caused by: java.io.IOException: Connection reset by peer
>at sun.nio.ch.FileDispatcher.writev0(Native Method)
>at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:33)
>at sun.nio.ch.IOUtil.write(IOUtil.java:164)
>at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:365)
>at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:388)
>at java.nio.channels.SocketChannel.write(SocketChannel.java:360)
>at
> org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:229)
>at

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

I think I have something... Look at the attached stacktrace. It seems I 
get an NPE on the line where I do:


log.error(Session.get().getId() + " " + Session.get().hashCode() + " " + 
currentIp + " C: " + currentCustomer != null ? 
currentCustomer.getFullName() : "nocustomer");


I think that Session.get() returns null somehow.. That's not supposed to 
happen, is it?


-- Edvin



16:54:20,902 ERROR [RequestCycle] [btpool0-9] org.mortbay.jetty.EofException
org.apache.wicket.WicketRuntimeException: org.mortbay.jetty.EofException
at 
org.apache.wicket.protocol.http.request.WebErrorCodeResponseTarget.respond(WebErrorCodeResponseTarget.java:96)
at 
org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
at 
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)

at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at 
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at 
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:324)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)

Caused by: org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760)
at 
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566)
at 
org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:910)
at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:650)
at 
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:577)
at 
org.mortbay.util.ByteArrayISO8859Writer.writeTo(ByteArrayISO8859Writer.java:103)
at 
org.mortbay.jetty.handler.ErrorHandler.handle(ErrorHandler.java:55)
at 
org.mortbay.jetty.servlet.ErrorPageErrorHandler.handle(ErrorPageErrorHandler.java:117)

at org.mortbay.jetty.Response.sendError(Response.java:274)
at org.mortbay.jetty.Response.sendError(Response.java:340)
at 
org.apache.wicket.protocol.http.request.WebErrorCodeResponseTarget.respond(WebErrorCodeResponseTarget.java:91)

... 24 more
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.writev0(Native Method)
at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:33)
at sun.nio.ch.IOUtil.write(IOUtil.java:164)
at sun.nio.ch.SocketChannelImpl.write0(SocketChannelImpl.java:365)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:388)
at java.nio.channels.SocketChannel.write(SocketChannel.java:360)
at 
org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:229)
at 
org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:197)

at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:682)
... 34 more
285154 [btpool0-9] ERROR org.mortbay.log - /undefined
java.lang.IllegalStateException: STREAM
at org.mortbay.jetty.Response.getWriter(Response.java:585)
at 
org.apache.wicket.protocol.http.WebResponse.write(WebResponse.java:355)
at 
org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:73)
at 
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:371)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at 
org.mortbay.

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


I have now redeplyed with the following log4j ConversionPattern:

%d{ABSOLUTE} %-5p [%c{1}] [%t] %m%n

I've started saving the ip of the user that creates a new session, and 
then before returning the current mailuser from the session I do:


public MailUser getCurrentMailuser() {
		String currentIp = 
((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getRemoteAddr();


if(currentIp.equals(ip))
return currentMailuser;

		log.error(Session.get().getId() + " " + Session.get().hashCode() + " " 
+ currentIp + " M: " + currentMailuser != null ? 
currentMailuser.getUsername() : "nomailuser");


		throw new RuntimeException("Invalid session M: " + 
currentMailuser.getUsername() + " " + currentIp + " / " + ip);

}


Will this be enough to get a clearer picture? Tips on what else I can do 
to make it easier to debug? I'm not very familiar with log4j..


-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Erik van Oosten wrote:

Hi,

Is there a jira issue in which the topic is tracked?


No, not yet. I want to be sure that this is a wicket bug first. I have 
now confirmed that I get the same behaviour in 1.3.2, and I'm about to 
put on some more logging as suggested to try to give you guys more 
relevant info.


I'll mail again when the logging is in place.

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-08 Thread Erik van Oosten


Hi,

Is there a jira issue in which the topic is tracked?

Regards,
   Erik.


Edvin Syse wrote:
(I wrote this email earlier this evening but forgot to send it it 
seems. Here it is:)


When I ran with 1.3.0 I also had 1.3.3 on the classpath. I reverted to 
1.3.2 30 minutes ago and still haven't seen the problem. I've been 
running 1.3.2 up until this evening with no problems reported, so I am 
now quite certain that the problem is only with 1.3.3.


We have monitoring running now, and if the problem arises when the 
traffic increases tomorrow morning we'll know for sure.


I'll report back tomorrow :)

-- Edvin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Martijn Dashorst

In this case he should use both the MDC and a Session id logger.

The MDC session id is used to track the start session id (from the
start of the request), and the other for comparison during the
request.

It is one of the things I'd like to propose for Wicket NG: to set the
MDC with session id and possibly request ID. This could replace the
request logger IMO (which I like, but I'm always ears to make our API
tighter).

Martijn

On 4/8/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> hm, slf4j supports MDC. dont know if it emulates it for logging impls
>  that dont support it or not.
>
>  here we use logback and have a thing like this:
>
>  public class RequestIdLogFilter implements Filter
>  {
> private static final String MDC_REQUEST_ID = "requestId";
> private static AtomicInteger requestIdCounter = new AtomicInteger();
>
> public void init(FilterConfig filterConfig) throws ServletException
> {
> requestIdCounter.set(1000);
> }
>
> public void doFilter(ServletRequest request, ServletResponse
>  response, FilterChain chain)
> throws IOException, ServletException
> {
> int id = requestIdCounter.getAndIncrement();
> MDC.put(MDC_REQUEST_ID, String.valueOf(id));
> try
> {
> chain.doFilter(request, response);
> }
> finally
> {
> MDC.remove(MDC_REQUEST_ID);
> }
> }
>  }
>
>  then in the log simply ${requestId} and it adds it to every logging line
>
>
>  -igor
>
>
>
>  On Mon, Apr 7, 2008 at 4:01 PM, Martijn Dashorst
>  <[EMAIL PROTECTED]> wrote:
>  > What kind of logging system do you use? log4j's pattern logger has %p
>  >  I think. If you combine this with start/end logging of your request
>  >  (see requestcycle#onbeginrequest/onendrequest) you can log the session
>  >  id together with the username. This would make it easier to track what
>  >  is happening in each thread.
>  >
>  >  Martijn
>  >
>  >
>  >
>  >  On 4/8/08, Edvin Syse <[EMAIL PROTECTED]> wrote:
>  >  > Martijn Dashorst wrote:
>  >  >
>  >  > > Add to that the thread name. This way you can track session usage
>  >  > > across threads.
>  >  > >
>  >  >
>  >  >  How do I get the thread name?
>  >  >
>  >  >
>  >  >  -- Edvin
>  >  >
>  >  > -
>  >  >  To unsubscribe, e-mail:
>  >  > [EMAIL PROTECTED]
>  >  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >  >
>  >  >
>  >
>  >
>  >
>  > --
>  >  Buy Wicket in Action: http://manning.com/dashorst
>  >  Apache Wicket 1.3.2 is released
>  >  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
>  >
>  >  -
>  >
>  >
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Martijn Dashorst wrote:

What kind of logging system do you use? log4j's pattern logger has %p
I think. If you combine this with start/end logging of your request
(see requestcycle#onbeginrequest/onendrequest) you can log the session
id together with the username. This would make it easier to track what
is happening in each thread.


The debug-output I mentioned is just to stderr now, but I'm using log4j so I'll 
set this up tomorrow, thanks! :)

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Igor Vaynberg

hm, slf4j supports MDC. dont know if it emulates it for logging impls
that dont support it or not.

here we use logback and have a thing like this:

public class RequestIdLogFilter implements Filter
{
private static final String MDC_REQUEST_ID = "requestId";
private static AtomicInteger requestIdCounter = new AtomicInteger();

public void init(FilterConfig filterConfig) throws ServletException
{
requestIdCounter.set(1000);
}

public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain)
throws IOException, ServletException
{
int id = requestIdCounter.getAndIncrement();
MDC.put(MDC_REQUEST_ID, String.valueOf(id));
try
{
chain.doFilter(request, response);
}
finally
{
MDC.remove(MDC_REQUEST_ID);
}
}
}

then in the log simply ${requestId} and it adds it to every logging line

-igor


On Mon, Apr 7, 2008 at 4:01 PM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
> What kind of logging system do you use? log4j's pattern logger has %p
>  I think. If you combine this with start/end logging of your request
>  (see requestcycle#onbeginrequest/onendrequest) you can log the session
>  id together with the username. This would make it easier to track what
>  is happening in each thread.
>
>  Martijn
>
>
>
>  On 4/8/08, Edvin Syse <[EMAIL PROTECTED]> wrote:
>  > Martijn Dashorst wrote:
>  >
>  > > Add to that the thread name. This way you can track session usage
>  > > across threads.
>  > >
>  >
>  >  How do I get the thread name?
>  >
>  >
>  >  -- Edvin
>  >
>  > -
>  >  To unsubscribe, e-mail:
>  > [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>
>
> --
>  Buy Wicket in Action: http://manning.com/dashorst
>  Apache Wicket 1.3.2 is released
>  Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
>
>  -
>
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Martijn Dashorst

What kind of logging system do you use? log4j's pattern logger has %p
I think. If you combine this with start/end logging of your request
(see requestcycle#onbeginrequest/onendrequest) you can log the session
id together with the username. This would make it easier to track what
is happening in each thread.

Martijn

On 4/8/08, Edvin Syse <[EMAIL PROTECTED]> wrote:
> Martijn Dashorst wrote:
>
> > Add to that the thread name. This way you can track session usage
> > across threads.
> >
>
>  How do I get the thread name?
>
>
>  -- Edvin
>
> -
>  To unsubscribe, e-mail:
> [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Edvin Syse wrote:

Igor Vaynberg wrote:
can you try with 1.3.1, 1.3.0. would help us isolate where the problem 
is...


I tried with 1.3.0 as well, still the same problem.


(I wrote this email earlier this evening but forgot to send it it seems. Here 
it is:)

When I ran with 1.3.0 I also had 1.3.3 on the classpath. I reverted to 1.3.2 30 minutes ago and still haven't seen the problem. I've been 
running 1.3.2 up until this evening with no problems reported, so I am now quite certain that the problem is only with 1.3.3.


We have monitoring running now, and if the problem arises when the traffic 
increases tomorrow morning we'll know for sure.

I'll report back tomorrow :)

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Martijn Dashorst wrote:

Add to that the thread name. This way you can track session usage
across threads.


How do I get the thread name?

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x



Johan Compagner wrote:

is it by the way that easy to reproduce for you?
you seem to have it pretty quickly when we ask for you if you could test
some other version


Yes, it's easy because I have more than 10.000 users that have to login to this system to check their email, so all I do is shutdown the 
app, do mvn war:war and deploy the war-file and startup again - and after a couple of minutes I would see the behaviour.



if that is the case isnt it somehow reproducible in a smaller test case?


I could set up a dev-environment with 1.3.3 tomorrow and have ten users log in/out and see if I can reproduce it. If I can, I'll start 
ripping things out until I have a small reproducible case I can submit.


Johan Compagner wrote:
> can you also log the http session id and the hash/id of the WicketSession?

I don't dare to take the app down again now, but if it breaks tomorrow I'll throw it in. If it doesn't break, I'll include this in the 1.3.3 
test.


-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Martijn Dashorst

Add to that the thread name. This way you can track session usage
across threads.

Martijn

On 4/8/08, Johan Compagner <[EMAIL PROTECTED]> wrote:
> can you also log the http session id and the hash/id of the WicketSession?
>
>
>  On Mon, Apr 7, 2008 at 11:22 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
>
>  > Igor Vaynberg wrote:
>  >
>  > > can you try with 1.3.1, 1.3.0. would help us isolate where the problem
>  > > is...
>  > >
>  > > seems kind of strange that you are the only one seeing this though...
>  > >
>  >
>  > I've turned on some logging in MySession:
>  >
>  > public MailUser getCurrentMailuser() {
>  >try {
>  >
>  >  
> System.out.println(((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getRemoteAddr()
>  > + " got mailuser " + currentMailuser.getId() + " " +
>  > currentMailuser.getUsername());
>  >} catch (Exception ignored) {}
>  >return currentMailuser;
>  > }
>  >
>  > This gives me output like:
>  >
>  > 85.165.86.192 got mailuser 19712 [EMAIL PROTECTED]
>  > 77.208.58.135 got mailuser 22817 [EMAIL PROTECTED]
>  >
>  > these are fine, but then I suddenly get:
>  >
>  > 84.215.17.110 got mailuser 21024 [EMAIL PROTECTED]
>  > 84.215.17.110 got mailuser 21740 [EMAIL PROTECTED]
>  >
>  >
>  > Trouble! One user got the session for two different users on two
>  > subsequent requests..
>  >
>  > Any ide? This is really killing me.. :(
>  >
>  > -- Edvin
>  >
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>


-- 
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Johan Compagner

is it by the way that easy to reproduce for you?
you seem to have it pretty quickly when we ask for you if you could test
some other version

if that is the case isnt it somehow reproducible in a smaller test case?

On Mon, Apr 7, 2008 at 11:25 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> Igor Vaynberg wrote:
>
> > can you try with 1.3.1, 1.3.0. would help us isolate where the problem
> > is...
> >
>
> I tried with 1.3.0 as well, still the same problem.
>
> My authorization-strategy is quite involved.. I can't see any immediate
> problems, but I'm posting it here just in case:
>
>getSecuritySettings().setAuthorizationStrategy(new
> IAuthorizationStrategy() {
>
>public boolean isActionAuthorized(Component
> component, Action action) {
>return true;
>}
>
>public boolean isInstantiationAuthorized(Class
> componentClass) {
>TornadoSession s = (TornadoSession)
> Session.get();
>
>if(MailuserBasePage.class.isAssignableFrom(componentClass))
> {
>if(s.getCurrentMailuser() == null) {
>throw new
> RestartResponseAtInterceptPageException(MailLoginPage.class);
>}
>}
>/* Instance pages needs instance */
>if
> (BasePage.class.isAssignableFrom(componentClass)) {
>if (s.getInstanceId() == null)
>throw new
> RestartResponseAtInterceptPageException(NoInstancePage.class);
>
>/* Instance has access to cms
> module */
>CmsModule cmsAnnotation =
> (CmsModule) componentClass.getAnnotation(CmsModule.class);
>if (cmsAnnotation != null) {
>if
> (!webModuleDao.instanceHasModule(s.getInstanceId(), cmsAnnotation.id())) {
>throw new
> RestartResponseAtInterceptPageException(NoModuleAccessPage.class);
>}
>}
>}
>
>/* New-instance wizard can only be calles
> from tornado */
>
>  if(NewInstanceBasePage.class.isAssignableFrom(componentClass) && !new
> Integer(1).equals(TornadoSession.get().getInstanceId()))
>throw new
> RestartResponseAtInterceptPageException(NoModuleAccessPage.class);
>
>/* Protected Control Panel pages */
>
>  if(CpBasePage.class.isAssignableFrom(componentClass)) {
>if(s.getCurrentCustomer() == null)
>throw new
> RestartResponseAtInterceptPageException(CpLoginPage.class);
>
>}
>
>
>  if(PartnerBasePage.class.isAssignableFrom(componentClass) &&
> (TornadoSession.get().getCurrentCustomer() == null ||
> !TornadoSession.get().getCurrentCustomer().getCustomerType().getId().equals(Customer.CTYPE_PARTNER)))
>throw new
> RestartResponseAtInterceptPageException(PartnerLoginPage.class);
>
>
>/* CMS Admin */
>
>  if(AdminBasePage.class.isAssignableFrom(componentClass)) {
>if(s.getCurrentUser() == null ||
> !s.getCurrentUser().getInstance().getId().equals(s.getInstanceId()))
>throw new
> RestartResponseAtInterceptPageException(AdminLogin.class);
>}
>
>/* Only instance 1 can bootstrap */
>
>  if(BootstrapModuleAdmin.class.isAssignableFrom(componentClass) &&
> !s.getInstanceId().equals(new Integer(1)))
>throw new
> RestartResponseAtInterceptPageException(AdminHomePage.class);
>
>return true;
>}
>});
>
>}
>
> -- Edvin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Johan Compagner

can you also log the http session id and the hash/id of the WicketSession?

On Mon, Apr 7, 2008 at 11:22 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> Igor Vaynberg wrote:
>
> > can you try with 1.3.1, 1.3.0. would help us isolate where the problem
> > is...
> >
> > seems kind of strange that you are the only one seeing this though...
> >
>
> I've turned on some logging in MySession:
>
> public MailUser getCurrentMailuser() {
>try {
>
>  
> System.out.println(((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getRemoteAddr()
> + " got mailuser " + currentMailuser.getId() + " " +
> currentMailuser.getUsername());
>} catch (Exception ignored) {}
>return currentMailuser;
> }
>
> This gives me output like:
>
> 85.165.86.192 got mailuser 19712 [EMAIL PROTECTED]
> 77.208.58.135 got mailuser 22817 [EMAIL PROTECTED]
>
> these are fine, but then I suddenly get:
>
> 84.215.17.110 got mailuser 21024 [EMAIL PROTECTED]
> 84.215.17.110 got mailuser 21740 [EMAIL PROTECTED]
>
>
> Trouble! One user got the session for two different users on two
> subsequent requests..
>
> Any ide? This is really killing me.. :(
>
> -- Edvin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Igor Vaynberg wrote:

can you try with 1.3.1, 1.3.0. would help us isolate where the problem is...


I tried with 1.3.0 as well, still the same problem.

My authorization-strategy is quite involved.. I can't see any immediate 
problems, but I'm posting it here just in case:

getSecuritySettings().setAuthorizationStrategy(new 
IAuthorizationStrategy() {

public boolean isActionAuthorized(Component component, 
Action action) {
return true;
}

public boolean isInstantiationAuthorized(Class 
componentClass) {
TornadoSession s = (TornadoSession) 
Session.get();

if(MailuserBasePage.class.isAssignableFrom(componentClass)) {
if(s.getCurrentMailuser() == null) {
throw new 
RestartResponseAtInterceptPageException(MailLoginPage.class);
}
}
/* Instance pages needs instance */
if 
(BasePage.class.isAssignableFrom(componentClass)) {
if (s.getInstanceId() == null)
throw new 
RestartResponseAtInterceptPageException(NoInstancePage.class);

/* Instance has access to cms module */
CmsModule cmsAnnotation = (CmsModule) 
componentClass.getAnnotation(CmsModule.class);
if (cmsAnnotation != null) {
if 
(!webModuleDao.instanceHasModule(s.getInstanceId(), cmsAnnotation.id())) {
throw new 
RestartResponseAtInterceptPageException(NoModuleAccessPage.class);
}
}
}

/* New-instance wizard can only be calles from 
tornado */

if(NewInstanceBasePage.class.isAssignableFrom(componentClass) && !new 
Integer(1).equals(TornadoSession.get().getInstanceId()))
throw new 
RestartResponseAtInterceptPageException(NoModuleAccessPage.class);

/* Protected Control Panel pages */

if(CpBasePage.class.isAssignableFrom(componentClass)) {
if(s.getCurrentCustomer() == null)
throw new 
RestartResponseAtInterceptPageException(CpLoginPage.class);

}

if(PartnerBasePage.class.isAssignableFrom(componentClass) && (TornadoSession.get().getCurrentCustomer() == null || 
!TornadoSession.get().getCurrentCustomer().getCustomerType().getId().equals(Customer.CTYPE_PARTNER)))

throw new 
RestartResponseAtInterceptPageException(PartnerLoginPage.class);


/* CMS Admin */

if(AdminBasePage.class.isAssignableFrom(componentClass)) {
if(s.getCurrentUser() == null || 
!s.getCurrentUser().getInstance().getId().equals(s.getInstanceId()))
throw new 
RestartResponseAtInterceptPageException(AdminLogin.class);
}

/* Only instance 1 can bootstrap */

if(BootstrapModuleAdmin.class.isAssignableFrom(componentClass) && 
!s.getInstanceId().equals(new Integer(1)))
throw new 
RestartResponseAtInterceptPageException(AdminHomePage.class);

return true;
}
});

}

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x


Igor Vaynberg wrote:

can you try with 1.3.1, 1.3.0. would help us isolate where the problem is...

seems kind of strange that you are the only one seeing this though...


I've turned on some logging in MySession:

public MailUser getCurrentMailuser() {
try {
		System.out.println(((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getRemoteAddr() + " got mailuser " + 
currentMailuser.getId() + " " + currentMailuser.getUsername());

} catch (Exception ignored) {}
return currentMailuser;
}

This gives me output like:

85.165.86.192 got mailuser 19712 [EMAIL PROTECTED]
77.208.58.135 got mailuser 22817 [EMAIL PROTECTED]

these are fine, but then I suddenly get:

84.215.17.110 got mailuser 21024 [EMAIL PROTECTED]
84.215.17.110 got mailuser 21740 [EMAIL PROTECTED]


Trouble! One user got the session for two different users on two subsequent 
requests..

Any ide? This is really killing me.. :(

-- Edvin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Igor Vaynberg

can you try with 1.3.1, 1.3.0. would help us isolate where the problem is...

seems kind of strange that you are the only one seeing this though...

-igor


On Mon, Apr 7, 2008 at 1:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
> Today I deployed an application based on Wicket 1.3.3 that has close to
> 10.000 users. After a couple of hours we started getting reports from users
> saying that even upon requesting the login-page, they were already logged in
> as an arbitrary user.
>
>  The users they were logged in as had previously performed a succesful
> login.
>
>  It seems like the wicket-sessions bleed over between different
> http-sessions. I tried changing from HybridUrlCodingStrategy to mounting the
> pages with the normal mountBookmarkablePage() method, but the results are
> the same. I also tried downgrading to 1.3.2 with the same results.
>
>  Can anyone think of a logical mistake I might have made?
>
>  Sincerely,
>  Edvin Syse
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

is it really the wicket session or a page?

I believe it's the session, but I'm not sure. The "hijacker" is able to navigate through all pages as the hijacked user.. And on the top of
every page there is a logout button and text saying "Logout ".

I'm not running in a clustered environment, just plain Jetty 6.1.7 in setuid
mode.

I'm using the SecondLevelCacheSessionStore, but I'm thinking about trying with
the HttpSessionStore now to see if it makes any difference.

I refer to the session object with a static getter everywhere (I think) using
MySession.get().etc..

-- Edvin

On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

Today I deployed an application based on Wicket 1.3.3 that has close to
10.000 users. After a couple of hours we started getting reports from users
saying that even upon requesting the login-page, they were already logged in
as an arbitrary user.

The users they were logged in as had previously performed a succesful
login.

It seems like the wicket-sessions bleed over between different
http-sessions. I tried changing from HybridUrlCodingStrategy to mounting the
pages with the normal mountBookmarkablePage() method, but the results are
the same. I also tried downgrading to 1.3.2 with the same results.

Can anyone think of a logical mistake I might have made?

Sincerely,
Edvin Syse

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Matej Knopp

Is you application running in clustered environment? Are you storing
the session reference anywhere?

-Matej

On Mon, Apr 7, 2008 at 10:47 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> is it really the wicket session or a page?
>
>
>
>  On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:
>
>  > Today I deployed an application based on Wicket 1.3.3 that has close to
>  > 10.000 users. After a couple of hours we started getting reports from users
>  > saying that even upon requesting the login-page, they were already logged 
> in
>  > as an arbitrary user.
>  >
>  > The users they were logged in as had previously performed a succesful
>  > login.
>  >
>  > It seems like the wicket-sessions bleed over between different
>  > http-sessions. I tried changing from HybridUrlCodingStrategy to mounting 
> the
>  > pages with the normal mountBookmarkablePage() method, but the results are
>  > the same. I also tried downgrading to 1.3.2 with the same results.
>  >
>  > Can anyone think of a logical mistake I might have made?
>  >
>  > Sincerely,
>  > Edvin Syse
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>



-- 
Resizable and reorderable grid components.
http://www.inmethod.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Invoulentary session sharing/leakage in Wicket 1.3.x

2008-04-07 Thread Johan Compagner

is it really the wicket session or a page?

On Mon, Apr 7, 2008 at 10:40 PM, Edvin Syse <[EMAIL PROTECTED]> wrote:

> Today I deployed an application based on Wicket 1.3.3 that has close to
> 10.000 users. After a couple of hours we started getting reports from users
> saying that even upon requesting the login-page, they were already logged in
> as an arbitrary user.
>
> The users they were logged in as had previously performed a succesful
> login.
>
> It seems like the wicket-sessions bleed over between different
> http-sessions. I tried changing from HybridUrlCodingStrategy to mounting the
> pages with the normal mountBookmarkablePage() method, but the results are
> the same. I also tried downgrading to 1.3.2 with the same results.
>
> Can anyone think of a logical mistake I might have made?
>
> Sincerely,
> Edvin Syse
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Invoulentary session sharing/leakage in Wicket 1.3.x