Re: ComponentNotFoundException and Clustering failover

[Martin Grigorov]

On Thu, Apr 13, 2017 at 12:27 AM, Wayne W 
wrote:

> Hi Martin,
>
> Ok I've opened a ticket. I did some more debugging and I've described it to
> the best of my understanding. I could try and make a patch but its complex
> code and I don't want to mess anything up!! - not very confident with
> Wicket.
>
> https://issues.apache.org/jira/browse/WICKET-6356


Thank you!


>
>
> thanks
>
>
> On Mon, Apr 3, 2017 at 8:19 AM, Martin Grigorov 
> wrote:
>
> > Hi,
> >
> > On Thu, Mar 30, 2017 at 11:21 PM, Wayne W 
> > wrote:
> >
> > > Please ignore my last email I have done a lot more debugging and I
> > *think*
> > > I understand why replication does not work for us:
> > >
> > >
> > > Whenever a stateful pages is used (touched) the SessionEntry is
> updated,
> > > > i.e. the page is put into it.
> > > > The SessionEntry is stored as an attribute in the HTTP Session.
> > > > The web container has logic to detect if the HTTP session has been
> > > updated
> > > > in a request and if it was then it replicates the whole session to
> the
> > > > other nodes.
> > > > Once the session is replicated it is deserialized. Here
> > > > SessionEntry#readObject() comes to play. It reads the pages from the
> > > > SessionEntry and stores them into the disk (via IDiskStore).
> > > > So the stateful pages should be available in the disks of all nodes.
> > > > Stateless pages are always recreated from scratch, so they are not
> > > > replicated.
> > >
> > >
> > > I think this is a little wrong. Yes the SessionEntry in stored as an
> > > attribute in the http session and is replicated. However the pages in
> the
> > > SessionEntry cache are not replicated as they are transient.
> > >
> > > private transient List sessionCache;
> > >
> >
> > This looks like a bug!
> > It shouldn't be transient.
> > Please open a ticket!
> > Could you please provide your Tomcat configuration related to replication
> > too ?
> > A patch / Pull Request is also very welcome!
> >
> > Thank you!
> >
> >
> > >
> > > private transient List afterReadObject
> > >
> > > Therefore the pages are *not* deserialised as you say. The only time
> > > SessionEntry#readObject()
> > > comes to play (at least with Tomcat) is when a node is first brought up
> > and
> > > the daltamanager replicates ALL sessions across, at this point all the
> > > current SessionEntry's in the other nodes http sessions are written
> > across.
> > > After this is done SessionEntry#readObject() is not called anymore. Any
> > new
> > > pages/updates on the original instance are not replicated across (only
> > the
> > > sessionId in the SessionEntry).
> > >
> > > This means any new pages created on the old instance (after the new
> > > instance has started up) are not available in the http session or the
> > > second level page store on the new instance.
> > > Therefore when the old instance in shut down the user is load balanced
> to
> > > the new instance. At this point the link in the page Wicket is looking
> > for
> > > does not exist in the SessionEntry cache or the PageStore so it creates
> > the
> > > page and looks for the component/link.
> > >
> > > This causes a ComponentNotFoundException for us because the links are
> > > either in a DataView which is never rendered so does not exist, or the
> > > other links are actually added to the page in an Ajax request and again
> > > because the page is not rendered are not there, Wicket then throws the
> > > exception and it appears to the user the session is lost.
> > >
> > > This is at least what I am observing. I can provide a Quick start to
> > > demonstrate if needed.
> > >
> > > many thanks for you time thus far.
> > >
> > >
> > > On Thu, Mar 30, 2017 at 4:29 PM, Wayne W 
> > > wrote:
> > >
> > > >
> > > >
> > > > On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov <
> mgrigo...@apache.org
> > >
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >> Whenever a stateful pages is used (touched) the SessionEntry is
> > updated,
> > > >> i.e. the page is put into it.
> > > >>
> > > >
> > > > Yes I can see that happening in PageStoreManager.storeTouchedPages()
> > > >
> > > >
> > > >> The SessionEntry is stored as an attribute in the HTTP Session.
> > > >>
> > > >
> > > > I'm not seeing this. In the wicket.Session class there is line :
> > > >
> > > > private transient ISessionStore sessionStore;
> > > >
> > > > Which is loaded from the Application each request. The SessionStore
> > > > contains the SessionEntry's no???
> > > >
> > > >
> > > >
> > > >> The web container has logic to detect if the HTTP session has been
> > > updated
> > > >> in a request and if it was then it replicates the whole session to
> the
> > > >> other nodes.
> > > >>
> > > >
> > > > Yes I'm seeing the http session replicated no issues.
> > > >
> > > >
> > > >> Once the session is replicated it is deserialized. Here
> > > >> SessionEntry#readObject() comes to play. It 

nice tutorial : "Call Apache Wicket from Javascript / Back Button Behavior"

[Francois Meillet]

For all those who are interested by this subject, have a look at this very good 
tutorial

https://twitter.com/apache_wicket/status/852786047746322434


François




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