[
https://issues.apache.org/struts/browse/WW-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wes Wannemacher closed WW-2985.
-------------------------------
Resolution: Won't Fix
Brian, I am going to close this as "Won't Fix" only because I don't see any way
that making this work in a cluster is feasible. I think your workaround will
let your app run in a cluster, but as you mentioned, it's not really a good
solution. I would like to leave it open and mark for the future, but I don't
know of any way to get a running thread to replicate to another server...
Especially if the thread performs processing on data that should only be done
once. This is a tricky topic and I don't think there is any good solution other
than to keep long-running actions on a single server.
> ExecuteAndWaitInterceptor puts non-serializable object on the session
> ---------------------------------------------------------------------
>
> Key: WW-2985
> URL: https://issues.apache.org/struts/browse/WW-2985
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.1.6
> Environment: All
> Reporter: Brian Levine
> Priority: Critical
>
> Using ExecuteAndWaitInterceptor puts StrutsRequestWrapper on the session.
> This causes a NotSerializable exception in Tomcat (and I suppose other app
> servers) when session serialization for clustering is enabled.
> The problem appears to be a member variable in BackgroundProcess which
> contains a reference to StrutsRequestWrapper in its object containment
> hierarchy.
> The result of this bug is that no session data is replicated when an action
> using the ExecuteAndWaitInterceptor is invoked. It should also be noted that
> BackgroundProcess (the class that is actually added to the session) contains
> a reference to ActionInvocation which can result in quite a bit of data being
> added to the session. This should be stripped down so that only the absolute
> minimum information necessary to execute the action is added to
> BackgroundProcess.
> Temporary workaround:
> I created my own subclass of ExecuteAndWaitInterceptor and overrode
> getNewBackgroundProcess to return my own implementation of BackgroundProcess
> in which the two suspect member variables are declared transient. This at
> least fixes the NotSerializableException although there is still a window of
> vulnerability if one node in a cluster goes down while the application is in
> the middle of an action that uses the ExecuteAndWaitInterceptor.
> See also: WW-2803
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
