Some questions - mainly about session expiration and serialization

["fabrizio.giudici@tidalwave.it" <fa...@tidalwave.it>]

Hi to all.

This is my first post, here's a quick introduction of
myself. My name is Fabrizio Giudici, I'm a senior architect
and I've been working with Wicket for a bit more than one
year.

I've recently upgraded to 1.3 (I was working with an 1.3
snapshot that dated back to a few months ago) and I've got a
project that is exiting from the "prototype" stage and
should go into production in a matter of weeks. I'm doing a
final review of the code, considering that some of the older
portions weren't probably very good (it is my first Wicket
project) and something changed with 1.3.

Here's my list of question - I apologize as I bet there's
something more or less trivial, of course I've already done
some searches around but I wasn't able to find good answers
(or I didn't understand them ;-) :

1. I've always experienced some sudden "session expiration"
problems with no apparent reason (I mean, the user wasn't
actually sleeping). But they happened only once in a while.
After upgrading to 1.3 they occur very often and they have
quickly become the issue on the top of the list and I've to
fix it immediately, since it's jeopardizing the acceptance
tests performed by my customer. I've already searched in
forums and tried some change (such as disabling versioning),
but I got no benefit from it.

2. I have a modal window used to enter a date (I can't use
the already provided component since this a special date)
that has been working from several months. After upgrading
to 1.3 it deterministically causes a session expired
whenever it's closed (since this is deterministic I bet it's
a different thing than the above).

3. I have still some confusion about serialization of things
in sessions. I've always got some objects that are not
serializable and caused tons of exceptions in log files, but
no harm other than it. I'm now wondering whether they can
trigger one of the above problems, and anyway before going
into production I'd like to face with this issue in a
definitive fashion. I know about the possibility of using
detachable objects, nevertheless I need first to understand
why this serialization thing can't be disabled - after all
I've got no need for clustering in near future (and if I
should do it, I'd probably go with Terracotta). Also, in
version 1.2 I once saw that there was a UserSession (?)
method that looked like it was useful for disabling
serialization, and I had a mental note about using it, but
it looks like it disappeared in 1.3.0. Hints?

Thanks in advance..

-- 
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici -
www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941



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

Re: Some questions - mainly about session expiration and serialization

[Johan Compagner <jc...@gmail.com>]

>
> Ok, I'll try this just to see if it can at least solve immediately
> the problem, then go for some refactoring. My question is: but if I
> don't need (and don't want) page versioning, and I disable it, is
> serialization still necessary?
>

it is with the 1.3 default page store you have to do this:

class MyApplication extends WebApplication { ISessionStore
newSessionStore() { return new HttpSessionStore();}}

But its way better to make everything serializeable the right way

johan

Re: Some questions - mainly about session expiration and serialization

[Fabrizio Giudici <fa...@tidalwave.it>]

On 06/feb/08, at 19:31, Igor Vaynberg wrote:
>
> sure, you can disable the versioning completely, but then you also
> wont have a proper backbutton support. versioning is there for a
> reason...
>
> -igor

I understand it, but I don't like backbutton support :-)

When I disable the versioning (I suppose I just need to call  
setVersioned(false) in the base page of my hierarchy) what is the  
behaviour when I hit the back button? Will I get "page expired" or  
will I just make the relevant page class to be run?


-- 
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

Re: Some questions - mainly about session expiration and serialization

[Igor Vaynberg <ig...@gmail.com>]

On Feb 6, 2008 10:28 AM, Fabrizio Giudici <fa...@tidalwave.it> wrote:
>
> >
> > Are you using our modal window implementation or your own?
>
> Wicket implementation. BTW, I have another modal window that doesn't
> create problem. I'll later post the code, when I'm able to cut it down.

are you using it to popup a panel or a page? i think the panel popup
doesnt generally work well, the page version works better. also make
sure you popup the page in a different pagemap.

> >
> >> 3. I have still some confusion about serialization of things
> >> in sessions. I've always got some objects that are not
> >> serializable and caused tons of exceptions in log files, but
> >> no harm other than it. I'm now wondering whether they can
> >> trigger one of the above problems, and anyway before going
> >> into production I'd like to face with this issue in a
> >> definitive fashion. I know about the possibility of using
> >> detachable objects, nevertheless I need first to understand
> >> why this serialization thing can't be disabled - after all
> >> I've got no need for clustering in near future (and if I
> >> should do it, I'd probably go with Terracotta). Also, in
> >> version 1.2 I once saw that there was a UserSession (?)
> >> method that looked like it was useful for disabling
> >> serialization, and I had a mental note about using it, but
> >> it looks like it disappeared in 1.3.0. Hints?
> >
> > Serialization has always been needed in wicket for things other then
> > cluster replication. Versioning has been one of those reasons. We
> > would use serialization mostly for cloning an object, so that we can
> > keep a reference to its previous state for rolling back a version.
> > With 1.3.1 this has changed dramatically. In order to free up session
> > space (1.2 would keep x pages in session) 1.3.1 only keeps the most
> > current page in session and spools older pages to disk via
> > serialization. So if you hit a page that has a serialization problem
> > and later come back to it via back button and click a link/submit a
> > form you will get a page expired error. My recommendation is to make
> > sure you use detachable models or make your objects serializable. In
> > the meantime, try
> >
> > class MyApplication extends WebApplication { ISessionStore
> > newSessionStore() { return new HttpSessionStore();}}
> >
> > that will turn off disk spooling and will make 1.3 behave more like
> > 1.2 in that regard.
>
> Ok, I'll try this just to see if it can at least solve immediately
> the problem, then go for some refactoring. My question is: but if I
> don't need (and don't want) page versioning, and I disable it, is
> serialization still necessary?

