Hi,
I don't think it's currently possible for @WaitPage to run on multiple server.
It was not programmed to support a multi-server environment.
I don't think it can support sticky sessions right now, but it may be possible
to change the code to make it work.
The best thing you can do is look at the code and ask me or Aaron Porter for
details. If you can find a way to support multi-server, I'll be happy to look
at the code and commit it to StripesStuff.
I think the first thing to do is replace the contexts attribute of the
interceptor to store it in session.
private Map<Integer, Context> contexts = new ConcurrentHashMap<Integer,
Context>();
Christian
De : Adam Stokar [mailto:[email protected]]
Envoyé : October-31-12 10:07 AM
À : Stripes Users List
Objet : [Stripes-users] Stripes WaitPageInterceptor Issue
Hi all,
I am using the Stripes WaitPage Interceptor for an action that takes a while.
We use redis (in-memory key-value store) to store sessions outside of tomcat.
It works fine when I test it locally. However, when I deploy it to our
production environment, I am getting an NPE at the following line
104
context.actionBean.setContext(executionContext.getActionBeanContext());
Our production environment has 2 or more webservers and we are offloading
sessions to an in-memory store. I have a feeling that the issue is due to the
fact that we have non-sticky sessions so subsequent WaitPage requests can go to
a different server. My question is, does the same server have to handle the
wait page updates as the server that handled the initial request? If not,
could anyone think of why else I might be getting this exception?
Thanks,
Adam
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
