You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Victor Igumnov <vi...@fabulously40.com> on 2009/03/02 22:30:28 UTC

Help with SecondLevelCache and Serialization

I have been running on the HttpSessionStore for a good year now.  
HttpSessions are clustered and have been working fine for all this  
time. As of recently I have switched to SecondLevelCache and  
DiskPageStore to avoid HttpSession bloat and still have fail over.

I have run into an odd issue with serialization which throws a  
stackoverflow exception. Here is the cause:

Passing an LDM model as-is to a page, it will stackoverflow on the  
receiving page, if that page is refreshed twice or a form has been  
submitted.

Here is an example...

setResponsePage(new EditBlogPage(new LoadableDetachableModel<Blog>() {
	private static final long serialVersionUID = 1L;
	@Override
	protected Blog load() {
		// just an example....
		return new Blog();
	}

}));

However, if I subclass the LDM and pass it like so, it will work just  
fine.

public class FakeLDM extends LoadableDetachableModel<Blog> {
	private static final long serialVersionUID = 1L;

	@Override
	protected Blog load() {
		return new Blog();
	}
}

setResponsePage(new EditBlogPage(new FakeLDM()));

One last thing, If I construct the LDM inside the receiving page. It  
will work fine as well.

This seems to only happen with the SecondLevelCache, any ideas?

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


Re: Help with SecondLevelCache and Serialization

Posted by Victor Igumnov <vi...@fabulously40.com>.
Here is the test case and stacktrace

https://issues.apache.org/jira/browse/WICKET-2138


On Mar 3, 2009, at 3:55 AM, behrica wrote:

>
> Yes, it might be the same problem I had with the serialization.
> Could you maybe paste your stack trace and let me know the JIRA id,  
> so I can
> track it.
>
> You mentioned you had an other configuration which the  
> HttpSessionStore.
> What is this and how can it be enabled ?
>
> Thanks,
>
> Carsten
>
>
>
> Victor Igumnov-4 wrote:
>>
>> Igor,
>>
>> Thanks for the confirmation, this is exactly what I thought. I will
>> submit a bug report now.
>>
>> This seems exactly like that other issue that someone had with JBoss
>> clustered sessions.
>>
>> On Mar 2, 2009, at 1:35 PM, Igor Vaynberg wrote:
>>
>>> when you construct it using the first example you showed (anonymous
>>> class) the ldm is carrying a reference to the page on which it is
>>> constructed. so your editblogpage is indirectly holding onto the
>>> instance of the previous page, perhaps that is what is causing the
>>> problem. please file a jira issue.
>>>
>>> -igor
>>>
>>>
>>> On Mon, Mar 2, 2009 at 1:30 PM, Victor Igumnov <victori@fabulously40.com
>>>> wrote:
>>>> I have been running on the HttpSessionStore for a good year now.
>>>> HttpSessions are clustered and have been working fine for all this
>>>> time. As
>>>> of recently I have switched to SecondLevelCache and DiskPageStore
>>>> to avoid
>>>> HttpSession bloat and still have fail over.
>>>>
>>>> I have run into an odd issue with serialization which throws a
>>>> stackoverflow
>>>> exception. Here is the cause:
>>>>
>>>> Passing an LDM model as-is to a page, it will stackoverflow on the
>>>> receiving
>>>> page, if that page is refreshed twice or a form has been submitted.
>>>>
>>>> Here is an example...
>>>>
>>>> setResponsePage(new EditBlogPage(new
>>>> LoadableDetachableModel<Blog>() {
>>>>       private static final long serialVersionUID = 1L;
>>>>       @Override
>>>>       protected Blog load() {
>>>>               // just an example....
>>>>               return new Blog();
>>>>       }
>>>>
>>>> }));
>>>>
>>>> However, if I subclass the LDM and pass it like so, it will work
>>>> just fine.
>>>>
>>>> public class FakeLDM extends LoadableDetachableModel<Blog> {
>>>>       private static final long serialVersionUID = 1L;
>>>>
>>>>       @Override
>>>>       protected Blog load() {
>>>>               return new Blog();
>>>>       }
>>>> }
>>>>
>>>> setResponsePage(new EditBlogPage(new FakeLDM()));
>>>>
>>>> One last thing, If I construct the LDM inside the receiving page.
>>>> It will
>>>> work fine as well.
>>>>
>>>> This seems to only happen with the SecondLevelCache, any ideas?
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>
> -- 
> View this message in context: http://www.nabble.com/Help-with-SecondLevelCache-and-Serialization-tp22297221p22307250.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>


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


Re: Help with SecondLevelCache and Serialization

Posted by behrica <ca...@efsa.europa.eu>.
Yes, it might be the same problem I had with the serialization.
Could you maybe paste your stack trace and let me know the JIRA id, so I can
track it.

You mentioned you had an other configuration which the HttpSessionStore.
What is this and how can it be enabled ? 

Thanks,

Carsten



