[
https://issues.apache.org/struts/browse/WW-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46056#action_46056
]
Wes Wannemacher commented on WW-2985:
-------------------------------------
I think the problem may be more complicated than I thought when I first read
this issue. When the "long-running" action is placed in the session, it is
backgrounded as a thread. I don't see how another server would be able to grab
the thread and continue executing it... I would think that any actions needing
to use the ExecuteAndWaitInterceptor need to remain on one server. There is
another issue that I linked this one too because the same object being
unserializable means that the TokenSessionStoreInterceptor can't work in a
cluster.
I don't have a cluster handy to play around with this, but I would think that
your solution wouldn't really work, as you said, since a running thread isn't
going to easily serialize.
> 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.
