Re: Wicket in JBoss cluster
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-...
Re: Wicket in JBoss cluster
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
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
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
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
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
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-...
