Re: Wicket in JBoss cluster

2009-10-23 Thread Jan Grathwohl
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 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 in-memory sessions.

 On Oct 22, 2009 5:41 PM, Matej Knopp matej.kn...@gmail.com wrote:

 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 replication.

 -Matej

 On Fri, Oct 23, 2009 at 12:00 AM, Randy S. randypo...@gmail.com wrote: 
 Are you saying that beca...

 - To
 unsubscribe, e-mail: users-...



Wicket in JBoss cluster

2009-10-22 Thread Jan Grathwohl
Dear all,

would you be so kind and share your experience about whether it is
reasonable to use Wicket for app development in the following situation:

We are planning to develop an application that will be deployed in our
customer's portlet environment (JBoss Portal). There will be two clustered
JBoss instances with JBoss's own session replication mechanism enabled. The
main reason for the clustering is to have failover that should be
transparent for logged in users, and this has to work really reliably. I
don't know what the exact configuration of the load balancer and the JBoss
servers will be, and how much influence we will have on it.

Is it safe to use wicket in such a situation, or should we rather go for a
more stateless framework?

I did some tests to run a very simple Wicket app in two clustered JBoss
instances, and after I shut down the instance with the active session, the
session continues to be available on the other cluster node, and the links
in the pages still work. So far, so good. But when I hit the browser's back
button, I receive a Page Expired Error. This probably means that the content
of the page store is not correctly replicated to the other cluster node?

Is this a known limitation, or caused by some wrong configuration?

Thanks for any feedback on these topics, please let me know what your
experiences and opinions are.

Kind regards,

Jan


Re: Wicket in JBoss cluster

2009-10-22 Thread Matej Knopp
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

On Thu, Oct 22, 2009 at 10:27 PM, Jan Grathwohl
jan.grathw...@googlemail.com wrote:
 Dear all,

 would you be so kind and share your experience about whether it is
 reasonable to use Wicket for app development in the following situation:

 We are planning to develop an application that will be deployed in our
 customer's portlet environment (JBoss Portal). There will be two clustered
 JBoss instances with JBoss's own session replication mechanism enabled. The
 main reason for the clustering is to have failover that should be
 transparent for logged in users, and this has to work really reliably. I
 don't know what the exact configuration of the load balancer and the JBoss
 servers will be, and how much influence we will have on it.

 Is it safe to use wicket in such a situation, or should we rather go for a
 more stateless framework?

 I did some tests to run a very simple Wicket app in two clustered JBoss
 instances, and after I shut down the instance with the active session, the
 session continues to be available on the other cluster node, and the links
 in the pages still work. So far, so good. But when I hit the browser's back
 button, I receive a Page Expired Error. This probably means that the content
 of the page store is not correctly replicated to the other cluster node?

 Is this a known limitation, or caused by some wrong configuration?

 Thanks for any feedback on these topics, please let me know what your
 experiences and opinions are.

 Kind regards,

 Jan


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



Re: Wicket in JBoss cluster

2009-10-22 Thread Randy S.
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,

 would you be so kind and share your experience about whether it is
 reasonable to use Wicket for app development in the following situation:

 We are planning to develop an application that will be deployed in our
 customer's portlet environment (JBoss Portal). There will be two clustered
 JBoss instances with JBoss's own session replication mechanism enabled. The
 main reason for the clustering is to have failover that should be
 transparent for logged in users, and this has to work really reliably. I
 don't know what the exact configuration of the load balancer and the JBoss
 servers will be, and how much influence we will have on it.

 Is it safe to use wicket in such a situation, or should we rather go for a
 more stateless framework?

 I did some tests to run a very simple Wicket app in two clustered JBoss
 instances, and after I shut down the instance with the active session, the
 session continues to be available on the other cluster node, and the links
 in the pages still work. So far, so good. But when I hit the browser's back
 button, I receive a Page Expired Error. This probably means that the
 content
 of the page store is not correctly replicated to the other cluster node?

 Is this a known limitation, or caused by some wrong configuration?

 Thanks for any feedback on these topics, please let me know what your
 experiences and opinions are.

 Kind regards,

 Jan



Re: Wicket in JBoss cluster

2009-10-22 Thread Matej Knopp
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 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,

 would you be so kind and share your experience about whether it is
 reasonable to use Wicket for app development in the following situation:

 We are planning to develop an application that will be deployed in our
 customer's portlet environment (JBoss Portal). There will be two clustered
 JBoss instances with JBoss's own session replication mechanism enabled. The
 main reason for the clustering is to have failover that should be
 transparent for logged in users, and this has to work really reliably. I
 don't know what the exact configuration of the load balancer and the JBoss
 servers will be, and how much influence we will have on it.

 Is it safe to use wicket in such a situation, or should we rather go for a
 more stateless framework?

 I did some tests to run a very simple Wicket app in two clustered JBoss
 instances, and after I shut down the instance with the active session, the
 session continues to be available on the other cluster node, and the links
 in the pages still work. So far, so good. But when I hit the browser's back
 button, I receive a Page Expired Error. This probably means that the
 content
 of the page store is not correctly replicated to the other cluster node?

 Is this a known limitation, or caused by some wrong configuration?

 Thanks for any feedback on these topics, please let me know what your
 experiences and opinions are.

 Kind regards,

 Jan



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



Re: Wicket in JBoss cluster

2009-10-22 Thread Randy S.
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 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 HTTP Session? This is in the default ISessionStore implementation (see
  SecondLevelCacheSessionStore, DiskPageStore).



Re: Wicket in JBoss cluster

2009-10-22 Thread Matej Knopp
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 replication.

-Matej

On Fri, Oct 23, 2009 at 12:00 AM, Randy S. randypo...@gmail.com wrote:
 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 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 HTTP Session? This is in the default ISessionStore implementation (see
  SecondLevelCacheSessionStore, DiskPageStore).



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



Re: Wicket in JBoss cluster

2009-10-22 Thread Randy S.
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 in-memory sessions.

On Oct 22, 2009 5:41 PM, Matej Knopp matej.kn...@gmail.com wrote:

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 replication.

-Matej

On Fri, Oct 23, 2009 at 12:00 AM, Randy S. randypo...@gmail.com wrote: 
Are you saying that beca...

- To
unsubscribe, e-mail: users-...