CommandAwareRpcDispatcher error with spring3.0 session scoped bean

[saava]

I'm trying to enable session replication for a hibernate + spring3.0 based application and I have session scoped beans which the app use to carry the state of the application. When clustering is enabled I get the following error:

ERROR [CommandAwareRpcDispatcher] org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'springSessionScopedBean': Scope 'session' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.

Appreciate any help.

[brian.stansberry]

What AS version?

Is there any stack trace?

From the log category my presumption is it's happening during replication, either on the sending side or the receiving side. From the error message, my bet is on the receiving side, since with the standard configuration, all the sending work is done by the request thread.

[saava]

Version JBOSS AS 5.1.0 GA. Yes it's happening during session replication. I don't see any stack traces but this error message appears more than once in the logs on the sender node and am pretty sure I also saw the same error message on the receiver node. I will try to increase the log levels and try to get more information.

[brian.stansberry]

The default conf/jboss-log4j.xml configuration that ships with AS 5.1 will result in the inclusion of the calling thread name in each log message in server.log. It includes (%t) in the log4j PatternLayout.  With that thread name it would be obvious whether the logging came from a http request thread or a JGroups thread handling receipt of a replication message. Or from some other thread if you've got something unusual in your configuration.

Besides looking into that, if the configuration of the JBoss Cache instance used for session replication is changed from the default, please post it. Please also post the contents of any jboss-web.xml you're using.

[saava]

Attached the exception.

I didn't change any settings either in the AS or in my app. (I'm not using jboss-web.xml).

One other thing that I'm doing is , I call session.put when i'm in a SpringAppContext Listner class which I believe should run in the same thread as the web request.

[brian.stansberry]

I can probably guess what the problem is, although unfortunately the stack trace is hiding the real problem.

The problem definitely happened during a normal attempt to replicate the session after application code has handled the request. Session replication is executed by a Tomcat valve that replicates the session when the thread returns from invoking on the application code. My *guess* is whatever Spring code is responsible for making "Scope 'session' active for the current thread" is a servlet filter (i.e. part of the "application code")  and it removes session scope before returning.  By the time the replication happens the session scope is no longer active.

That's only a guess because unfortunately your stack trace shows the problem is coming from:

        at org.jboss.cache.marshall.CacheMarshaller200.objectToObjectStream(CacheMarshaller200.java:195)

and that's actually an error logging message:

         if(log.isErrorEnabled()) log.error("Error while marshalling object: " + o, th);

The exception is thrown when o.toString() is called. That masks whatever the real problem was, which occurred when trying to marshall the session to a byte[] for replication.

My expectation though is the real problem is probably the same thing. You can confirm this by disabling the exection of the log message by editing server/<your config>/conf/jboss-log4j.xml and adding this:

   <category name="org.jboss.cache">
      <priority value="FATAL"/>
   </category>

That will let the real underlying exception propagate and get logged.