Re: FlushSession never called on AjaxFormComponentUpdatingBehavior

2022-05-16 Thread Sven Meier

Hi Wayne,

not, because InSessionPageStore#canBeAsynchronous returns false, thereby 
preventing asynchronous adds.


Regards
Sven


On 16.05.22 09:37, Wayne W wrote:

Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support http
session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:


Hi Wayne,

I've create an issue for this bug:

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

I think I have a fix ready, but have to give it some more tests.

Thanks for reporting the issue.

Sven


On 10.05.22 23:25, Sven Meier wrote:

Hi Wayne,


Is this a bug?

could be, do we have a Jira issue already?

I think there might be a call to Session#setMetaData() missing. Before
Wicket 9.x it seemed to have been called additionally when a page is
stored in the session.

I'll take a deeper look into this tomorrow.

Best regards
Sven


On 10.05.22 18:47, Wayne W wrote:

Hi,

I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.

After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes to
the
model are not persisted in the HTTP Session and into Redis backed store.
The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And when the
next call arrives, the page is pulled back out of Redis/Http session
without the changes.

I had to do the following to get the wicket session to be stored in the
session within our Application:

ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
  protected IPageStore newCachingStore(IPageStore pageStore)
  {
  return new CachingPageStore(pageStore, new
InSessionPageStore( 2,
serializer));
  }
  });

The objects are updated in the session page object instance correctly
with
AjaxFormComponentUpdatingBehavior , however this issue is they are never
saved/persisted as setAttribute is not called. So the next request comes
and a new page object instance is unserialized from the store without
the
changes.

Is this a bug?


-
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: FlushSession never called on AjaxFormComponentUpdatingBehavior

2022-05-16 Thread Wayne W
Ah that's great Sven.

Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support http
session setup?

I saw a post about this quite some time ago but I'm not sure.

Thanks for clarifying



On Sun, May 15, 2022 at 8:54 PM Sven Meier  wrote:

> Hi Wayne,
>
> I've create an issue for this bug:
>
> https://issues.apache.org/jira/browse/WICKET-6981
>
> I think I have a fix ready, but have to give it some more tests.
>
> Thanks for reporting the issue.
>
> Sven
>
>
> On 10.05.22 23:25, Sven Meier wrote:
> > Hi Wayne,
> >
> > >Is this a bug?
> >
> > could be, do we have a Jira issue already?
> >
> > I think there might be a call to Session#setMetaData() missing. Before
> > Wicket 9.x it seemed to have been called additionally when a page is
> > stored in the session.
> >
> > I'll take a deeper look into this tomorrow.
> >
> > Best regards
> > Sven
> >
> >
> > On 10.05.22 18:47, Wayne W wrote:
> >> Hi,
> >>
> >> I am *still* trying to troubleshoot why migrating to 9.4 we have
> >> found that
> >> our app no longer supports session failover correctly. We use
> >> Redission to
> >> store the tomcat session in Redis.
> >>
> >> After a lot of debugging it appears that for
> >> AjaxFormComponentUpdatingBehavior.onEvent() calls,
> >> HttpSessionStore.flushSession() is never called after. And changes to
> >> the
> >> model are not persisted in the HTTP Session and into Redis backed store.
> >> The reason is setAttribute is never called on the session and
> >> therefore the
> >> updated session with good model values is never persisted. And when the
> >> next call arrives, the page is pulled back out of Redis/Http session
> >> without the changes.
> >>
> >> I had to do the following to get the wicket session to be stored in the
> >> session within our Application:
> >>
> >> ISerializer serializer = new JavaSerializer(getApplicationKey());
> >> getFrameworkSettings().setSerializer(serializer);
> >> getStoreSettings().setAsynchronous(false);
> >> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> >>  protected IPageStore newCachingStore(IPageStore pageStore)
> >>  {
> >>  return new CachingPageStore(pageStore, new
> >> InSessionPageStore( 2,
> >> serializer));
> >>  }
> >>  });
> >>
> >> The objects are updated in the session page object instance correctly
> >> with
> >> AjaxFormComponentUpdatingBehavior , however this issue is they are never
> >> saved/persisted as setAttribute is not called. So the next request comes
> >> and a new page object instance is unserialized from the store without
> >> the
> >> changes.
> >>
> >> Is this a bug?
> >>
> >
> > -
> > 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
>
>