i suggest always mounting with querystringurlcodingstrategy unless you
specifically want the folder structure of /name1/value1/name2/value2
which most of the time you dont. too bad this was made the default, we
cant change it in 1.4 but are fixing it in 1.5 as it causes all kinds
of problems.

-igor

On Thu, Mar 18, 2010 at 4:42 PM, Chris Colman
<chr...@stepaheadsoftware.com> wrote:
> 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
>
>

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

Reply via email to