Re: StackOverflowError under serialization leaves pagemap locked

2010-03-19 Thread Nigel Parker
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

2010-03-19 Thread Igor Vaynberg
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

2010-03-19 Thread Nigel Parker
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

2010-03-18 Thread Nigel Parker

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

2010-03-18 Thread Igor Vaynberg
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

2010-03-18 Thread Johan Compagner
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




StackOverflowError under serialization leaves pagemap locked

2010-03-17 Thread Nigel Parker
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 under serialization leaves pagemap locked

2010-03-17 Thread Johan Compagner
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