> > Matej Knopp-2 wrote: > > > > > > Hi all, > > > > > > I've committed couple of changes to DiskPageStore to address some > > > issues. Mind you the commit is rather fresh and needs to be tested > > > properly before 1.3.1 gets out. > > > > > > First of all it solves the problem of context reloads (see > > > https://issues.apache.org/jira/browse/WICKET-1161). When context is > > > reloaded, the DiskPageStore index is no longer lost and all serialized > > > page files can be used as if no reload has happened. > > > > > > The other improvement is better clustering support > > > (https://issues.apache.org/jira/browse/WICKET-1272). The back button > > > support is improved in clustered environment and also the memory > > > consumption is reduced significantly. > > > > > > What's new? Imagine a simplified environment, cluster with two nodes > > > (NodeA and NodeB). All sessions from a NodeA are replicated to NodeB > > > and vice versa. > > > > > > When a page instance is being replicated from NodeA to NodeB, it is > > > immediately stored to DiskPageStore on nodeB, rather than kept in > > > session. This means that the instance is later accessible on NodeB > > > even after another page from the same pagemap has been replicated to > > > NodeB, because it's already stored in DiskPageStore. Also it doesn't > > > have to be kept in memory, significantly reducing the session state. > > > > > > > > > There is one exception though, where the backbutton won't work across > > > cluster. Imagine following scenario: > > > > > > Session is created to NodeA > > > NodeB goes down > > > User visits page1, page2, page3 on NodeA (these pages were not > > > replicated to NodeB, because the node is not available) > > > NodeB goes up > > > > > > only page3 (the last accessed page in it's pagemap) will be available > > > on NodeB. page1 and page2 are not available, because when they were > > > visited NodeB was not running. page3 is available, because it was > > > active in nodeA session, thus got replicated to NodeB when the context > > > on NodeB was initialized.
> > On Jan 9, 2008 10:24 PM, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > > > > > Ideally, NodeB ought to "catch up" when it joins the cluster by > > syncing the content in the disk page stores at that time. I think > > it's a flaw we should track and fix at some point. > > > > Nice job, Matej! > On Wed, 2008-01-09 at 22:35 -0800, Igor Vaynberg wrote: > this cant be accomplished transparently. we would need our own network > connection, node discovery, blah blah blah. loses a bit of appeal. > > -igor > > I'm intending to stir the pot a bit, but why are we kicking this further? Igor is absolutely right.. For something simple, currently in the linux kernel try drbd [1] 1) Nodes can catch up/sync 2) It'll be faster than anything you can do inside java 3) transparent to the application 4) debugged and proven to work inside a production env 5) means you can revert your changes and we don't have to worry/test anything ----------------------------------- To be honest you may be on the right path long term and I don't currently have a better suggestion, but we are really reinventing the wheel here which leads me to be highly cautious. Thanks ./C [1] http://www.drbd.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
