Hello Martin,
so I've been trying to still get to the bottom of this days later. So my
understanding is getting better and it appears that the session itself is
replicated fine. However I've tracked my issue down to the following:
- If I have a page that has 2 links at the top. Link A is a Bookmarkable
link back to the same page - it is also mounted thus: mountPage(
"/cube/documents/${0}", CubeDocumentPage.class); It has a Long page param
needed to construct the page ( i.e. /cube/documents/12345 ). The second
link B is just a simple new Link<Void>("B") .
- If both instances are up and running , lets say I am on instance A. I
visit link A 3 times. I then kill instance A and I am balanced over to
instance B. If I visit link B , the PageStoreManager cannot find the page
that contains link B in the store and then tries to create a new instance
of the page - the problem is then for some reason the page parameters are
always null and the Long is never passed. Why is the page parameter always
null here? Trying to debug it, is seems the IPageManager is got from the
wicket Application instance and not the Session, and this IPageManager
looks for a RequestAdaptor. Somewhere the page parameters are lost?.
However I can get it to work this way:
- start instance A, visit the page and say click link A 3 times.
- Now start up instance B
- Kill instance A
- Click on the link B and this time the PageStoreManager finds the page and
there the link B and everything works fine.
It only works if I don't visit another page just after instance B starts up.
I will do some more debugging tomorrow to try and understand this
PageStoreManager/request adaptor bit more. But if you have any ideas I'd
appreciate it.
Thanks
On Fri, Mar 24, 2017 at 12:48 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Hi,
>
> On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <waynemailingli...@gmail.com>
> wrote:
>
> > Thanks Martin,
> >
> > I have a theory what this is, perhaps you could confirm?
> >
> > What I observe is the following with the replication: If I visit page A
> and
> > then visit page B, then kill the instance I am on the session is
> > successfully failed over to the other node. Now I'm still looking at
> page B
> > in the browser - if I hit back on the browser I get PageExpiredException.
> > Is this the expected behaviour?
> >
>
> No.
> The expected behavior is to see the latest state of page A.
>
>
> >
> > If it IS the expected behaviour, then the reason I think that I have an
> > issue with the page with the AbstractDefaultAjaxBehavior is because the
> > code in the AbstractDefaultAjaxBehaviour.respond is adding components to
> > the page which in turn marks the Session dirty which in turn replicates
> the
> > session. If only the last page/session commit is only replicated it could
> > explain why I get a ComponentNotFound exception from the page as
> > it overwriten by the update from the AbstractDefaultAjaxBehavior
> >
>
> Any time the page is marked as dirty Wicket will store it in 1) the HTTP
> session and 2) on the disk
> 1) will notify the web server (e.g. Tomcat) that it has to replicate the
> session because some attribute has been modified
> At node2 Wicket will detect the replicated session in #readObject() and
> store it on the disk.
> From now on node2 will have the same history for that page as node1, i.e.
> PageA and PageB.
>
> In addition:
> Updates made in an Ajax requests do not add a new entry in the history
> (storages) but overrides the previous entry for that page instance!
> I.e. when PageA is rendered Wicket will assign a pageId for it, e.g. 5, and
> store it in the disk.
> Later when you make a change to PageA:5 in Ajax request then Wicket will
> override the entry on the disk.
> If you make a change in non-Ajax request then Wicket will assign a new
> pageId, e.g. 6, and add a new entry in the history (disk), so you will have
> two entries for this session.
> Later when you open PageB then this will be pageId 7, etc.
>
>
> >
> > What do you think?
> >
> >
> >
> > On Fri, Mar 24, 2017 at 9:31 AM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > Once the http session is replicated this method should be executed on
> the
> > > node that did not process the request
> > > org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
> > > Here Wicket will either store the page(s) on the disk or will schedule
> > them
> > > for storing.
> > > There is no much usage of Loggers here so you will have to attach a
> > > debugger and see what happens.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Thu, Mar 23, 2017 at 6:11 PM, Wayne W <waynemailingli...@gmail.com>
> > > wrote:
> > >
> > > > If I put the AbstractDefaultAjaxBehavior back in, it always fails.
> If I
> > > > remove the AbstractDefaultAjaxBehavior most of the time it works, but
> > > every
> > > > now and then it fails to replicate. Its really inconsistent.
> > > >
> > > > I have no idea how to get to the bottom of this. Any pointers or help
> > is
> > > > much appreciated.
> > > >
> > > > On Thu, Mar 23, 2017 at 4:53 PM, Wayne W <
> waynemailingli...@gmail.com>
> > > > wrote:
> > > >
> > > > > So it seems the homepage is not the only page. However removing the
> > > > > AbstractDefaultAjaxBehavior makes no difference I still get the
> same
> > > > > issues. Just don;t know where to start with this one. Is there a
> way
> > I
> > > > can
> > > > > turn on the logging around replication in wicket?
> > > > >
> > > > > On Thu, Mar 23, 2017 at 4:27 PM, Wayne W <
> > waynemailingli...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hi Martin,
> > > > >>
> > > > >> no - I still get the ComponentNotFoundException in the new
> instance.
> > > :-/
> > > > >>
> > > > >> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov <
> > > mgrigo...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >>> Hi,
> > > > >>>
> > > > >>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W <
> > > waynemailingli...@gmail.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>> > Hi Martin,
> > > > >>> >
> > > > >>> > that was a typo on my part. I've been doing a lot more testing
> > > > before I
> > > > >>> > replied to make sure things are as I say. This is what I am
> > > > observing:
> > > > >>> >
> > > > >>> >
> > > > >>> > - I have a 2 node tomcat cluster setup with apache balancing
> > > > between
> > > > >>> > them locally on my machine.
> > > > >>> > - Testing with a very simple Wicket app I can see the
> > > replication
> > > > is
> > > > >>> > working fine when shutting down either instance.
> > > > >>> > - Testing with our very heavy weight wicket app it sometimes
> > > work
> > > > >>> and
> > > > >>> > sometimes does not.
> > > > >>> >
> > > > >>> > Now the last point above I have narrowed down to our homepage.
> > If I
> > > > am
> > > > >>> not
> > > > >>> > on the homepage the replication seems to work ok. However if I
> am
> > > on
> > > > >>> the
> > > > >>> > homepage I always get a ComponentNotFoundException when failing
> > > over
> > > > >>> to the
> > > > >>> > other instance.
> > > > >>> > The homepage has an AbstractDefaultAjaxBehavior which is called
> > > once
> > > > >>> the
> > > > >>> > page is rendered, this in turn adds to the the page a DataView
> > > > >>> containing a
> > > > >>> > lot of content and links. The user needs to be logged in before
> > > they
> > > > >>> see
> > > > >>> > the homepage, so the session is already setup.
> > > > >>> >
> > > > >>> > I don't know what it is about this page that breaks the
> > > replication.
> > > > Is
> > > > >>> > there anything around the ajax part that could do this? Any
> > > pointers
> > > > >>> would
> > > > >>> > be most welcome as it will be a long long task to break that
> page
> > > > down
> > > > >>> and
> > > > >>> > do rounds and rounds of cluster testing
> > > > >>> >
> > > > >>>
> > > > >>> Let's try something!
> > > > >>> In you Ajax callback method do something like:
> > > > >>> getSession().setAttribute("someKey",
> UUID.randomUUID().toString())
> > > > >>> Does this trigger replication ?
> > > > >>>
> > > > >>>
> > > > >>> >
> > > > >>> > many thanks
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> >
> > > > >>> > On Wed, Mar 22, 2017 at 12:34 PM, Martin Grigorov <
> > > > >>> mgrigo...@apache.org>
> > > > >>> > wrote:
> > > > >>> >
> > > > >>> > > Hi,
> > > > >>> > >
> > > > >>> > > "I can stop one of the instances and I'm not logged in"
> > > > >>> > > This statement says that you don't really have a properly
> > > > configured
> > > > >>> > > failover.
> > > > >>> > > If those two Tomcat instances are in a cluster then the http
> > > > sessions
> > > > >>> > > should be replicated and you should stay logged in no matter
> > > which
> > > > >>> one is
> > > > >>> > > serving the request.
> > > > >>> > > Wicket will store the used stateful page at the disks for all
> > > > >>> Tomcats in
> > > > >>> > > the cluster, if it the replication is actually working!
> > > > >>> > >
> > > > >>> > >
> > > > >>> > > On Wed, Mar 22, 2017 at 1:02 PM, Wayne W <
> > > > >>> waynemailingli...@gmail.com>
> > > > >>> > > wrote:
> > > > >>> > >
> > > > >>> > > > Hi,
> > > > >>> > > >
> > > > >>> > > > We have 2 instances of Tomcat running with Apache sitting
> in
> > > > front
> > > > >>> > > > balancing between the Tomcat instances. I have session
> > > > replication
> > > > >>> > setup
> > > > >>> > > > which seems to work for basic bookmarkable links on the
> > pages.
> > > I
> > > > >>> can
> > > > >>> > stop
> > > > >>> > > > one of the instances and I'm not logged in as it failover
> to
> > > the
> > > > >>> other
> > > > >>> > > > instance.
> > > > >>> > > >
> > > > >>> > > > However for normal Link<?> and ajax links etc I get
> > > > >>> > > > ComponentNotFoundException thrown as the new instance
> cannot
> > > > find
> > > > >>> it
> > > > >>> > in
> > > > >>> > > > the session it seems.
> > > > >>> > > >
> > > > >>> > > > Clearly I'm not understanding how wicket manages the page
> > state
> > > > or
> > > > >>> I've
> > > > >>> > > > configured something wrong.
> > > > >>> > > >
> > > > >>> > > > Does wicket support full session failover ?
> > > > >>> > > >
> > > > >>> > > > Many thanks
> > > > >>> > > >
> > > > >>> > >
> > > > >>> >
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