sure, you can disable the versioning completely, but then you also
wont have a proper backbutton support. versioning is there for a
reason...

-igor

>
> --
>
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941
>
>
>

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

Re: Some questions - mainly about session expiration and serialization

[Fabrizio Giudici <fa...@tidalwave.it>]

>
> Are you using our modal window implementation or your own?

Wicket implementation. BTW, I have another modal window that doesn't  
create problem. I'll later post the code, when I'm able to cut it down.

>
>> 3. I have still some confusion about serialization of things
>> in sessions. I've always got some objects that are not
>> serializable and caused tons of exceptions in log files, but
>> no harm other than it. I'm now wondering whether they can
>> trigger one of the above problems, and anyway before going
>> into production I'd like to face with this issue in a
>> definitive fashion. I know about the possibility of using
>> detachable objects, nevertheless I need first to understand
>> why this serialization thing can't be disabled - after all
>> I've got no need for clustering in near future (and if I
>> should do it, I'd probably go with Terracotta). Also, in
>> version 1.2 I once saw that there was a UserSession (?)
>> method that looked like it was useful for disabling
>> serialization, and I had a mental note about using it, but
>> it looks like it disappeared in 1.3.0. Hints?
>
> Serialization has always been needed in wicket for things other then
> cluster replication. Versioning has been one of those reasons. We
> would use serialization mostly for cloning an object, so that we can
> keep a reference to its previous state for rolling back a version.
> With 1.3.1 this has changed dramatically. In order to free up session
> space (1.2 would keep x pages in session) 1.3.1 only keeps the most
> current page in session and spools older pages to disk via
> serialization. So if you hit a page that has a serialization problem
> and later come back to it via back button and click a link/submit a
> form you will get a page expired error. My recommendation is to make
> sure you use detachable models or make your objects serializable. In
> the meantime, try
>
> class MyApplication extends WebApplication { ISessionStore
> newSessionStore() { return new HttpSessionStore();}}
>
> that will turn off disk spooling and will make 1.3 behave more like
> 1.2 in that regard.

Ok, I'll try this just to see if it can at least solve immediately  
the problem, then go for some refactoring. My question is: but if I  
don't need (and don't want) page versioning, and I disable it, is  
serialization still necessary?

-- 
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

Re: Some questions - mainly about session expiration and serialization

[Igor Vaynberg <ig...@gmail.com>]

On Feb 6, 2008 4:40 AM, fabrizio.giudici@tidalwave.it
<fa...@tidalwave.it> wrote:
> 1. I've always experienced some sudden "session expiration"
> problems with no apparent reason (I mean, the user wasn't
> actually sleeping). But they happened only once in a while.
> After upgrading to 1.3 they occur very often and they have
> quickly become the issue on the top of the list and I've to
> fix it immediately, since it's jeopardizing the acceptance
> tests performed by my customer. I've already searched in
> forums and tried some change (such as disabling versioning),
> but I got no benefit from it.

My guess is that #3 is causing it...see my answer there.

> 2. I have a modal window used to enter a date (I can't use
> the already provided component since this a special date)
> that has been working from several months. After upgrading
> to 1.3 it deterministically causes a session expired
> whenever it's closed (since this is deterministic I bet it's
> a different thing than the above).

Are you using our modal window implementation or your own?

> 3. I have still some confusion about serialization of things
> in sessions. I've always got some objects that are not
> serializable and caused tons of exceptions in log files, but
> no harm other than it. I'm now wondering whether they can
> trigger one of the above problems, and anyway before going
> into production I'd like to face with this issue in a
> definitive fashion. I know about the possibility of using
> detachable objects, nevertheless I need first to understand
> why this serialization thing can't be disabled - after all
> I've got no need for clustering in near future (and if I
> should do it, I'd probably go with Terracotta). Also, in
> version 1.2 I once saw that there was a UserSession (?)
> method that looked like it was useful for disabling
> serialization, and I had a mental note about using it, but
> it looks like it disappeared in 1.3.0. Hints?

Serialization has always been needed in wicket for things other then
cluster replication. Versioning has been one of those reasons. We
would use serialization mostly for cloning an object, so that we can
keep a reference to its previous state for rolling back a version.
With 1.3.1 this has changed dramatically. In order to free up session
space (1.2 would keep x pages in session) 1.3.1 only keeps the most
current page in session and spools older pages to disk via
serialization. So if you hit a page that has a serialization problem
and later come back to it via back button and click a link/submit a
form you will get a page expired error. My recommendation is to make
sure you use detachable models or make your objects serializable. In
the meantime, try

class MyApplication extends WebApplication { ISessionStore
newSessionStore() { return new HttpSessionStore();}}

that will turn off disk spooling and will make 1.3 behave more like
1.2 in that regard.

-igor



>
> Thanks in advance..
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -
> www.tidalwave.it/blog
> Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941
>
>
>
> ---------------------------------------------------------------------
> 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: Some questions - mainly about session expiration and serialization

[Erik van Oosten <er...@grons.nl>]

Hi Fabrizio,

In 1.3 everything is serialized to disk at some time. So'll have to make 
things serializable, whether you are clustering or not (even with 
Terracotta).

Secondly, I very very very strongly recommend detachable models. Let me 
repeat, I really recommend detachable models. Large, or many non 
detachable models will fill up your session space quickly.

I am not sure your problems will go away with these changes, but I dare 
to bet on it.

Good luck and regards,
     Erik.



fabrizio.giudici@tidalwave.it wrote:
> Hi to all.
>
> This is my first post, here's a quick introduction of
> myself. My name is Fabrizio Giudici, I'm a senior architect
> and I've been working with Wicket for a bit more than one
> year.
>
> I've recently upgraded to 1.3......


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