You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Douglas Ferguson <do...@buzzstream.com> on 2010/11/16 05:54:53 UTC
StackOverflowError
Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
> PageMap # Size Growth
> 13 389523448 1.93
> 12 202059096 1.93
> 11 104804096 1.93
> 10 54352280 1.93
> 9 28182760 1.93
> 8 14594976 1.93
> 7 7549336 1.94
> 6 3900704 1.94
> 5 2013480 2
> 4 1006960 2
> 3 503696 2
> 2 252072 1.86
> 1 135704
Any thoughts or tips on trying to get to the bottom of this one?
Here's the stack trace
> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> at java.util.LinkedList.writeObject(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
> 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)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
> at org.apache.wicket.Component.writeObject(Component.java:4660)
> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> 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)
> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> at 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:389)
Re: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
yup..
On Nov 16, 2010, at 12:05 PM, Martijn Dashorst wrote:
> DON'T DO THIS:
>
> the offending code probably was:
>
> add(new Label("id", new PropertyModel(getSession(), "someProperty")));
>
> This hard links the session to the page, and causes a cycle when serializing.
>
> Martijn
>
> On Tue, Nov 16, 2010 at 6:59 PM, jcgarciam <jc...@gmail.com> wrote:
>>
>> Douglas, can you share any insight of how having the session in the property
>> model could actually provoke this leak?
>>
>> It seems weird.
>>
>> On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
>> ml-node+3045359-698752336-65838@n4.nabble.com<ml...@n4.nabble.com>
>>> wrote:
>>
>>> it is perfectly valid to use page as the model object. in fact if you
>>> wanted to pull something out of session you can simply say new
>>> PropertyModel(this, "session.property"), this being the Page instance
>>> you are in.
>>>
>>> -igor
>>>
>>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
>>> wrote:
>>>
>>>> We found it.. Finally!!!
>>>>
>>>> There was a property model that was using the session as the model
>>> object.
>>>>
>>>> It would be cool if PropertyModel, etc would check for this and blow up
>>> on construction.
>>>> i.e. not allow Page, Session, Application as the model object...
>>>>
>>>> D/
>>>> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>>>>
>>>>> Just tested on 1.4.13 and it still happens
>>>>>
>>>>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>>>>
>>>>>> 1.4.12, but the problem has been around since a few versions back.
>>>>>>
>>>>>> D/
>>>>>>
>>>>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>>>>
>>>>>>> Are you using 1.4.13?
>>>>>>>
>>>>>>> Martijn
>>>>>>>
>>>>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>>>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
>>> wrote:
>>>>>>>> Some time ago I posted to the list regarding a stack overflow error
>>> that I was receiving and the advice was to make sure that I didn't have a
>>> page storing a reference to another page.
>>>>>>>> We did track this down and have just had to ignore it in the
>>> production logs. Now we've made it a priority to track this down.
>>>>>>>>
>>>>>>>> Anyway, we've recently tracked this down to
>>> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
>>> pasting a url into a new browser window and thus generating a new pagemap.
>>> On a certain page the memory consumption doubles as you generate new
>>> pagemaps (see the chart below). The profile is indicating that the memory is
>>> being taken up by a hashmap, but that's as far as we've been able to trace
>>> it so far.
>>>>>>>>
>>>>>>>>> PageMap # Size Growth
>>>>>>>>> 13 389523448 1.93
>>>>>>>>> 12 202059096 1.93
>>>>>>>>> 11 104804096 1.93
>>>>>>>>> 10 54352280 1.93
>>>>>>>>> 9 28182760 1.93
>>>>>>>>> 8 14594976 1.93
>>>>>>>>> 7 7549336 1.94
>>>>>>>>> 6 3900704 1.94
>>>>>>>>> 5 2013480 2
>>>>>>>>> 4 1006960 2
>>>>>>>>> 3 503696 2
>>>>>>>>> 2 252072 1.86
>>>>>>>>> 1 135704
>>>>>>>>
>>>>>>>>
>>>>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>>>>
>>>>>>>> Here's the stack trace
>>>>>>>>
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> 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)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>
>>>>>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>
>>>>>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>>>>> at
>>> 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:389)
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Become a Wicket expert, learn from the best:
>>> http://wicketinaction.com <http://wicketinaction.com?by-user=t>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2>
>>>>>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4>
>>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6>
>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7>
>>>
>>>
>>>
>>> ------------------------------
>>> View message @
>>> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html
>>> To start a new topic under Apache Wicket, email
>>> ml-node+1842946-398011874-65838@n4.nabble.com<ml...@n4.nabble.com>
>>> To unsubscribe from Apache Wicket, click here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>.
>>>
>>>
>>>
>>
>>
>> --
>> Sincerely,
>> JC (http://www.linkedin.com/in/jcgarciam)
>> Work smarter, not harder!.
>>
>> --
>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.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
>>
>>
>
>
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
Yeah.. there should really be a warning or a fatal exception in this case.. it is an easy mistake for beginners.
I even knew to look for it and I couldn't find it..
D/
On Nov 16, 2010, at 12:05 PM, Martijn Dashorst wrote:
> DON'T DO THIS:
>
> the offending code probably was:
>
> add(new Label("id", new PropertyModel(getSession(), "someProperty")));
>
> This hard links the session to the page, and causes a cycle when serializing.
>
> Martijn
>
> On Tue, Nov 16, 2010 at 6:59 PM, jcgarciam <jc...@gmail.com> wrote:
>>
>> Douglas, can you share any insight of how having the session in the property
>> model could actually provoke this leak?
>>
>> It seems weird.
>>
>> On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
>> ml-node+3045359-698752336-65838@n4.nabble.com<ml...@n4.nabble.com>
>>> wrote:
>>
>>> it is perfectly valid to use page as the model object. in fact if you
>>> wanted to pull something out of session you can simply say new
>>> PropertyModel(this, "session.property"), this being the Page instance
>>> you are in.
>>>
>>> -igor
>>>
>>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
>>> wrote:
>>>
>>>> We found it.. Finally!!!
>>>>
>>>> There was a property model that was using the session as the model
>>> object.
>>>>
>>>> It would be cool if PropertyModel, etc would check for this and blow up
>>> on construction.
>>>> i.e. not allow Page, Session, Application as the model object...
>>>>
>>>> D/
>>>> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>>>>
>>>>> Just tested on 1.4.13 and it still happens
>>>>>
>>>>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>>>>
>>>>>> 1.4.12, but the problem has been around since a few versions back.
>>>>>>
>>>>>> D/
>>>>>>
>>>>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>>>>
>>>>>>> Are you using 1.4.13?
>>>>>>>
>>>>>>> Martijn
>>>>>>>
>>>>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>>>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
>>> wrote:
>>>>>>>> Some time ago I posted to the list regarding a stack overflow error
>>> that I was receiving and the advice was to make sure that I didn't have a
>>> page storing a reference to another page.
>>>>>>>> We did track this down and have just had to ignore it in the
>>> production logs. Now we've made it a priority to track this down.
>>>>>>>>
>>>>>>>> Anyway, we've recently tracked this down to
>>> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
>>> pasting a url into a new browser window and thus generating a new pagemap.
>>> On a certain page the memory consumption doubles as you generate new
>>> pagemaps (see the chart below). The profile is indicating that the memory is
>>> being taken up by a hashmap, but that's as far as we've been able to trace
>>> it so far.
>>>>>>>>
>>>>>>>>> PageMap # Size Growth
>>>>>>>>> 13 389523448 1.93
>>>>>>>>> 12 202059096 1.93
>>>>>>>>> 11 104804096 1.93
>>>>>>>>> 10 54352280 1.93
>>>>>>>>> 9 28182760 1.93
>>>>>>>>> 8 14594976 1.93
>>>>>>>>> 7 7549336 1.94
>>>>>>>>> 6 3900704 1.94
>>>>>>>>> 5 2013480 2
>>>>>>>>> 4 1006960 2
>>>>>>>>> 3 503696 2
>>>>>>>>> 2 252072 1.86
>>>>>>>>> 1 135704
>>>>>>>>
>>>>>>>>
>>>>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>>>>
>>>>>>>> Here's the stack trace
>>>>>>>>
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> 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)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>
>>>>>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>
>>>>>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>>>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>>> Source)
>>>>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>>> Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>>>>> 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)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>>>>> at
>>> 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:389)
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Become a Wicket expert, learn from the best:
>>> http://wicketinaction.com <http://wicketinaction.com?by-user=t>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2>
>>>>>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4>
>>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6>
>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7>
>>>
>>>
>>>
>>> ------------------------------
>>> View message @
>>> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html
>>> To start a new topic under Apache Wicket, email
>>> ml-node+1842946-398011874-65838@n4.nabble.com<ml...@n4.nabble.com>
>>> To unsubscribe from Apache Wicket, click here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>.
>>>
>>>
>>>
>>
>>
>> --
>> Sincerely,
>> JC (http://www.linkedin.com/in/jcgarciam)
>> Work smarter, not harder!.
>>
>> --
>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.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
>>
>>
>
>
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Martijn Dashorst <ma...@gmail.com>.
DON'T DO THIS:
the offending code probably was:
add(new Label("id", new PropertyModel(getSession(), "someProperty")));
This hard links the session to the page, and causes a cycle when serializing.
Martijn
On Tue, Nov 16, 2010 at 6:59 PM, jcgarciam <jc...@gmail.com> wrote:
>
> Douglas, can you share any insight of how having the session in the property
> model could actually provoke this leak?
>
> It seems weird.
>
> On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
> ml-node+3045359-698752336-65838@n4.nabble.com<ml...@n4.nabble.com>
>> wrote:
>
>> it is perfectly valid to use page as the model object. in fact if you
>> wanted to pull something out of session you can simply say new
>> PropertyModel(this, "session.property"), this being the Page instance
>> you are in.
>>
>> -igor
>>
>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
>> wrote:
>>
>> > We found it.. Finally!!!
>> >
>> > There was a property model that was using the session as the model
>> object.
>> >
>> > It would be cool if PropertyModel, etc would check for this and blow up
>> on construction.
>> > i.e. not allow Page, Session, Application as the model object...
>> >
>> > D/
>> > On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>> >
>> >> Just tested on 1.4.13 and it still happens
>> >>
>> >> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>> >>
>> >>> 1.4.12, but the problem has been around since a few versions back.
>> >>>
>> >>> D/
>> >>>
>> >>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>> >>>
>> >>>> Are you using 1.4.13?
>> >>>>
>> >>>> Martijn
>> >>>>
>> >>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>> >>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
>> wrote:
>> >>>>> Some time ago I posted to the list regarding a stack overflow error
>> that I was receiving and the advice was to make sure that I didn't have a
>> page storing a reference to another page.
>> >>>>> We did track this down and have just had to ignore it in the
>> production logs. Now we've made it a priority to track this down.
>> >>>>>
>> >>>>> Anyway, we've recently tracked this down to
>> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
>> pasting a url into a new browser window and thus generating a new pagemap.
>> On a certain page the memory consumption doubles as you generate new
>> pagemaps (see the chart below). The profile is indicating that the memory is
>> being taken up by a hashmap, but that's as far as we've been able to trace
>> it so far.
>> >>>>>
>> >>>>>> PageMap # Size Growth
>> >>>>>> 13 389523448 1.93
>> >>>>>> 12 202059096 1.93
>> >>>>>> 11 104804096 1.93
>> >>>>>> 10 54352280 1.93
>> >>>>>> 9 28182760 1.93
>> >>>>>> 8 14594976 1.93
>> >>>>>> 7 7549336 1.94
>> >>>>>> 6 3900704 1.94
>> >>>>>> 5 2013480 2
>> >>>>>> 4 1006960 2
>> >>>>>> 3 503696 2
>> >>>>>> 2 252072 1.86
>> >>>>>> 1 135704
>> >>>>>
>> >>>>>
>> >>>>> Any thoughts or tips on trying to get to the bottom of this one?
>> >>>>>
>> >>>>> Here's the stack trace
>> >>>>>
>> >>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>> Source)
>> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>> Source)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>> >>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>> >>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>> Source)
>> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>> Source)
>> >>>>>> 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)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>
>> >>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>
>> >>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>> >>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
>> Source)
>> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
>> Source)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> >>>>>> 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)
>> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>> >>>>>> at
>> 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:389)
>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Become a Wicket expert, learn from the best:
>> http://wicketinaction.com <http://wicketinaction.com?by-user=t>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2>
>> >>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3>
>> >>>>
>> >>>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4>
>> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6>
>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7>
>>
>>
>>
>> ------------------------------
>> View message @
>> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html
>> To start a new topic under Apache Wicket, email
>> ml-node+1842946-398011874-65838@n4.nabble.com<ml...@n4.nabble.com>
>> To unsubscribe from Apache Wicket, click here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>.
>>
>>
>>
>
>
> --
> Sincerely,
> JC (http://www.linkedin.com/in/jcgarciam)
> Work smarter, not harder!.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.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
>
>
--
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: StackOverflowError
Posted by jcgarciam <jc...@gmail.com>.
Douglas, can you share any insight of how having the session in the property
model could actually provoke this leak?
It seems weird.
On Tue, Nov 16, 2010 at 2:56 PM, Igor Vaynberg-2 [via Apache Wicket] <
ml-node+3045359-698752336-65838@n4.nabble.com<ml...@n4.nabble.com>
> wrote:
> it is perfectly valid to use page as the model object. in fact if you
> wanted to pull something out of session you can simply say new
> PropertyModel(this, "session.property"), this being the Page instance
> you are in.
>
> -igor
>
> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
> <[hidden email] <http://user/SendEmail.jtp?type=node&node=3045359&i=0>>
> wrote:
>
> > We found it.. Finally!!!
> >
> > There was a property model that was using the session as the model
> object.
> >
> > It would be cool if PropertyModel, etc would check for this and blow up
> on construction.
> > i.e. not allow Page, Session, Application as the model object...
> >
> > D/
> > On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
> >
> >> Just tested on 1.4.13 and it still happens
> >>
> >> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
> >>
> >>> 1.4.12, but the problem has been around since a few versions back.
> >>>
> >>> D/
> >>>
> >>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
> >>>
> >>>> Are you using 1.4.13?
> >>>>
> >>>> Martijn
> >>>>
> >>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
> >>>> <[hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=1>>
> wrote:
> >>>>> Some time ago I posted to the list regarding a stack overflow error
> that I was receiving and the advice was to make sure that I didn't have a
> page storing a reference to another page.
> >>>>> We did track this down and have just had to ignore it in the
> production logs. Now we've made it a priority to track this down.
> >>>>>
> >>>>> Anyway, we've recently tracked this down to
> "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by
> pasting a url into a new browser window and thus generating a new pagemap.
> On a certain page the memory consumption doubles as you generate new
> pagemaps (see the chart below). The profile is indicating that the memory is
> being taken up by a hashmap, but that's as far as we've been able to trace
> it so far.
> >>>>>
> >>>>>> PageMap # Size Growth
> >>>>>> 13 389523448 1.93
> >>>>>> 12 202059096 1.93
> >>>>>> 11 104804096 1.93
> >>>>>> 10 54352280 1.93
> >>>>>> 9 28182760 1.93
> >>>>>> 8 14594976 1.93
> >>>>>> 7 7549336 1.94
> >>>>>> 6 3900704 1.94
> >>>>>> 5 2013480 2
> >>>>>> 4 1006960 2
> >>>>>> 3 503696 2
> >>>>>> 2 252072 1.86
> >>>>>> 1 135704
> >>>>>
> >>>>>
> >>>>> Any thoughts or tips on trying to get to the bottom of this one?
> >>>>>
> >>>>> Here's the stack trace
> >>>>>
> >>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
> Source)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> >>>>>> at java.util.LinkedList.writeObject(Unknown Source)
> >>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
> Source)
> >>>>>> 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)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>
> >>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>
> >>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
> >>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)
> >>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
> >>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
> Source)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> >>>>>> 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)
> >>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> >>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> >>>>>> at
> 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:389)
>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Become a Wicket expert, learn from the best:
> http://wicketinaction.com <http://wicketinaction.com?by-user=t>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=2>
> >>>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=3>
> >>>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=4>
> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=5>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=6>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3045359&i=7>
>
>
>
> ------------------------------
> View message @
> http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045359.html
> To start a new topic under Apache Wicket, email
> ml-node+1842946-398011874-65838@n4.nabble.com<ml...@n4.nabble.com>
> To unsubscribe from Apache Wicket, click here<http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>.
>
>
>
--
Sincerely,
JC (http://www.linkedin.com/in/jcgarciam)
Work smarter, not harder!.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-tp3044241p3045367.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: StackOverflowError
Posted by Martin Funk <ma...@googlemail.com>.
2010/11/16 Douglas Ferguson <do...@douglasferguson.us>
> so I guess it knows not to serialize itself again if it sees it in a model?
>
close....
'this' is the page it gets serialized anyway.
and "session.property" gets transformed into a
'getSession().getProperty()" whenever PropertyModel.getObject() is called.
mf
>
> On Nov 16, 2010, at 11:55 AM, Igor Vaynberg wrote:
>
> > PropertyModel(this, "session.property"), this being the Page instance
> > you are in.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
so I guess it knows not to serialize itself again if it sees it in a model?
On Nov 16, 2010, at 11:55 AM, Igor Vaynberg wrote:
> PropertyModel(this, "session.property"), this being the Page instance
> you are in.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Igor Vaynberg <ig...@gmail.com>.
it is perfectly valid to use page as the model object. in fact if you
wanted to pull something out of session you can simply say new
PropertyModel(this, "session.property"), this being the Page instance
you are in.
-igor
On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> We found it.. Finally!!!
>
> There was a property model that was using the session as the model object.
>
> It would be cool if PropertyModel, etc would check for this and blow up on construction.
> i.e. not allow Page, Session, Application as the model object...
>
> D/
> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>
>> Just tested on 1.4.13 and it still happens
>>
>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>
>>> 1.4.12, but the problem has been around since a few versions back.
>>>
>>> D/
>>>
>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>
>>>> Are you using 1.4.13?
>>>>
>>>> Martijn
>>>>
>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>> <do...@buzzstream.com> wrote:
>>>>> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
>>>>> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>>>>>
>>>>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>>>>>
>>>>>> PageMap # Size Growth
>>>>>> 13 389523448 1.93
>>>>>> 12 202059096 1.93
>>>>>> 11 104804096 1.93
>>>>>> 10 54352280 1.93
>>>>>> 9 28182760 1.93
>>>>>> 8 14594976 1.93
>>>>>> 7 7549336 1.94
>>>>>> 6 3900704 1.94
>>>>>> 5 2013480 2
>>>>>> 4 1006960 2
>>>>>> 3 503696 2
>>>>>> 2 252072 1.86
>>>>>> 1 135704
>>>>>
>>>>>
>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>
>>>>> Here's the stack trace
>>>>>
>>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> 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)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>> at 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:389)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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: StackOverflowError
Posted by Erik van Oosten <e....@grons.nl>.
I have seen an application (not mine!) fail horribly and costly on the second
example.
The problem with getting an object from the session and passing the reference to
a (Compound)PropertyModel is that the natural assumption, the session object is
updated too, is wrong.
So this is exactly the same problem as keeping a reference to the session
itself, only now restricted to less data.
Regards,
Erik.
Op 22-11-10 20:51, Igor Vaynberg schreef:
> no. the example below doesnt hit any pitfalls because it doesnt
> reference the session itself. as long as objects retrieved from
> session do not contain references back to session he is ok.
>
> however, declaring Session instance as final is not a good idea
> because it makes it easy to reference it in anonymous classes.
>
> -igor
>
> On Mon, Nov 22, 2010 at 11:49 AM, Erik van Oosten<e....@grons.nl> wrote:
>> Yes, both are very wrong.
>>
>> Pitfalls are in earlier messages in this thread.
>>
>>
>> On 22-11-10 16:36, MZemeck@osc.state.ny.us wrote:
>>> By "keep a reference to the session in their class" do you mean something
>>> like this?
>>>
>>> Are there any pitfalls to doing this?
>>>
>>> final Session session = getSession();
>>> add(new Label("userNameLabel", new Model(session.getUser
>>> ().getUserName())));
>>>
>>> How about this?
>>> final UserDTO dto = session.getUser();
>>> CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
>>>
--
Sent from my SMTP compliant software
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Igor Vaynberg <ig...@gmail.com>.
no. the example below doesnt hit any pitfalls because it doesnt
reference the session itself. as long as objects retrieved from
session do not contain references back to session he is ok.
however, declaring Session instance as final is not a good idea
because it makes it easy to reference it in anonymous classes.
-igor
On Mon, Nov 22, 2010 at 11:49 AM, Erik van Oosten <e....@grons.nl> wrote:
> Yes, both are very wrong.
>
> Pitfalls are in earlier messages in this thread.
>
>
> On 22-11-10 16:36, MZemeck@osc.state.ny.us wrote:
>>
>> By "keep a reference to the session in their class" do you mean something
>> like this?
>>
>> Are there any pitfalls to doing this?
>>
>> final Session session = getSession();
>> add(new Label("userNameLabel", new Model(session.getUser
>> ().getUserName())));
>>
>> How about this?
>> final UserDTO dto = session.getUser();
>> CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
>>
>
> --
> Sent from my SMTP compliant software
> Erik van Oosten
> http://day-to-day-stuff.blogspot.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: StackOverflowError
Posted by Erik van Oosten <e....@grons.nl>.
Yes, both are very wrong.
Pitfalls are in earlier messages in this thread.
On 22-11-10 16:36, MZemeck@osc.state.ny.us wrote:
> By "keep a reference to the session in their class" do you mean something
> like this?
>
> Are there any pitfalls to doing this?
>
> final Session session = getSession();
> add(new Label("userNameLabel", new Model(session.getUser
> ().getUserName())));
>
> How about this?
> final UserDTO dto = session.getUser();
> CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
>
--
Sent from my SMTP compliant software
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by MZ...@osc.state.ny.us.
By "keep a reference to the session in their class" do you mean something
like this?
Are there any pitfalls to doing this?
final Session session = getSession();
add(new Label("userNameLabel", new Model(session.getUser
().getUserName())));
How about this?
final UserDTO dto = session.getUser();
CompoundPropertyModel cpm = new CompoundPropertyModel(dto);
From: Martijn Dashorst <ma...@gmail.com>
To: users@wicket.apache.org
Date: 11/20/2010 12:02 PM
Subject: Re: StackOverflowError
Problem is that there's no single super constructor. For Wicket all
really matters is the IModel interface of which many implementations
exist outside wicket as well. And it is of course not only the model
that is dangerous. Folks can easily keep a reference to the session in
their class, or make a local variable final and reference that inside
an anon-inner class.
It is not possible to make this water tight. As you are about the
first company running into this issue, I'd say it is not worth the
effort trying to fix it.
What we might do is add a check in the serializable checker and ensure
no wicket session ends up in the tree.
Martijn
On Sat, Nov 20, 2010 at 2:27 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> Why not just throw and illegal argument exception when you try to create
a model with a session?
>
> D/
>
> On Nov 19, 2010, at 3:16 AM, Erik van Oosten wrote:
>
>> Pedro's solution allows you to turn serialisation on and off for a
given thread so you won't mess with serialisation by other users (such as
the servlet container).
>>
>> Clever. The only missing piece is an override of the default
serialisation to temporarily flip the switch.
>>
>> Still, in core it would be much more useful. Users that can configure
this kind of tricks don't tend to make the mistake of referring a session
anyway.
>>
>> Regards,
>> Erik.
>>
>>
>> Op 18-11-10 18:31, Martijn Dashorst schreef:
>>> Sessions are meant to be serialized. That's the way they travel
>>> through a cluster, or how sessions are preserved during a server
>>> restart. I'd like to not break that by adding this functionality.
>>>
>>> Martijn
>>>
>>> On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos<pe...@gmail.com>
wrote:
>>>> Ok, I still don't know how interest is to have it in the core. You
can do it
>>>> at an session extension, like:
>>>>
>>>> 1- providing some API
>>>>
>>>> MySession extends Session{
>>>> private ThreadLocal<Object> sessionSerializationRestrictor = new
>>>> ThreadLocal<Object>();
>>>> public void inhibitSerializationOnThread(Object restrictor){
>>>> sessionSerializationRestrictor.set(restrictor); }
>>>>
>>>> public void removeSerializationRestriction(){
>>>> sessionSerializationRestrictor.set(null); }
>>>>
>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>> IOException {
>>>> if (sessionSerializationRestrictor.get() != null) {
>>>> throw some exception explaining that the restrictor do not
allow
>>>> this serialization;
>>>> } else {
>>>> out.defaultWriteObject();
>>>> } }}
>>>>
>>>> 2- providing some Page.IPageSerializer that calls
>>>> inhibitSerializationOnThread and removeSerializationRestriction
before and
>>>> after the page serialization.
>>>>
>>>> On Thu, Nov 18, 2010 at 6:48 AM, Erik van
Oosten<e....@grons.nl>wrote:
>>>>
>>>>> That won't work in general as some servlet containers (like tomcat)
>>>>> serialise the session to disk when its idle for too long.
>>>>>
>>>>> What I meant is that when the page is serialised, it _must_ not
contain a
>>>>> reference to session.
>>>>>
>>>>>
>>>>> but than some other developers can complain because they are
deliberated
>>>>>> serialializing some session.
>>>>>>
>>>>> They won't complain when the exception text specifies why this is
wrong.
>>>>> See Martijn's e-mail in this discussion thread for why it is wrong.
>>>>>
>>>>> Regards,
>>>>> Erik.
>>>>>
>>>>>
>>>>> Op 17-11-10 21:05, Pedro Santos schreef:
>>>>>
>>>>> I think it is to specific. You can override the Session on your app
an
>>>>>> catch
>>>>>> this situation like:
>>>>>>
>>>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>>>> IOException {
>>>>>> if (Application.get() != null&&
>>>>>>
Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>>>>>> log.info("Session is being serialized in the
development
>>>>>> environment, which is an not a desirable behavior.");
>>>>>> }}
>>>>>>
>>>>>> but than some other developers can complain because they are
deliberated
>>>>>> serialializing some session.
>>>>>>
>>>>>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van
Oosten<e.vanoosten@grons.nl
>>>>>>> wrote:
>>>>>>> Shouldn't serialization fail when it references
session/application?
>>>>>>> Perhaps only in development mode.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Erik.
>>>>>>>
>>>>>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>>>>>
>>>>>>> added a log warning to property models when they reference
session.
>>>>>>>
>>
>> --
>> Sent from my SMTP compliant software
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.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
>
>
--
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
Notice: This communication, including any attachments, is intended solely
for the use of the individual or entity to which it is addressed. This
communication may contain information that is protected from disclosure
under State and/or Federal law. Please notify the sender immediately if
you have received this communication in error and delete this email from
your system. If you are not the intended recipient, you are requested not
to disclose, copy, distribute or take any action in reliance on the
contents of this information.
Re: StackOverflowError
Posted by Martijn Dashorst <ma...@gmail.com>.
Problem is that there's no single super constructor. For Wicket all
really matters is the IModel interface of which many implementations
exist outside wicket as well. And it is of course not only the model
that is dangerous. Folks can easily keep a reference to the session in
their class, or make a local variable final and reference that inside
an anon-inner class.
It is not possible to make this water tight. As you are about the
first company running into this issue, I'd say it is not worth the
effort trying to fix it.
What we might do is add a check in the serializable checker and ensure
no wicket session ends up in the tree.
Martijn
On Sat, Nov 20, 2010 at 2:27 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> Why not just throw and illegal argument exception when you try to create a model with a session?
>
> D/
>
> On Nov 19, 2010, at 3:16 AM, Erik van Oosten wrote:
>
>> Pedro's solution allows you to turn serialisation on and off for a given thread so you won't mess with serialisation by other users (such as the servlet container).
>>
>> Clever. The only missing piece is an override of the default serialisation to temporarily flip the switch.
>>
>> Still, in core it would be much more useful. Users that can configure this kind of tricks don't tend to make the mistake of referring a session anyway.
>>
>> Regards,
>> Erik.
>>
>>
>> Op 18-11-10 18:31, Martijn Dashorst schreef:
>>> Sessions are meant to be serialized. That's the way they travel
>>> through a cluster, or how sessions are preserved during a server
>>> restart. I'd like to not break that by adding this functionality.
>>>
>>> Martijn
>>>
>>> On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos<pe...@gmail.com> wrote:
>>>> Ok, I still don't know how interest is to have it in the core. You can do it
>>>> at an session extension, like:
>>>>
>>>> 1- providing some API
>>>>
>>>> MySession extends Session{
>>>> private ThreadLocal<Object> sessionSerializationRestrictor = new
>>>> ThreadLocal<Object>();
>>>> public void inhibitSerializationOnThread(Object restrictor){
>>>> sessionSerializationRestrictor.set(restrictor); }
>>>>
>>>> public void removeSerializationRestriction(){
>>>> sessionSerializationRestrictor.set(null); }
>>>>
>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>> IOException {
>>>> if (sessionSerializationRestrictor.get() != null) {
>>>> throw some exception explaining that the restrictor do not allow
>>>> this serialization;
>>>> } else {
>>>> out.defaultWriteObject();
>>>> } }}
>>>>
>>>> 2- providing some Page.IPageSerializer that calls
>>>> inhibitSerializationOnThread and removeSerializationRestriction before and
>>>> after the page serialization.
>>>>
>>>> On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten<e....@grons.nl>wrote:
>>>>
>>>>> That won't work in general as some servlet containers (like tomcat)
>>>>> serialise the session to disk when its idle for too long.
>>>>>
>>>>> What I meant is that when the page is serialised, it _must_ not contain a
>>>>> reference to session.
>>>>>
>>>>>
>>>>> but than some other developers can complain because they are deliberated
>>>>>> serialializing some session.
>>>>>>
>>>>> They won't complain when the exception text specifies why this is wrong.
>>>>> See Martijn's e-mail in this discussion thread for why it is wrong.
>>>>>
>>>>> Regards,
>>>>> Erik.
>>>>>
>>>>>
>>>>> Op 17-11-10 21:05, Pedro Santos schreef:
>>>>>
>>>>> I think it is to specific. You can override the Session on your app an
>>>>>> catch
>>>>>> this situation like:
>>>>>>
>>>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>>>> IOException {
>>>>>> if (Application.get() != null&&
>>>>>> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>>>>>> log.info("Session is being serialized in the development
>>>>>> environment, which is an not a desirable behavior.");
>>>>>> }}
>>>>>>
>>>>>> but than some other developers can complain because they are deliberated
>>>>>> serialializing some session.
>>>>>>
>>>>>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoosten@grons.nl
>>>>>>> wrote:
>>>>>>> Shouldn't serialization fail when it references session/application?
>>>>>>> Perhaps only in development mode.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Erik.
>>>>>>>
>>>>>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>>>>>
>>>>>>> added a log warning to property models when they reference session.
>>>>>>>
>>
>> --
>> Sent from my SMTP compliant software
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.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
>
>
--
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: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
Why not just throw and illegal argument exception when you try to create a model with a session?
D/
On Nov 19, 2010, at 3:16 AM, Erik van Oosten wrote:
> Pedro's solution allows you to turn serialisation on and off for a given thread so you won't mess with serialisation by other users (such as the servlet container).
>
> Clever. The only missing piece is an override of the default serialisation to temporarily flip the switch.
>
> Still, in core it would be much more useful. Users that can configure this kind of tricks don't tend to make the mistake of referring a session anyway.
>
> Regards,
> Erik.
>
>
> Op 18-11-10 18:31, Martijn Dashorst schreef:
>> Sessions are meant to be serialized. That's the way they travel
>> through a cluster, or how sessions are preserved during a server
>> restart. I'd like to not break that by adding this functionality.
>>
>> Martijn
>>
>> On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos<pe...@gmail.com> wrote:
>>> Ok, I still don't know how interest is to have it in the core. You can do it
>>> at an session extension, like:
>>>
>>> 1- providing some API
>>>
>>> MySession extends Session{
>>> private ThreadLocal<Object> sessionSerializationRestrictor = new
>>> ThreadLocal<Object>();
>>> public void inhibitSerializationOnThread(Object restrictor){
>>> sessionSerializationRestrictor.set(restrictor); }
>>>
>>> public void removeSerializationRestriction(){
>>> sessionSerializationRestrictor.set(null); }
>>>
>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>> IOException {
>>> if (sessionSerializationRestrictor.get() != null) {
>>> throw some exception explaining that the restrictor do not allow
>>> this serialization;
>>> } else {
>>> out.defaultWriteObject();
>>> } }}
>>>
>>> 2- providing some Page.IPageSerializer that calls
>>> inhibitSerializationOnThread and removeSerializationRestriction before and
>>> after the page serialization.
>>>
>>> On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten<e....@grons.nl>wrote:
>>>
>>>> That won't work in general as some servlet containers (like tomcat)
>>>> serialise the session to disk when its idle for too long.
>>>>
>>>> What I meant is that when the page is serialised, it _must_ not contain a
>>>> reference to session.
>>>>
>>>>
>>>> but than some other developers can complain because they are deliberated
>>>>> serialializing some session.
>>>>>
>>>> They won't complain when the exception text specifies why this is wrong.
>>>> See Martijn's e-mail in this discussion thread for why it is wrong.
>>>>
>>>> Regards,
>>>> Erik.
>>>>
>>>>
>>>> Op 17-11-10 21:05, Pedro Santos schreef:
>>>>
>>>> I think it is to specific. You can override the Session on your app an
>>>>> catch
>>>>> this situation like:
>>>>>
>>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>>> IOException {
>>>>> if (Application.get() != null&&
>>>>> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>>>>> log.info("Session is being serialized in the development
>>>>> environment, which is an not a desirable behavior.");
>>>>> }}
>>>>>
>>>>> but than some other developers can complain because they are deliberated
>>>>> serialializing some session.
>>>>>
>>>>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoosten@grons.nl
>>>>>> wrote:
>>>>>> Shouldn't serialization fail when it references session/application?
>>>>>> Perhaps only in development mode.
>>>>>>
>>>>>> Regards,
>>>>>> Erik.
>>>>>>
>>>>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>>>>
>>>>>> added a log warning to property models when they reference session.
>>>>>>
>
> --
> Sent from my SMTP compliant software
> Erik van Oosten
> http://day-to-day-stuff.blogspot.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: StackOverflowError
Posted by Erik van Oosten <e....@grons.nl>.
Pedro's solution allows you to turn serialisation on and off for a given thread
so you won't mess with serialisation by other users (such as the servlet container).
Clever. The only missing piece is an override of the default serialisation to
temporarily flip the switch.
Still, in core it would be much more useful. Users that can configure this kind
of tricks don't tend to make the mistake of referring a session anyway.
Regards,
Erik.
Op 18-11-10 18:31, Martijn Dashorst schreef:
> Sessions are meant to be serialized. That's the way they travel
> through a cluster, or how sessions are preserved during a server
> restart. I'd like to not break that by adding this functionality.
>
> Martijn
>
> On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos<pe...@gmail.com> wrote:
>> Ok, I still don't know how interest is to have it in the core. You can do it
>> at an session extension, like:
>>
>> 1- providing some API
>>
>> MySession extends Session{
>> private ThreadLocal<Object> sessionSerializationRestrictor = new
>> ThreadLocal<Object>();
>> public void inhibitSerializationOnThread(Object restrictor){
>> sessionSerializationRestrictor.set(restrictor); }
>>
>> public void removeSerializationRestriction(){
>> sessionSerializationRestrictor.set(null); }
>>
>> private void writeObject(java.io.ObjectOutputStream out) throws
>> IOException {
>> if (sessionSerializationRestrictor.get() != null) {
>> throw some exception explaining that the restrictor do not allow
>> this serialization;
>> } else {
>> out.defaultWriteObject();
>> } }}
>>
>> 2- providing some Page.IPageSerializer that calls
>> inhibitSerializationOnThread and removeSerializationRestriction before and
>> after the page serialization.
>>
>> On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten<e....@grons.nl>wrote:
>>
>>> That won't work in general as some servlet containers (like tomcat)
>>> serialise the session to disk when its idle for too long.
>>>
>>> What I meant is that when the page is serialised, it _must_ not contain a
>>> reference to session.
>>>
>>>
>>> but than some other developers can complain because they are deliberated
>>>> serialializing some session.
>>>>
>>> They won't complain when the exception text specifies why this is wrong.
>>> See Martijn's e-mail in this discussion thread for why it is wrong.
>>>
>>> Regards,
>>> Erik.
>>>
>>>
>>> Op 17-11-10 21:05, Pedro Santos schreef:
>>>
>>> I think it is to specific. You can override the Session on your app an
>>>> catch
>>>> this situation like:
>>>>
>>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>>> IOException {
>>>> if (Application.get() != null&&
>>>> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>>>> log.info("Session is being serialized in the development
>>>> environment, which is an not a desirable behavior.");
>>>> }}
>>>>
>>>> but than some other developers can complain because they are deliberated
>>>> serialializing some session.
>>>>
>>>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoosten@grons.nl
>>>>> wrote:
>>>>> Shouldn't serialization fail when it references session/application?
>>>>> Perhaps only in development mode.
>>>>>
>>>>> Regards,
>>>>> Erik.
>>>>>
>>>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>>>
>>>>> added a log warning to property models when they reference session.
>>>>>
--
Sent from my SMTP compliant software
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Martijn Dashorst <ma...@gmail.com>.
Sessions are meant to be serialized. That's the way they travel
through a cluster, or how sessions are preserved during a server
restart. I'd like to not break that by adding this functionality.
Martijn
On Thu, Nov 18, 2010 at 6:19 PM, Pedro Santos <pe...@gmail.com> wrote:
> Ok, I still don't know how interest is to have it in the core. You can do it
> at an session extension, like:
>
> 1- providing some API
>
> MySession extends Session{
> private ThreadLocal<Object> sessionSerializationRestrictor = new
> ThreadLocal<Object>();
> public void inhibitSerializationOnThread(Object restrictor){
> sessionSerializationRestrictor.set(restrictor); }
>
> public void removeSerializationRestriction(){
> sessionSerializationRestrictor.set(null); }
>
> private void writeObject(java.io.ObjectOutputStream out) throws
> IOException {
> if (sessionSerializationRestrictor.get() != null) {
> throw some exception explaining that the restrictor do not allow
> this serialization;
> } else {
> out.defaultWriteObject();
> } }}
>
> 2- providing some Page.IPageSerializer that calls
> inhibitSerializationOnThread and removeSerializationRestriction before and
> after the page serialization.
>
> On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten <e....@grons.nl>wrote:
>
>> That won't work in general as some servlet containers (like tomcat)
>> serialise the session to disk when its idle for too long.
>>
>> What I meant is that when the page is serialised, it _must_ not contain a
>> reference to session.
>>
>>
>> but than some other developers can complain because they are deliberated
>>> serialializing some session.
>>>
>> They won't complain when the exception text specifies why this is wrong.
>> See Martijn's e-mail in this discussion thread for why it is wrong.
>>
>> Regards,
>> Erik.
>>
>>
>> Op 17-11-10 21:05, Pedro Santos schreef:
>>
>> I think it is to specific. You can override the Session on your app an
>>> catch
>>> this situation like:
>>>
>>> private void writeObject(java.io.ObjectOutputStream out) throws
>>> IOException {
>>> if (Application.get() != null&&
>>> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>>> log.info("Session is being serialized in the development
>>> environment, which is an not a desirable behavior.");
>>> }}
>>>
>>> but than some other developers can complain because they are deliberated
>>> serialializing some session.
>>>
>>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoosten@grons.nl
>>> >wrote:
>>>
>>>> Shouldn't serialization fail when it references session/application?
>>>> Perhaps only in development mode.
>>>>
>>>> Regards,
>>>> Erik.
>>>>
>>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>>
>>>> added a log warning to property models when they reference session.
>>>>
>>>
>> --
>> Sent from my SMTP compliant software
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.com/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
--
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: StackOverflowError
Posted by Pedro Santos <pe...@gmail.com>.
Ok, I still don't know how interest is to have it in the core. You can do it
at an session extension, like:
1- providing some API
MySession extends Session{
private ThreadLocal<Object> sessionSerializationRestrictor = new
ThreadLocal<Object>();
public void inhibitSerializationOnThread(Object restrictor){
sessionSerializationRestrictor.set(restrictor); }
public void removeSerializationRestriction(){
sessionSerializationRestrictor.set(null); }
private void writeObject(java.io.ObjectOutputStream out) throws
IOException {
if (sessionSerializationRestrictor.get() != null) {
throw some exception explaining that the restrictor do not allow
this serialization;
} else {
out.defaultWriteObject();
} }}
2- providing some Page.IPageSerializer that calls
inhibitSerializationOnThread and removeSerializationRestriction before and
after the page serialization.
On Thu, Nov 18, 2010 at 6:48 AM, Erik van Oosten <e....@grons.nl>wrote:
> That won't work in general as some servlet containers (like tomcat)
> serialise the session to disk when its idle for too long.
>
> What I meant is that when the page is serialised, it _must_ not contain a
> reference to session.
>
>
> but than some other developers can complain because they are deliberated
>> serialializing some session.
>>
> They won't complain when the exception text specifies why this is wrong.
> See Martijn's e-mail in this discussion thread for why it is wrong.
>
> Regards,
> Erik.
>
>
> Op 17-11-10 21:05, Pedro Santos schreef:
>
> I think it is to specific. You can override the Session on your app an
>> catch
>> this situation like:
>>
>> private void writeObject(java.io.ObjectOutputStream out) throws
>> IOException {
>> if (Application.get() != null&&
>> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
>> log.info("Session is being serialized in the development
>> environment, which is an not a desirable behavior.");
>> }}
>>
>> but than some other developers can complain because they are deliberated
>> serialializing some session.
>>
>> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e.vanoosten@grons.nl
>> >wrote:
>>
>>> Shouldn't serialization fail when it references session/application?
>>> Perhaps only in development mode.
>>>
>>> Regards,
>>> Erik.
>>>
>>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>>
>>> added a log warning to property models when they reference session.
>>>
>>
> --
> Sent from my SMTP compliant software
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: StackOverflowError
Posted by Erik van Oosten <e....@grons.nl>.
That won't work in general as some servlet containers (like tomcat) serialise
the session to disk when its idle for too long.
What I meant is that when the page is serialised, it _must_ not contain a
reference to session.
> but than some other developers can complain because they are deliberated
> serialializing some session.
They won't complain when the exception text specifies why this is wrong. See
Martijn's e-mail in this discussion thread for why it is wrong.
Regards,
Erik.
Op 17-11-10 21:05, Pedro Santos schreef:
> I think it is to specific. You can override the Session on your app an catch
> this situation like:
>
> private void writeObject(java.io.ObjectOutputStream out) throws
> IOException {
> if (Application.get() != null&&
> Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
> log.info("Session is being serialized in the development
> environment, which is an not a desirable behavior.");
> }}
>
> but than some other developers can complain because they are deliberated
> serialializing some session.
>
> On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten<e....@grons.nl>wrote:
>> Shouldn't serialization fail when it references session/application?
>> Perhaps only in development mode.
>>
>> Regards,
>> Erik.
>>
>> Op 16-11-10 19:03, Igor Vaynberg schreef:
>>
>> added a log warning to property models when they reference session.
--
Sent from my SMTP compliant software
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Pedro Santos <pe...@gmail.com>.
I think it is to specific. You can override the Session on your app an catch
this situation like:
private void writeObject(java.io.ObjectOutputStream out) throws
IOException {
if (Application.get() != null &&
Application.get().getConfigurationType().equals(Application.DEPLOYMENT)) {
log.info("Session is being serialized in the development
environment, which is an not a desirable behavior.");
}}
but than some other developers can complain because they are deliberated
serialializing some session.
On Wed, Nov 17, 2010 at 4:49 PM, Erik van Oosten <e....@grons.nl>wrote:
> Shouldn't serialization fail when it references session/application?
> Perhaps only in development mode.
>
> Regards,
> Erik.
>
> Op 16-11-10 19:03, Igor Vaynberg schreef:
>
> added a log warning to property models when they reference session.
>>
>> -igor
>>
>> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>
>>> We found it.. Finally!!!
>>>
>>> There was a property model that was using the session as the model
>>> object.
>>>
>>> It would be cool if PropertyModel, etc would check for this and blow up
>>> on construction.
>>> i.e. not allow Page, Session, Application as the model object...
>>>
>>
>>
>
> --
> Erik van Oosten
> http://www.day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: StackOverflowError
Posted by Erik van Oosten <e....@grons.nl>.
Shouldn't serialization fail when it references session/application?
Perhaps only in development mode.
Regards,
Erik.
Op 16-11-10 19:03, Igor Vaynberg schreef:
> added a log warning to property models when they reference session.
>
> -igor
>
> On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> We found it.. Finally!!!
>>
>> There was a property model that was using the session as the model object.
>>
>> It would be cool if PropertyModel, etc would check for this and blow up on construction.
>> i.e. not allow Page, Session, Application as the model object...
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Igor Vaynberg <ig...@gmail.com>.
added a log warning to property models when they reference session.
-igor
On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> We found it.. Finally!!!
>
> There was a property model that was using the session as the model object.
>
> It would be cool if PropertyModel, etc would check for this and blow up on construction.
> i.e. not allow Page, Session, Application as the model object...
>
> D/
> On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
>
>> Just tested on 1.4.13 and it still happens
>>
>> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>>
>>> 1.4.12, but the problem has been around since a few versions back.
>>>
>>> D/
>>>
>>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>>
>>>> Are you using 1.4.13?
>>>>
>>>> Martijn
>>>>
>>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>>> <do...@buzzstream.com> wrote:
>>>>> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
>>>>> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>>>>>
>>>>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>>>>>
>>>>>> PageMap # Size Growth
>>>>>> 13 389523448 1.93
>>>>>> 12 202059096 1.93
>>>>>> 11 104804096 1.93
>>>>>> 10 54352280 1.93
>>>>>> 9 28182760 1.93
>>>>>> 8 14594976 1.93
>>>>>> 7 7549336 1.94
>>>>>> 6 3900704 1.94
>>>>>> 5 2013480 2
>>>>>> 4 1006960 2
>>>>>> 3 503696 2
>>>>>> 2 252072 1.86
>>>>>> 1 135704
>>>>>
>>>>>
>>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>>
>>>>> Here's the stack trace
>>>>>
>>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> 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)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>>> 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)
>>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>>> at 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:389)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> 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: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
We found it.. Finally!!!
There was a property model that was using the session as the model object.
It would be cool if PropertyModel, etc would check for this and blow up on construction.
i.e. not allow Page, Session, Application as the model object...
D/
On Nov 16, 2010, at 11:20 AM, Douglas Ferguson wrote:
> Just tested on 1.4.13 and it still happens
>
> On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
>
>> 1.4.12, but the problem has been around since a few versions back.
>>
>> D/
>>
>> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>>
>>> Are you using 1.4.13?
>>>
>>> Martijn
>>>
>>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>>> <do...@buzzstream.com> wrote:
>>>> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
>>>> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>>>>
>>>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>>>>
>>>>> PageMap # Size Growth
>>>>> 13 389523448 1.93
>>>>> 12 202059096 1.93
>>>>> 11 104804096 1.93
>>>>> 10 54352280 1.93
>>>>> 9 28182760 1.93
>>>>> 8 14594976 1.93
>>>>> 7 7549336 1.94
>>>>> 6 3900704 1.94
>>>>> 5 2013480 2
>>>>> 4 1006960 2
>>>>> 3 503696 2
>>>>> 2 252072 1.86
>>>>> 1 135704
>>>>
>>>>
>>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>>
>>>> Here's the stack trace
>>>>
>>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>> 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)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>>> 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)
>>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>>> at 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:389)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
Just tested on 1.4.13 and it still happens
On Nov 16, 2010, at 9:43 AM, Douglas Ferguson wrote:
> 1.4.12, but the problem has been around since a few versions back.
>
> D/
>
> On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
>
>> Are you using 1.4.13?
>>
>> Martijn
>>
>> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
>> <do...@buzzstream.com> wrote:
>>> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
>>> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>>>
>>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>>>
>>>> PageMap # Size Growth
>>>> 13 389523448 1.93
>>>> 12 202059096 1.93
>>>> 11 104804096 1.93
>>>> 10 54352280 1.93
>>>> 9 28182760 1.93
>>>> 8 14594976 1.93
>>>> 7 7549336 1.94
>>>> 6 3900704 1.94
>>>> 5 2013480 2
>>>> 4 1006960 2
>>>> 3 503696 2
>>>> 2 252072 1.86
>>>> 1 135704
>>>
>>>
>>> Any thoughts or tips on trying to get to the bottom of this one?
>>>
>>> Here's the stack trace
>>>
>>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>> at java.util.LinkedList.writeObject(Unknown Source)
>>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>> 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)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>>> 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)
>>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>>> at 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:389)
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Douglas Ferguson <do...@douglasferguson.us>.
1.4.12, but the problem has been around since a few versions back.
D/
On Nov 16, 2010, at 12:43 AM, Martijn Dashorst wrote:
> Are you using 1.4.13?
>
> Martijn
>
> On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
> <do...@buzzstream.com> wrote:
>> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
>> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>>
>> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>>
>>> PageMap # Size Growth
>>> 13 389523448 1.93
>>> 12 202059096 1.93
>>> 11 104804096 1.93
>>> 10 54352280 1.93
>>> 9 28182760 1.93
>>> 8 14594976 1.93
>>> 7 7549336 1.94
>>> 6 3900704 1.94
>>> 5 2013480 2
>>> 4 1006960 2
>>> 3 503696 2
>>> 2 252072 1.86
>>> 1 135704
>>
>>
>> Any thoughts or tips on trying to get to the bottom of this one?
>>
>> Here's the stack trace
>>
>>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>> at java.util.LinkedList.writeObject(Unknown Source)
>>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>> 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)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>> at java.lang.reflect.Method.invoke(Unknown Source)
>>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>>> 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)
>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>>> at 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:389)
>>
>>
>>
>>
>
>
>
> --
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StackOverflowError
Posted by Martijn Dashorst <ma...@gmail.com>.
Are you using 1.4.13?
Martijn
On Tue, Nov 16, 2010 at 5:54 AM, Douglas Ferguson
<do...@buzzstream.com> wrote:
> Some time ago I posted to the list regarding a stack overflow error that I was receiving and the advice was to make sure that I didn't have a page storing a reference to another page.
> We did track this down and have just had to ignore it in the production logs. Now we've made it a priority to track this down.
>
> Anyway, we've recently tracked this down to "AutomaticMultiWindowSupport" feature. We are able to recreate the bug by pasting a url into a new browser window and thus generating a new pagemap. On a certain page the memory consumption doubles as you generate new pagemaps (see the chart below). The profile is indicating that the memory is being taken up by a hashmap, but that's as far as we've been able to trace it so far.
>
>> PageMap # Size Growth
>> 13 389523448 1.93
>> 12 202059096 1.93
>> 11 104804096 1.93
>> 10 54352280 1.93
>> 9 28182760 1.93
>> 8 14594976 1.93
>> 7 7549336 1.94
>> 6 3900704 1.94
>> 5 2013480 2
>> 4 1006960 2
>> 3 503696 2
>> 2 252072 1.86
>> 1 135704
>
>
> Any thoughts or tips on trying to get to the bottom of this one?
>
> Here's the stack trace
>
>> at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>> at java.util.LinkedList.writeObject(Unknown Source)
>> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>> 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)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
>> at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
>> at org.apache.wicket.Component.writeObject(Component.java:4660)
>> at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
>> 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)
>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
>> at 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:389)
>
>
>
>
--
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