You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Robert Dahlström <ro...@ongame.com> on 2011/06/20 11:25:47 UTC
Locating StackOverflowErrors
Hi, I've been trying for some time now to localize a somewhat random
stackoverflow error. I've done an overhaul of the code and am now
convinced we no longer have any reference to the session object but we
still get StackOverflowErrors during page serialization.
This has probably been covered before (I seem to remember a link to some
of the most common errors but could not find it again).
Any pointers would be greatly appreciated.
I guess this could be rephrased to: What are the do not's of Wicket?
Regards
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by Robert Dahlström <ro...@ongame.com>.
Interesting idea, but I'm pretty sure we get a cyclic reference
somewhere. (I'm basing that on the stacktrace below) which has been
somewhat edited for brevity:
[org.apache.wicket.Session] - Exception when detaching/serializing page
java.lang.StackOverflowError
...
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
...
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1124)
at
org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:203)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.prepareForSerialization(DiskPageStore.java:1190)
at
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.writeObject(SecondLevelCacheSessionStore.java:390)
...
at
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:121)
...
rince & repeat, until Wicket has had enough.
/Robert
On 06/20/2011 01:01 PM, Martijn Dashorst wrote:
> Note that you can increase the max stack size, which sometimes too low
> for given component structures. We run with the default for 64 bit
> machines on our production boxes (-Xss1024k), but that is specific to
> and sufficient for our application. Your application might just push
> that boundary.
>
> You might want to try to double the size and see how that works out.
> If you still see those errors, then you might have an infinite loop
> somewhere...
>
>> From http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#threads_oom:
>
> My application has a lot of threads and is running out of memory, why?
>
> You may be running into a problem with the default stack size for
> threads. In Java SE 6, the default on Sparc is 512k in the 32-bit VM,
> and 1024k in the 64-bit VM. On x86 Solaris/Linux it is 320k in the
> 32-bit VM and 1024k in the 64-bit VM.
>
> On Windows, the default thread stack size is read from the binary
> (java.exe). As of Java SE 6, this value is 320k in the 32-bit VM and
> 1024k in the 64-bit VM.
>
> You can reduce your stack size by running with the -Xss option. For example:
>
> java -server -Xss64k
>
> Note that on some versions of Windows, the OS may round up thread
> stack sizes using very coarse granularity. If the requested size is
> less than the default size by 1K or more, the stack size is rounded up
> to the default; otherwise, the stack size is rounded up to a multiple
> of 1 MB.
>
> 64k is the least amount of stack space allowed per thread.
>
> Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by Martijn Dashorst <ma...@gmail.com>.
Note that you can increase the max stack size, which sometimes too low
for given component structures. We run with the default for 64 bit
machines on our production boxes (-Xss1024k), but that is specific to
and sufficient for our application. Your application might just push
that boundary.
You might want to try to double the size and see how that works out.
If you still see those errors, then you might have an infinite loop
somewhere...
>From http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#threads_oom:
My application has a lot of threads and is running out of memory, why?
You may be running into a problem with the default stack size for
threads. In Java SE 6, the default on Sparc is 512k in the 32-bit VM,
and 1024k in the 64-bit VM. On x86 Solaris/Linux it is 320k in the
32-bit VM and 1024k in the 64-bit VM.
On Windows, the default thread stack size is read from the binary
(java.exe). As of Java SE 6, this value is 320k in the 32-bit VM and
1024k in the 64-bit VM.
You can reduce your stack size by running with the -Xss option. For example:
java -server -Xss64k
Note that on some versions of Windows, the OS may round up thread
stack sizes using very coarse granularity. If the requested size is
less than the default size by 1K or more, the stack size is rounded up
to the default; otherwise, the stack size is rounded up to a multiple
of 1 MB.
64k is the least amount of stack space allowed per thread.
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by Robert Dahlström <ro...@ongame.com>.
No, we should not have any references to the session in models.
Thanks
Robert
On 06/20/2011 11:43 AM, Serban.Balamaci wrote:
> Hello,
> Are you perhaps using your WebSession in a PropertyModel?
> like new PropertyModel(getSession(), "username") for example?
>
> This way the web session might get serialized.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Locating-StackOverflowErrors-tp3610868p3610903.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by "Serban.Balamaci" <th...@gmail.com>.
Hello,
Are you perhaps using your WebSession in a PropertyModel?
like new PropertyModel(getSession(), "username") for example?
This way the web session might get serialized.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Locating-StackOverflowErrors-tp3610868p3610903.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by Robert Dahlström <ro...@ongame.com>.
Besides me not being able to figure where we have done the wrong thing I
don't have a problem with the serialization in Wicket 1.4 :)
Regards
Robert
On 06/20/2011 11:40 AM, Martin Grigorov wrote:
> Hi,
>
> Wicket uses Java Serialization to do this. So the question is: What
> are the do not's of Java Serialization ?
>
> In Wicket 1.5 this is plugable so you can use something else than Java
> Serialization (still the default impl).
>
> Schema-less serialization frameworks like Kryo and XStream is quite easy.
> Schema ones like Apache Avro, Thrift, Protobuf, etc. are harder but
> not impossible.
>
> At https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/serializer-kryo
> you can see such implementation based on
> http://code.google.com/p/kryo/ . It is a new project so maybe there
> are bugs and places for improvement.
>
> 2011/6/20 Robert Dahlström<ro...@ongame.com>:
>> Hi, I've been trying for some time now to localize a somewhat random
>> stackoverflow error. I've done an overhaul of the code and am now convinced
>> we no longer have any reference to the session object but we still get
>> StackOverflowErrors during page serialization.
>>
>> This has probably been covered before (I seem to remember a link to some of
>> the most common errors but could not find it again).
>>
>> Any pointers would be greatly appreciated.
>>
>> I guess this could be rephrased to: What are the do not's of Wicket?
>>
>> Regards
>> Robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Locating StackOverflowErrors
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Wicket uses Java Serialization to do this. So the question is: What
are the do not's of Java Serialization ?
In Wicket 1.5 this is plugable so you can use something else than Java
Serialization (still the default impl).
Schema-less serialization frameworks like Kryo and XStream is quite easy.
Schema ones like Apache Avro, Thrift, Protobuf, etc. are harder but
not impossible.
At https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/serializer-kryo
you can see such implementation based on
http://code.google.com/p/kryo/ . It is a new project so maybe there
are bugs and places for improvement.
2011/6/20 Robert Dahlström <ro...@ongame.com>:
> Hi, I've been trying for some time now to localize a somewhat random
> stackoverflow error. I've done an overhaul of the code and am now convinced
> we no longer have any reference to the session object but we still get
> StackOverflowErrors during page serialization.
>
> This has probably been covered before (I seem to remember a link to some of
> the most common errors but could not find it again).
>
> Any pointers would be greatly appreciated.
>
> I guess this could be rephrased to: What are the do not's of Wicket?
>
> Regards
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org