2 Replies Latest reply on Jun 21, 2006 5:23 PM by Andy W. Clements

    RequestFacade - not serializable

    Andy W. Clements Newbie

      Hello Forum Folks,

      This might belong in the Tomcat part of the forums, but it kinda overlaps with the cache so I thought I would start here first.

      I know this error pops up from time to time on the forums, but I have few questions about it that might make it a tad more palatable. The error is the following:

      13:13:11,461 ERROR [JBossCacheService] externalizeSession(): exception occurred externalizing session SessionBasedClusteredSession[id: OaE-UncPjhF1u2tWE799tg** lastAccessedTime: 1150920790929 version: 14 lastOutdated: 0]
      java.io.NotSerializableException: org.apache.catalina.connector.RequestFacade
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
       at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
       at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
       at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
       at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
       at java.util.Hashtable.writeObject(Hashtable.java:813)
       at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
       at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
       at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
       at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
       at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
       at org.jboss.web.tomcat.tc5.session.SessionBasedClusteredSession.writeExternal(SessionBasedClusteredSession.java:175)
       at org.jboss.web.tomcat.tc5.session.JBossCacheService.externalizeSession(JBossCacheService.java:902)
       at org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:348)
       at org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
       at org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:994)
       at org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:637)
       at org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:52)
       at org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:105)
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
       at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
       at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
       at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
       at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
       at java.lang.Thread.run(Thread.java:595)

      So, it seems that this error is not really effecting the way the cache operates, but it is occupying huge amount of space in my logs and makes it very hard to determine where the "real" errors are occuring.

      (1) Is there any way to shut off the error message for this specific error without turning off the entire log4j ERROR messages for the cache? If there is another error in the cache, I would probably want to know about it.

      (2) Failing number (1), is there any reason not to make the RequestFacade object serializable? Does anyone know which jar this class resides in? If I make this class serializable and recompile the jar, would there be any adverse effects? (According to the facts in my brain, this should work fine).

      (3) Assuming (2) is acceptable. Is there any way for JBoss to "adopt" this code and make it serializable in the build? Or am I barking up the wrong tree on this issue and should I go bother the Tomcat folks about this? Hell, I would be glad to donate the time to push this through the next build if someone can gently guide me on what I need to do to get it done.

      Thanks for your time,


        • 1. Re: RequestFacade - not serializable
          Brian Stansberry Master

          It's absolutely affecting the way the cache operates -- your session isn't being replicated properly.

          To answer your questions:

          1) The only way to get rid of this logging is to set logging for JBossCacheService to FATAL. You'll lose a lot of other error messages that way, though.

          2) You would need to ask this on the Tomcat lists.

          3) No, we wouldn't adopt such a change; it would have to come through the Tomcat code base.

          Why are you storing the request in the session anyway?

          • 2. Re: RequestFacade - not serializable
            Andy W. Clements Newbie

            I didn't know I was storing the request in the session. Is this an option in the configuration that I can change? Becuase I am pretty sure I'm not doing this programmatically.

            We do have Macromedia Flex on the front end of the application. Maybe it is storing the request in the session? I know they don't certify their product on JBoss, maybe this is why.

            We have tested the cache before and it seems to replicate with no problem, even though these errors are occuring.

            hmmmm strangely curious.

            Thanks for the input!