Hi, Did you mention already which version of Wicket you use ? There was an improvement related to reusing the page parameters when constructing a new page instance in 7.0.0. I have the feeling you are using 6.x. Am I correct ?
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Mar 28, 2017 at 7:22 PM, Wayne W <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > Hi, > > > > On Fri, Mar 24, 2017 at 1:31 PM, Wayne W <[email protected]> > > 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 <[email protected] > > > > > 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 < > [email protected]> > > > > 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 < > > [email protected]> > > > > > 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 < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > >> Hi Martin, > > > > > >> > > > > > >> no - I still get the ComponentNotFoundException in the new > > instance. > > > > :-/ > > > > > >> > > > > > >> On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov < > > > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W < > > > > [email protected]> > > > > > >>> 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 < > > > > > >>> [email protected]> > > > > > >>> > 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 < > > > > > >>> [email protected]> > > > > > >>> > > 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 > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > >
