Re: StackOverflowError in session creation
OhI made a stupid mistakesorry for that and thanks for solving my problem... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverflowError-in-session-creation-tp4516170p4521161.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError in session creation
On Thu, Mar 29, 2012 at 10:49 PM, kshitiz k.agarw...@gmail.com wrote:
Hi,
I am trying to save an object in a session like this:
public class Login extends BasePage {
private static final long serialVersionUID = 1L;
UserDomain userDomain = new UserDomain();
public Login()
{
// form
*StatelessForm loginForm = new StatelessForm (loginForm, new
CompoundPropertyModel(userDomain));*
add(loginForm);
// emailId field
Label emailIdLabel = new Label(emailIdLabel, EmailId);
loginForm.add(emailIdLabel);
final RequiredTextField emailId = new RequiredTextField(emailId);
loginForm.add(emailId);
emailId.add(EmailAddressValidator.getInstance());
// password field
Label passwordLabel = new Label(passwordLabel, Password);
loginForm.add(passwordLabel);
final PasswordTextField password = new
PasswordTextField(password);
loginForm.add(password);
Button submitButton = new Button(submitButton) {
/**
*
*/
private static final long serialVersionUID = 1L;
@Override
public void onSubmit() {
userDomain.setBlocked(true);
userDomain.setEmaild(emailId.getValue());
userDomain.setPassword(password.getValue());
UserService userService = new UserService();
userDomain = userService.login(userDomain);
* MySession.get().setMyObject(userDomain);*
setResponsePage(Home.class);
}
};
loginForm.add(submitButton);
}
}
My session class is:
public class MySession extends WebSession{
/**
*
*/
private static final long serialVersionUID = 1L;
public MySession(Request request) {
super(request);
// TODO Auto-generated constructor stub
}
private Object myObject;
public final Object getMyObject() {
return myObject;
}
public final void setMyObject(Object myObject) {
this.myObject = myObject;
}
// if you use java = 1.5 you can make use of covariant return types
* public static MySession get() {
// return (MySession)MySession.get(); --infinite recursion
return (MySession)Session.get();
* }
}
But whenver I try to login into the app, I get the following error:
WicketMessage: Method onFormSubmitted of interface
org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component
[MarkupContainer [Component id = loginForm]] threw an exception
Root cause:
java.lang.StackOverflowError
*at WalknShine.MySession.get(MySession.java:34)*
at WalknShine.MySession.get(MySession.java:34)
at WalknShine.MySession.get(MySession.java:34)
...
Complete stack:
org.apache.wicket.WicketRuntimeException: Method onFormSubmitted of
interface org.apache.wicket.markup.html.form.IFormSubmitListener targeted at
component [MarkupContainer [Component id = loginForm]] threw an exception
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:193)
at
org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:161)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1252)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1331)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1438)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:546)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:486)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:182)
at
org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:161)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1252)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1331)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1438)
at
Re: StackOverflowError
Yes, both are very wrong. Pitfalls are in earlier messages in this thread. On 22-11-10 16:36, mzem...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
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.vanoos...@grons.nl wrote: Yes, both are very wrong. Pitfalls are in earlier messages in this thread. On 22-11-10 16:36, mzem...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
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 Oostene.vanoos...@grons.nl wrote: Yes, both are very wrong. Pitfalls are in earlier messages in this thread. On 22-11-10 16:36, mzem...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError
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 doug...@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 #SizeGrowth 133895234481.93 122020590961.93 111048040961.93 10543522801.93 9281827601.93 8145949761.93 775493361.94 639007041.94 520134802 410069602 35036962 22520721.86 1135704 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
Re: StackOverflowError
added a log warning to property models when they reference session. -igor On Tue, Nov 16, 2010 at 9:46 AM, Douglas Ferguson doug...@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 doug...@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)
Re: StackOverFlowError
Hey guys, We overwrote IObjectStreamFactory with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson andr...@petersson.atwrote: i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Hey guys, We overwrote IObjectStreamFactory with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson andr...@petersson.atwrote: i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
When exactly does a page get serialized/serialized? On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Hey guys, We overwrote IObjectStreamFactory with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson andr...@petersson.at wrote: i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
at the end of request -igor On Thu, Sep 23, 2010 at 11:55 AM, Douglas Ferguson doug...@douglasferguson.us wrote: When exactly does a page get serialized/serialized? On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Hey guys, We overwrote IObjectStreamFactory with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Petersson andr...@petersson.at wrote: i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
Hello, Pages are serialized at the end of the request cycle (this includes at the end of ajax requests) Look at AbstractPageStore.serializePage(...) Specificically the call to Objects.objectToByteArray(page.getPageMapEntry()) which turns the page into a bytearray. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.wicket/wicket/1.4.10/org/apache/wicket/protocol/http/pagestore/AbstractPageStore.java#AbstractPageStore.serializePage%28org.apache.wicket.Page%29 Regards, Mike When exactly does a page get serialized/serialized? On Thu, Sep 23, 2010 at 12:54 PM, Igor Vaynbergigor.vaynb...@gmail.comwrote: in dev serialization should happen just like in production. -igor On Thu, Sep 23, 2010 at 10:34 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Hey guys, We overwrote IObjectStreamFactory with a copy that has more logging and we found the object that is causing the problems in our production logs. Now we need to recreate it in a more controlled environment. How could we force serialization of this object in a dev environmental? D/ On Wed, Sep 22, 2010 at 6:23 PM, Andreas Peterssonandr...@petersson.at wrote: i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
i had a very similar problem occuring in production when where was a cluster failover. i could never reproduce it. did something strange happen to you like, the filesystem was partially wiped during writing? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
this happened to me the other day. turned out to be a coding error. i wrapped a compoundpropertymodel in a propertylistview (which already wraps a model into a compoundpropertymodel). once the code was fix the problem went away. my data set was also large. about 1000 rows in a table being displayed on screen. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
Hmm... I don't really follow. On Fri, Jul 2, 2010 at 11:31 AM, robert.mcguinness robert.mcguinness@gmail.com wrote: this happened to me the other day. turned out to be a coding error. i wrapped a compoundpropertymodel in a propertylistview (which already wraps a model into a compoundpropertymodel). once the code was fix the problem went away. my data set was also large. about 1000 rows in a table being displayed on screen. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverFlowError
setresponsepage(new mypage(thispage)); or indirectly via an anonymous model class or something that holds a reference to the page. -igor On Fri, Jul 2, 2010 at 9:57 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Hmm... I don't really follow. On Fri, Jul 2, 2010 at 11:31 AM, robert.mcguinness robert.mcguinness@gmail.com wrote: this happened to me the other day. turned out to be a coding error. i wrapped a compoundpropertymodel in a propertylistview (which already wraps a model into a compoundpropertymodel). once the code was fix the problem went away. my data set was also large. about 1000 rows in a table being displayed on screen. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/StackOverFlowError-tp2276618p2276655.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
Thanks for all your help, Johan and Igor. Problem solved we think. One of the pages was holding a reference to the session. With multiple Ajax requests on the same page the session size was doubling each time, eventually giving stack overflow. Nigel Or: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ That should also have the latest fix - Original message - the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
we can modify serializable checker to check if anything is holding a reference to session or application and catch the error right away. please add a jira issue for this. -igor On Thu, Mar 18, 2010 at 11:17 PM, Nigel Parker nigel.par...@mazeppa.no wrote: Thanks for all your help, Johan and Igor. Problem solved we think. One of the pages was holding a reference to the session. With multiple Ajax requests on the same page the session size was doubling each time, eventually giving stack overflow. Nigel Or: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ That should also have the latest fix - Original message - the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
OK, WICKET-2789 added. Thanks again Nigel --- we can modify serializable checker to check if anything is holding a reference to session or application and catch the error right away. please add a jira issue for this. -igor
Re: StackOverflowError under serialization leaves pagemap locked
Thank you Johan for your reply. Agree that original problem should be fixed. This is a critical problem for us. We have found out during the last 24 hours that some of our pages are retaining a session reference. With Ajax requests this gives a doubling of session size for every request, and we now believe this to be the cause of the StackOverflowErrors. We will try this in production tomorrow. We upgraded to to 1.4.7 but still see that the pagemap is locked when the stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? Thanks Nigel Johan Compagner wrote: i fixed 2075 so that it should always unlock the pages. Problem is that you still could get weird errors because that page is not in a valid state in the session. So if back buttons/page versions are used it could be that that doesnt work So what should be fixed is the original problem On Wed, Mar 17, 2010 at 21:03, Nigel Parker nigel.par...@mazeppa.no wrote: We are a Wicket shop and for one of our clients have been running a Wicket application successfully for over 2 years. We are now at version 1.4.0. The traffic on the system is increasing and we are now seeing an increased frequency of pagemap locking which is beginning to be a serious problem for the users. By subclassing WebRequestCycle we have identified that a StackOverflowError under serialization in RequestCycle.detach() leaves the pagemap locked for the next minute. If our analysis is correct this is essentially the problem reported as https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we cannot reproduce the problem in our test environment and it occurs only in about one in every thousand requests with no apparent consistent pattern about what the user has been doing. Can anybody suggest an immediate strategy for further investigations? In particular: - is there a practical way to find out what is causing the serialization problem. The stack trace is no help. We do in many cases have large amounts of data in the session, but doubling the default stack size leaves the problem frequency unchanged leading us to suspect a logical error rather the sheer amount of data. - by overriding RequestCycle.detach() and catching the StackOverflowError we can get control when the error occurs. Is there any way we can persuade Wicket to release the pagemap lock? I have looked at the code and this doesn't look straightforward. - can we get Wicket itself to suppress the StackOverflowError so that detach() continues and releases the lock? Grateful for any suggestions. Nigel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker nigel.par...@mazeppa.no wrote: Thank you Johan for your reply. Agree that original problem should be fixed. This is a critical problem for us. We have found out during the last 24 hours that some of our pages are retaining a session reference. With Ajax requests this gives a doubling of session size for every request, and we now believe this to be the cause of the StackOverflowErrors. We will try this in production tomorrow. We upgraded to to 1.4.7 but still see that the pagemap is locked when the stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? Thanks Nigel Johan Compagner wrote: i fixed 2075 so that it should always unlock the pages. Problem is that you still could get weird errors because that page is not in a valid state in the session. So if back buttons/page versions are used it could be that that doesnt work So what should be fixed is the original problem On Wed, Mar 17, 2010 at 21:03, Nigel Parker nigel.par...@mazeppa.no wrote: We are a Wicket shop and for one of our clients have been running a Wicket application successfully for over 2 years. We are now at version 1.4.0. The traffic on the system is increasing and we are now seeing an increased frequency of pagemap locking which is beginning to be a serious problem for the users. By subclassing WebRequestCycle we have identified that a StackOverflowError under serialization in RequestCycle.detach() leaves the pagemap locked for the next minute. If our analysis is correct this is essentially the problem reported as https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we cannot reproduce the problem in our test environment and it occurs only in about one in every thousand requests with no apparent consistent pattern about what the user has been doing. Can anybody suggest an immediate strategy for further investigations? In particular: - is there a practical way to find out what is causing the serialization problem. The stack trace is no help. We do in many cases have large amounts of data in the session, but doubling the default stack size leaves the problem frequency unchanged leading us to suspect a logical error rather the sheer amount of data. - by overriding RequestCycle.detach() and catching the StackOverflowError we can get control when the error occurs. Is there any way we can persuade Wicket to release the pagemap lock? I have looked at the code and this doesn't look straightforward. - can we get Wicket itself to suppress the StackOverflowError so that detach() continues and releases the lock? Grateful for any suggestions. Nigel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
Or: http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.4-SNAPSHOT/ That should also have the latest fix - Original message - the fix is in 1.4.x branch and will be part of 1.4.8. in the meantime you can build a fresh snapshot yourself and drop that into your application http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x -igor On Thu, Mar 18, 2010 at 3:27 PM, Nigel Parker nigel.par...@mazeppa.no wrote: Thank you Johan for your reply. Agree that original problem should be fixed. This is a critical problem for us. We have found out during the last 24 hours that some of our pages are retaining a session reference. With Ajax requests this gives a doubling of session size for every request, and we now believe this to be the cause of the StackOverflowErrors. We will try this in production tomorrow. We upgraded to to 1.4.7 but still see that the pagemap is locked when the stack overflows. Do you know if the fix to WICKET-2075 is in 1.4.7? Thanks Nigel Johan Compagner wrote: i fixed 2075 so that it should always unlock the pages. Problem is that you still could get weird errors because that page is not in a valid state in the session. So if back buttons/page versions are used it could be that that doesnt work So what should be fixed is the original problem On Wed, Mar 17, 2010 at 21:03, Nigel Parker nigel.par...@mazeppa.no wrote: We are a Wicket shop and for one of our clients have been running a Wicket application successfully for over 2 years. We are now at version 1.4.0. The traffic on the system is increasing and we are now seeing an increased frequency of pagemap locking which is beginning to be a serious problem for the users. By subclassing WebRequestCycle we have identified that a StackOverflowError under serialization in RequestCycle.detach() leaves the pagemap locked for the next minute. If our analysis is correct this is essentially the problem reported as https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we cannot reproduce the problem in our test environment and it occurs only in about one in every thousand requests with no apparent consistent pattern about what the user has been doing. Can anybody suggest an immediate strategy for further investigations? In particular: - is there a practical way to find out what is causing the serialization problem. The stack trace is no help. We do in many cases have large amounts of data in the session, but doubling the default stack size leaves the problem frequency unchanged leading us to suspect a logical error rather the sheer amount of data. - by overriding RequestCycle.detach() and catching the StackOverflowError we can get control when the error occurs. Is there any way we can persuade Wicket to release the pagemap lock? I have looked at the code and this doesn't look straightforward. - can we get Wicket itself to suppress the StackOverflowError so that detach() continues and releases the lock? Grateful for any suggestions. Nigel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://old.nabble.com/StackOverflowError-under-serialization-leaves-pagemap-locked-tp27938028p27950858.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError under serialization leaves pagemap locked
i fixed 2075 so that it should always unlock the pages. Problem is that you still could get weird errors because that page is not in a valid state in the session. So if back buttons/page versions are used it could be that that doesnt work So what should be fixed is the original problem On Wed, Mar 17, 2010 at 21:03, Nigel Parker nigel.par...@mazeppa.no wrote: We are a Wicket shop and for one of our clients have been running a Wicket application successfully for over 2 years. We are now at version 1.4.0. The traffic on the system is increasing and we are now seeing an increased frequency of pagemap locking which is beginning to be a serious problem for the users. By subclassing WebRequestCycle we have identified that a StackOverflowError under serialization in RequestCycle.detach() leaves the pagemap locked for the next minute. If our analysis is correct this is essentially the problem reported as https://issues.apache.org/jira/browse/WICKET-2075. Unfortunately we cannot reproduce the problem in our test environment and it occurs only in about one in every thousand requests with no apparent consistent pattern about what the user has been doing. Can anybody suggest an immediate strategy for further investigations? In particular: - is there a practical way to find out what is causing the serialization problem. The stack trace is no help. We do in many cases have large amounts of data in the session, but doubling the default stack size leaves the problem frequency unchanged leading us to suspect a logical error rather the sheer amount of data. - by overriding RequestCycle.detach() and catching the StackOverflowError we can get control when the error occurs. Is there any way we can persuade Wicket to release the pagemap lock? I have looked at the code and this doesn't look straightforward. - can we get Wicket itself to suppress the StackOverflowError so that detach() continues and releases the lock? Grateful for any suggestions. Nigel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: StackOverflowError using 1.3.2
i was able to reproduce it in a quickstart. see WICKET-1476 Gerolf On Wed, Apr 2, 2008 at 9:02 PM, Johan Compagner [EMAIL PROTECTED] wrote: if we have a quickstart for this we could look for the solution... On Wed, Apr 2, 2008 at 8:26 PM, André Souza [EMAIL PROTECTED] wrote: I have the exactly same problem. Someone found the solution? On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner [EMAIL PROTECTED] wrote: do you have a unit test or quickstart for this? johan On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg [EMAIL PROTECTED] wrote: Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java :600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc( ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java :1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.defaultReadFields( ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject( Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore
Re: StackOverflowError using 1.3.2
I have the exactly same problem. Someone found the solution? On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner [EMAIL PROTECTED] wrote: do you have a unit test or quickstart for this? johan On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg [EMAIL PROTECTED] wrote: Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java :600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc( ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java :1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.defaultReadFields( ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject( Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore $PageHolder.readResolve(AbstractPageStore.java:363) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) .. - To unsubscribe, e-mail: [EMAIL PROTECTED]
Re: StackOverflowError using 1.3.2
if we have a quickstart for this we could look for the solution... On Wed, Apr 2, 2008 at 8:26 PM, André Souza [EMAIL PROTECTED] wrote: I have the exactly same problem. Someone found the solution? On Tue, Apr 1, 2008 at 6:09 PM, Johan Compagner [EMAIL PROTECTED] wrote: do you have a unit test or quickstart for this? johan On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg [EMAIL PROTECTED] wrote: Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java :600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc( ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java :1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.defaultReadFields( ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject( Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore $PageHolder.readResolve(AbstractPageStore.java:363) at
Re: StackOverflowError using 1.3.2
do you have a unit test or quickstart for this? johan On Tue, Apr 1, 2008 at 10:57 PM, Mark Lichtenberg [EMAIL PROTECTED] wrote: Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java :600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc( ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java :1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.defaultReadFields( ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject( ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject( Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore $PageHolder.readResolve(AbstractPageStore.java:363) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
