I'm using BookmarkablePageLink extensively as it makes it easy to add
parameter name/value pairs. I end up with URLs like:

www.mysite.com/p1/v1/p2/v2

Which works fine for most cases but I have a number of questions/issues:

My logs show exceptions whereby some browsers (or crawlers) without
cookies enabled end up requesting URLs with the ;jessionid=... suffix
which is used when no cookie support is available.

The exception is caused when I try to convert a parameter and the
session suffix is included in its value eg.,

org.apache.wicket.util.string.StringValueConversionException: Unable to
convert '4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC' to a long
value

The parameter pair was intended to be:

parameter1/4574  i.e. parameter1=4574

but with the suffix added by tomcat in the absence of cookies it became:

parameter1/4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC

i.e. parameter1=4574;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC

which isn't a valid integer value and so causes an exception.

What can we do about this? Is it possible to force wicket to always add
a trailing / because this would help wicket's parameter parser avoid
this issue eg.,

parameter1/4574/;jsessionid=3359BBC174E43EF2AE12D7F8FA80FCEC

should work fine I'd imagine.

Another thing about trailing slashes: apparently a trailing slash can
avoid an redirect. Apparently:

www.mysite.com/p1/v1 will be redirected to 
www.mysite.com/p1/v1/

If the URL was simply www.mysite.com/p1/v1/ then the redirect is
avoided.


7%3Bjsessionid%3D3359BBC174E43EF2AE12D7F8FA80FCEC

> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
> Sent: Friday, 19 March 2010 9:56 AM
> To: users@wicket.apache.org
> Subject: Re: StackOverflowError under serialization leaves pagemap
locked
> 
> the fix is in 1.4.x branch and will be part of 1.4.8.
> 
> in the meantime you can build a fresh snapshot yourself and drop that
> into your application
> 
> http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x
> 
> -igor
> 
> On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker
<nigel.par...@mazeppa.no>
> wrote:
> >
> > Thank you Johan for your reply. Agree that original problem should
be
> fixed.
> > This is a critical problem for us. We have found out during the last
24
> > hours that some of our pages are retaining a session reference. With
> Ajax
> > requests this gives a doubling of session size for every request,
and we
> now
> > believe this to be the cause of the StackOverflowErrors. We will try
> this in
> > production tomorrow.
> >
> > We upgraded to to 1.4.7 but still see that the pagemap is locked
when
> the
> > stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7?
> >
> > Thanks
> > Nigel
> >
> >
> > Johan Compagner wrote:
> >>
> >> i fixed 2075 so that it should always unlock the pages.
> >>
> >> Problem is that you still could get weird errors because that page
is
> not
> >> in
> >> a valid state in the session.
> >> So if back buttons/page versions are used it could be that that
doesnt
> >> work
> >>
> >> So what should be fixed is the original problem
> >>
> >>
> >>
> >> On Wed, Mar 17, 2010 at 21:03, Nigel Parker
<nigel.par...@mazeppa.no>
> >> wrote:
> >>
> >>> We are a Wicket shop and for one of our clients have been running
a
> >>> Wicket application successfully for over 2 years. We are now at
> >>> version 1.4.0. The traffic on the system is increasing and we are
now
> >>> seeing an increased frequency of pagemap locking which is
beginning to
> >>> be a serious problem for the users. By subclassing WebRequestCycle
we
> >>> have identified that a StackOverflowError under serialization in
> >>> RequestCycle.detach() leaves the pagemap locked for the next
minute.
> >>> If our analysis is correct this is essentially the problem
reported as
> >>> https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately
we
> >>> cannot reproduce the problem in our test environment and it occurs
> >>> only in about one in every thousand requests with no apparent
> >>> consistent pattern about what the user has been doing. Can anybody
> >>> suggest an immediate strategy for further investigations? In
> >>> particular:
> >>>
> >>> - is there a practical way to find out what is causing the
> >>> serialization problem. The stack trace is no help. We do in many
cases
> >>> have large amounts of data in the session, but doubling the
default
> >>> stack size leaves the problem frequency unchanged leading us to
> >>> suspect a logical error rather the sheer amount of data.
> >>>
> >>> - by overriding RequestCycle.detach() and catching the
> >>> StackOverflowError we can get control when the error occurs. Is
there
> >>> any way we can persuade Wicket to release the pagemap lock? I have
> >>> looked at the code and this doesn't look straightforward.
> >>>
> >>> - can we get Wicket itself to suppress the StackOverflowError so
that
> >>> detach() continues and releases the lock?
> >>>
> >>> Grateful for any suggestions.
> >>>
> >>> Nigel
> >>>
> >>>
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
http://old.nabble.com/StackOverflowError-
> under-serialization-leaves-pagemap-locked-tp27938028p27950858.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to