Thanks guys, I think I understand now what's going on.
Does anyone know which configuration settings are needed for JBoss 4.2 to
make things work?
2009/10/23 Randy S. randypo...@gmail.com
Oh I see. Thanks for the explanation.
I can't comment on JBoss's session replication. I'm familiar
Well, if JBoss doesn't deserialize session immediately after
replication (which i have no idea if it does) the back button will not
work. However if you are using sticky sessions (which you definitely
should) then this will only be issue when user click back button
after a node went down.
-Matej
Isn't this caused by the storage of past pages in files on disk rather than
in HTTP Session? This is in the default ISessionStore implementation (see
SecondLevelCacheSessionStore, DiskPageStore).
On Thu, Oct 22, 2009 at 3:27 PM, Jan Grathwohl jan.grathw...@googlemail.com
wrote:
Dear all,
Yes. But wicket tries to store the page being sent across cluster
during replication when the session is deserialized on target node.
-Matej
On Thu, Oct 22, 2009 at 11:46 PM, Randy S. randypo...@gmail.com wrote:
Isn't this caused by the storage of past pages in files on disk rather than
in
Are you saying that because HTTP Session will contain the
last-displayed-page, a single back button after failover should have worked
because the second server would have persisted that one page to its own
disk?
On Thu, Oct 22, 2009 at 4:49 PM, Matej Knopp matej.kn...@gmail.com wrote:
Yes. But
Not quite. On every request when page is changed and the session with
page is replicated on cluster the receiving nodes should store the
page to diskpagestore. This way every state of page should be saved.
But this will only work if the container deserializes sessions
immediately after
Oh I see. Thanks for the explanation.
I can't comment on JBoss's session replication. I'm familiar with websphere
with a DB-backed session which does not deserialize until it has to re-load
from the DB, either because you bounced nodes or had the session expunged
from memory due to the limit of
