Hello Sven,
Many thanks for looking into this. It's greatly appreciated that you
understand what is happening here.
Out of interest I just had a look at the RedissionSession setAttribute and
it's just calling org.apache.catalina.session.StandardSession.setAttribute(
name, value, notify) and all the unBound calls are done in there. So
perhaps this is an issue with different versions of Tomcat?
FYI RedissionSession:
*public* *void* setAttribute(String name, Object value, *boolean* notify)
{
*super*.setAttribute(name, value, notify);
*if* (value == *null*) {
*return*;
}
*if* (updateMode == UpdateMode.*DEFAULT* && map != *null*) {
fastPut(name, value);
}
*if* (readMode == ReadMode.*REDIS*) {
loadedAttributes.put(name, value);
updatedAttributes.put(name, value);
}
*if* (updateMode == UpdateMode.*AFTER_REQUEST*) {
removedAttributes.remove(name);
}
}
Either way looking forward to the fix.
On Sun, Jun 19, 2022 at 10:09 PM Sven Meier <s...@meiers.net> wrote:
> Hi again,
>
> I found the cause of this bug:
>
> RedissonSession exposes a behavior we've seen before, which seems not to
> be a problem with the default Tomcat session implementation:
> When an attribute is set on the session, the previously set attribute is
> removed first - this leads to #valueUnbound() being called, signalling
> PersistentPageStore to drop all store pages.
>
> I'll perpare a fix tomorrow.
>
> Thanks for your report.
> Sven
>
>
> On 18.06.22 15:24, Sven Meier wrote:
> > Hi,
> >
> > I've stripped all pageManager related settings from your application.
> >
> > Now the bug only appears with Tomcat's RedissonSessionManager, without
> > it the detailPages open as expected.
> >
> > I'm no expert in Redis, so I don't know what is going wrong there. Can
> > you confirm my observation so far?
> >
> > Regards
> > Sven
> >
> >
> > On 13.06.22 12:30, Wayne W wrote:
> >> Hi Sven,
> >>
> >> Ok here is a quickstart demonstrating the issue.
> >>
> https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f
> >>
> >>
> >> To reproduce, open localhost:8080 and you will now also see a list of 4
> >> links. If you right click each link and open in a new window, you
> >> will see
> >> that only the first tab will render correctly. The other tabs just
> >> refresh
> >> the page.
> >>
> >> If you change the wicket version to say 9.4.0 and do the same you
> >> will see
> >> that each page opens correctly in a new tab, and clicking on the link in
> >> the page outputs "this" to the console correctly.
> >>
> >> Let me know your thoughts
> >> I will of course try and understand whats happening.
> >>
> >>
> >> On Thu, Jun 9, 2022 at 8:45 AM Sven Meier <s...@meiers.net> wrote:
> >>
> >>> Hi Wayne,
> >>>
> >>> no idea on my side.
> >>>
> >>> Please compare without InSessionPageStore and with different max pages.
> >>>
> >>> If the problem persists, please provide a quickstart.
> >>>
> >>> Thanks
> >>> Sven
> >>>
> >>>
> >>> On 08.06.22 18:51, Wayne W wrote:
> >>>> Hi Sven,
> >>>>
> >>>> I'm having a new issue with this wicket version - I've yet had time to
> >>> dig
> >>>> deep and try and make a quickstart to replicate it. However I
> >>>> thought I
> >>>> would describe it first to see if it rings any bells in your head!
> >>>>
> >>>> In our app we have a file explorer like page that lists a bunch of
> >>>> files.
> >>>> Clicking one of these opens a popup over the page to see the
> >>>> details. We
> >>>> used to be able to open each of these files in a new browser tab.
> >>> However,
> >>>> now when the new tabs are opened, the details load ok, but when the
> >>>> user
> >>>> clicks on the wicket link to close the popup we are getting
> >>>> componentsnotfound in the page.
> >>>>
> >>>> Something about opening new browser tabs is messing up the session and
> >>>> loosing the components. I presume this is something to do with
> >>>> InSessionPageStore. Opening a single new tab is fine, it when there
> >>>> are
> >>>> more than 2 in total. I tried increasing the maxPages to 20 for
> >>>> InSessionPageStore
> >>>> but it made no difference.
> >>>>
> >>>> Any idea?
> >>>>
> >>>> On Wed, Jun 8, 2022 at 10:43 AM Sven Meier <s...@meiers.net> wrote:
> >>>>
> >>>>> Thanks Wayne!
> >>>>>
> >>>>> The fix will be part of the next 9.x release.
> >>>>>
> >>>>> Best regards
> >>>>> Sven
> >>>>>
> >>>>>
> >>>>> On 07.06.22 12:22, Wayne W wrote:
> >>>>>> Hi Sven,
> >>>>>>
> >>>>>> I can confirm your fix is working .
> >>>>>>
> >>>>>> I suppose it will be a while before this reaches an official
> >>>>>> release?
> >>>>>> Thanks for your help - really appreciated.
> >>>>>>
> >>>>>> Wayne
> >>>>>>
> >>>>>> On Sun, May 29, 2022 at 10:47 PM Sven Meier <s...@meiers.net>
> wrote:
> >>>>>>
> >>>>>>> Hi Wayne,
> >>>>>>>
> >>>>>>> the Eclipse .project still has 9.1.1 on the classpath:
> >>>>>>>
> >>>>>>> <classpathentry kind="var"
> >>>>>>>
> >>>
> path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"
> >>>
> >>>
> sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>
>
> >>>
> >>>>>>>
> >>>>>>> Without that, flushing of the Session works fine here with my
> >>>>>>> fix on
> >>> 9.x
> >>>>>>> BTW the workaround with HubInSessionCache subclassing
> >>> InSessionPageStore
> >>>>>>> (to use a separate MetaDataKey) is no longer needed.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Sven
> >>>>>>>
> >>>>>>>
> >>>>>>> On 26.05.22 19:19, Wayne W wrote:
> >>>>>>>> Hello Sven,
> >>>>>>>>
> >>>>>>>> So this particular issue I've been investigating might be a
> >>>>>>>> lack of
> >>> my
> >>>>>>>> understanding of wicket as much as a session issue, but it
> >>>>>>>> seems odd
> >>>>>>>> and I'm fairly sure it's not correct. It appears I need to call
> >>>>>>>> getSession().dirty();
> >>>>>>>> as well within the ajax request for wicket to flush the updated
> >>>>>>>> model
> >>>>>>> into
> >>>>>>>> the session (in the onDetach -> internalDetach -> setAttribute )
> >>>>>>> otherwise
> >>>>>>>> the model update is simply ignored. If I don't call dirty()
> >>>>>>>> then the
> >>>>>>> model
> >>>>>>>> is never persisted to the httlpsession via setAttribute() and the
> >>>>> change
> >>>>>>> is
> >>>>>>>> lost.
> >>>>>>>>
> >>>>>>>> Is that right?
> >>>>>>>>
> >>>>>>>> Interestingly if I remove this from the Application:
> >>>>>>>>
> >>>>>>>> *final* 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*
> >>>>>>> HubInSessionCache(
> >>>>>>>> serializer));
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> });
> >>>>>>>>
> >>>>>>>> Then I do not need to call dirty(). Is this because the
> >>>>>>>> httpsession
> >>> is
> >>>>>>> not
> >>>>>>>> used I presume?
> >>>>>>>>
> >>>>>>>> If I do not use persisted tomcat session in redis it's ok
> >>>>>>>> though when
> >>>>> not
> >>>>>>>> calling dirty() - this because as I explained before,
> >>>>>>>> setAttribute is
> >>>>> not
> >>>>>>>> being called on the tomcat httpsession on the next request to the
> >>>>>>> AjaxLink.
> >>>>>>>> The redis tomcat is looking for calls to the setAttribute to store
> >>> the
> >>>>>>>> updated session into redis , and without that explicit dirty()
> >>>>>>>> call
> >>> it
> >>>>>>>> doesn't happen.
> >>>>>>>>
> >>>>>>>> Here is a quickstart if you want:
> >>>>>>>>
> >>>
> https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4
> >>>
> >>>>>>>> You will need a bog standard redis instance running on your
> >>>>>>>> machine
> >>>>>>> though
> >>>>>>>> to test. Check the path is correct in Start.java line 84.
> >>>>>>>> Line 74 in HomePage.java has the dirty commented out at the
> >>>>>>>> moment.
> >>>>>>>>
> >>>>>>>> Enter some text into the textfield and you will see the model is
> >>>>> updated
> >>>>>>>> (printed out). However when you click on the AjaxLink 'next' the
> >>> model
> >>>>> is
> >>>>>>>> null.
> >>>>>>>>
> >>>>>>>> Let me know your thoughts
> >>>>>>>> Many thanks.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, May 25, 2022 at 4:19 PM Wayne W
> >>>>>>>> <waynemailingli...@gmail.com
> >>>>>>> wrote:
> >>>>>>>>> Hi Sven,
> >>>>>>>>>
> >>>>>>>>> Many thanks.
> >>>>>>>>>
> >>>>>>>>> I've built 9,x and the changes seem to be there, but I still have
> >>> the
> >>>>>>>>> issue. I will try and create a quickstart reproducing this
> >>>>>>>>> issue and
> >>>>> get
> >>>>>>>>> back to you.
> >>>>>>>>>
> >>>>>>>>> Wayne
> >>>>>>>>>
> >>>>>>>>> On Wed, May 25, 2022 at 8:34 AM Sven Meier <s...@meiers.net>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi Wayne,
> >>>>>>>>>>
> >>>>>>>>>> I've pushed a fix to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>
> https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set
> >>>
> >>>>>>>>>> Are you able to test this on your setup?
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>> Sven
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 24.05.22 10:43, Wayne W wrote:
> >>>>>>>>>>> Hello Sven,
> >>>>>>>>>>>
> >>>>>>>>>>> Any update on this?
> >>>>>>>>>>> Many thanks
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, May 16, 2022 at 11:40 AM Sven Meier <s...@meiers.net>
> >>>>> wrote:
> >>>>>>>>>>>> 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 <s...@meiers.net>
> >>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>> 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
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>