Victor Igumnov-4 wrote:
> 
> Igor,
> 
> Thanks for the confirmation, this is exactly what I thought. I will  
> submit a bug report now.
> 
> This seems exactly like that other issue that someone had with JBoss  
> clustered sessions.
> 
> On Mar 2, 2009, at 1:35 PM, Igor Vaynberg wrote:
> 
>> when you construct it using the first example you showed (anonymous
>> class) the ldm is carrying a reference to the page on which it is
>> constructed. so your editblogpage is indirectly holding onto the
>> instance of the previous page, perhaps that is what is causing the
>> problem. please file a jira issue.
>>
>> -igor
>>
>>
>> On Mon, Mar 2, 2009 at 1:30 PM, Victor Igumnov <victori@fabulously40.com 
>> > wrote:
>>> I have been running on the HttpSessionStore for a good year now.
>>> HttpSessions are clustered and have been working fine for all this  
>>> time. As
>>> of recently I have switched to SecondLevelCache and DiskPageStore  
>>> to avoid
>>> HttpSession bloat and still have fail over.
>>>
>>> I have run into an odd issue with serialization which throws a  
>>> stackoverflow
>>> exception. Here is the cause:
>>>
>>> Passing an LDM model as-is to a page, it will stackoverflow on the  
>>> receiving
>>> page, if that page is refreshed twice or a form has been submitted.
>>>
>>> Here is an example...
>>>
>>> setResponsePage(new EditBlogPage(new  
>>> LoadableDetachableModel<Blog>() {
>>>        private static final long serialVersionUID = 1L;
>>>        @Override
>>>        protected Blog load() {
>>>                // just an example....
>>>                return new Blog();
>>>        }
>>>
>>> }));
>>>
>>> However, if I subclass the LDM and pass it like so, it will work  
>>> just fine.
>>>
>>> public class FakeLDM extends LoadableDetachableModel<Blog> {
>>>        private static final long serialVersionUID = 1L;
>>>
>>>        @Override
>>>        protected Blog load() {
>>>                return new Blog();
>>>        }
>>> }
>>>
>>> setResponsePage(new EditBlogPage(new FakeLDM()));
>>>
>>> One last thing, If I construct the LDM inside the receiving page.  
>>> It will
>>> work fine as well.
>>>
>>> This seems to only happen with the SecondLevelCache, any ideas?
>>>
>>> ---------------------------------------------------------------------
>>> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Help-with-SecondLevelCache-and-Serialization-tp22297221p22307250.html
Sent from the Wicket - User 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: Help with SecondLevelCache and Serialization

Posted by Victor Igumnov <vi...@fabulously40.com>.
Igor,

Thanks for the confirmation, this is exactly what I thought. I will  
submit a bug report now.

This seems exactly like that other issue that someone had with JBoss  
clustered sessions.

On Mar 2, 2009, at 1:35 PM, Igor Vaynberg wrote:

> when you construct it using the first example you showed (anonymous
> class) the ldm is carrying a reference to the page on which it is
> constructed. so your editblogpage is indirectly holding onto the
> instance of the previous page, perhaps that is what is causing the
> problem. please file a jira issue.
>
> -igor
>
>
> On Mon, Mar 2, 2009 at 1:30 PM, Victor Igumnov <victori@fabulously40.com 
> > wrote:
>> I have been running on the HttpSessionStore for a good year now.
>> HttpSessions are clustered and have been working fine for all this  
>> time. As
>> of recently I have switched to SecondLevelCache and DiskPageStore  
>> to avoid
>> HttpSession bloat and still have fail over.
>>
>> I have run into an odd issue with serialization which throws a  
>> stackoverflow
>> exception. Here is the cause:
>>
>> Passing an LDM model as-is to a page, it will stackoverflow on the  
>> receiving
>> page, if that page is refreshed twice or a form has been submitted.
>>
>> Here is an example...
>>
>> setResponsePage(new EditBlogPage(new  
>> LoadableDetachableModel<Blog>() {
>>        private static final long serialVersionUID = 1L;
>>        @Override
>>        protected Blog load() {
>>                // just an example....
>>                return new Blog();
>>        }
>>
>> }));
>>
>> However, if I subclass the LDM and pass it like so, it will work  
>> just fine.
>>
>> public class FakeLDM extends LoadableDetachableModel<Blog> {
>>        private static final long serialVersionUID = 1L;
>>
>>        @Override
>>        protected Blog load() {
>>                return new Blog();
>>        }
>> }
>>
>> setResponsePage(new EditBlogPage(new FakeLDM()));
>>
>> One last thing, If I construct the LDM inside the receiving page.  
>> It will
>> work fine as well.
>>
>> This seems to only happen with the SecondLevelCache, any ideas?
>>
>> ---------------------------------------------------------------------
>> 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: Help with SecondLevelCache and Serialization

Posted by Igor Vaynberg <ig...@gmail.com>.
when you construct it using the first example you showed (anonymous
class) the ldm is carrying a reference to the page on which it is
constructed. so your editblogpage is indirectly holding onto the
instance of the previous page, perhaps that is what is causing the
problem. please file a jira issue.

-igor


On Mon, Mar 2, 2009 at 1:30 PM, Victor Igumnov <vi...@fabulously40.com> wrote:
> I have been running on the HttpSessionStore for a good year now.
> HttpSessions are clustered and have been working fine for all this time. As
> of recently I have switched to SecondLevelCache and DiskPageStore to avoid
> HttpSession bloat and still have fail over.
>
> I have run into an odd issue with serialization which throws a stackoverflow
> exception. Here is the cause:
>
> Passing an LDM model as-is to a page, it will stackoverflow on the receiving
> page, if that page is refreshed twice or a form has been submitted.
>
> Here is an example...
>
> setResponsePage(new EditBlogPage(new LoadableDetachableModel<Blog>() {
>        private static final long serialVersionUID = 1L;
>        @Override
>        protected Blog load() {
>                // just an example....
>                return new Blog();
>        }
>
> }));
>
> However, if I subclass the LDM and pass it like so, it will work just fine.
>
> public class FakeLDM extends LoadableDetachableModel<Blog> {
>        private static final long serialVersionUID = 1L;
>
>        @Override
>        protected Blog load() {
>                return new Blog();
>        }
> }
>
> setResponsePage(new EditBlogPage(new FakeLDM()));
>
> One last thing, If I construct the LDM inside the receiving page. It will
> work fine as well.
>
> This seems to only happen with the SecondLevelCache, any ideas?
>
> ---------------------------------------------------------------------
> 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