Thanks for the reply.

I decided to ditch the wait page and attempted to fix the root of the
problem:  Requests that require a lot of processing shouldn't be running on
the web server.  By using amazon SQS, I add a job then run a different
process on a separate server to pull down from the queue.

Your solution sounds like something that might work, however.

On Wed, Oct 31, 2012 at 1:15 PM, Poitras Christian <
[email protected]> wrote:

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

Reply via email to