1 2 Previous Next 16 Replies Latest reply on Sep 25, 2010 12:45 PM by deanhiller2000

    Diagnosing Session Serialization (seam 2.1.1.GA)

    sbasinge

      Can anyone tell me tricks, tips on how to determine what objects are causing issues with httpsession cluster?  I had injected an entityhome into my authenticator and it would spit out serialization problems with java.lang.reflect.Method and invalidate the session in my cluster.

        • 1. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
          norman

          Can you post the stack trace and any relevant log lines?  In my experience, you can usually figure it out from that information.

          • 2. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
            sbasinge
            It's worth noting that I am running jboss4.2.2 clustered, seam 2.1.1GA, POJO based JPA and deploying as a war.  I have deployed the booking example ear to ensure my container and cluster work ok.  Upon signing into the booking app, I can see the clustered sessions in the jboss jmx console.  I changed my Jboss-web.xml to include a replication config (granularity:attribute and trigger:SET) which seems to help in that most aatributes are marshalled, and I suspect failover will generally work, although I haven't tested it.

            2009-01-17 13:10:01,428 INFO  [STDOUT] 13:10:01,428 INFO  [Authenticator] Exit onSuccessfulLogin.
            2009-01-17 13:10:01,430 INFO  [STDOUT] 13:10:01,430 WARN  [SessionListener] org.jboss.seam.preRemoveVariable observed
            2009-01-17 13:10:01,431 DEBUG [org.jboss.cache.interceptors.TxInterceptor]  local transaction exists - registering global tx if not present for Thread[ajp-10.40.102.101-9800-8,5,jboss]
            2009-01-17 13:10:01,432 ERROR [org.jboss.web.tomcat.service.session.JBossCacheService] IOException occurred marshalling value
            java.io.NotSerializableException: java.lang.reflect.Method
                    at java.io.ObjectOutputStream.writeObject0(Ljava.lang.Object;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject(Ljava.lang.Object;)V(Unknown Source)
                    at java.util.HashMap.writeObject(Ljava.io.ObjectOutputStream;)V(Unknown Source)
                    at java.lang.LangAccessImpl.writeObject(Ljava.lang.Class;Ljava.lang.Object;Ljava.io.ObjectOutputStream;)V(Unknown Source)
                    at java.io.ObjectStreamClass.invokeWriteObject(Ljava.lang.Object;Ljava.io.ObjectOutputStream;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeSerialData(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeOrdinaryObject(Ljava.lang.Object;Ljava.io.ObjectStreamClass;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject0(Ljava.lang.Object;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.defaultWriteFields(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeSerialData(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeOrdinaryObject(Ljava.lang.Object;Ljava.io.ObjectStreamClass;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject0(Ljava.lang.Object;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject(Ljava.lang.Object;)V(Unknown Source)
                    at java.util.ArrayList.writeObject(ArrayList.java:569)
                    at java.lang.LangAccessImpl.writeObject(Ljava.lang.Class;Ljava.lang.Object;Ljava.io.ObjectOutputStream;)V(Unknown Source)
                    at java.io.ObjectStreamClass.invokeWriteObject(Ljava.lang.Object;Ljava.io.ObjectOutputStream;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeSerialData(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeOrdinaryObject(Ljava.lang.Object;Ljava.io.ObjectStreamClass;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject0(Ljava.lang.Object;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.defaultWriteFields(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeSerialData(Ljava.lang.Object;Ljava.io.ObjectStreamClass;)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeOrdinaryObject(Ljava.lang.Object;Ljava.io.ObjectStreamClass;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject0(Ljava.lang.Object;Z)V(Unknown Source)
                    at java.io.ObjectOutputStream.writeObject(Ljava.lang.Object;)V(Unknown Source)
                    at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:70)
                    at org.jboss.web.tomcat.service.session.JBossCacheService.getMarshalledValue(JBossCacheService.java:966)
                    at org.jboss.web.tomcat.service.session.JBossCacheService.putAttribute(JBossCacheService.java:397)
                    at org.jboss.web.tomcat.service.session.AttributeBasedClusteredSession.processSessionRepl(AttributeBasedClusteredSession.java:145)
                    at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1097)
                    at org.jboss.web.tomcat.service.session.JBossCacheManager.storeSession(JBossCacheManager.java:652)
                    at org.jboss.web.tomcat.service.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
                    at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)

            jmx-console:

              /JSESSION

                /localhost

                  /myLongaberger

                    /15027A93E1787304F90347B71D73D707.jbossstg01
            VERSION: 5
            15027A93E1787304F90347B71D73D707.jbossstg01: [B@2a04a91

                      /ATTRIBUTE
            org.ajax4jsf.application.AjaxStateManager.view_sequence: org.jboss.invocation.MarshalledValue@79215bb1
            user: org.jboss.invocation.MarshalledValue@d054d8e7
            org.jboss.seam.security.ruleBasedPermissionResolver: org.jboss.invocation.MarshalledValue@c2052be0
            facelets.ui.DebugOutput: org.jboss.invocation.MarshalledValue@8449a0c0
            org.jboss.seam.web.session: org.jboss.invocation.MarshalledValue@8d98074d
            NewsForYouManager: org.jboss.invocation.MarshalledValue@bbbb4d88
            org.jboss.seam.international.localeSelector: org.jboss.invocation.MarshalledValue@b292b698
            javax.faces.request.charset: org.jboss.invocation.MarshalledValue@71783d1f
            recognitionLevelManager: org.jboss.invocation.MarshalledValue@a4c6ff9e
            navigationManager: org.jboss.invocation.MarshalledValue@52e8ada
            org.jboss.seam.core.conversationEntries: org.jboss.invocation.MarshalledValue@b771f89b
            org.jboss.seam.security.credentials: org.jboss.invocation.MarshalledValue@9b81c6ea
            associateHome: null
            org.jboss.seam.security.identity: org.jboss.invocation.MarshalledValue@66d29dd4
            org.jboss.seam.theme.themeSelector: org.jboss.invocation.MarshalledValue@fce6675f
            org.jboss.seam.security.rememberMe: org.jboss.invocation.MarshalledValue@6568b3cb
            org.ajax4jsf.application.AjaxStateHolder: org.jboss.invocation.MarshalledValue@e07c076d
            newsForYouItems: org.jboss.invocation.MarshalledValue@2fd6902f


            • 3. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
              sbasinge
              I changed from jrockit jvm to sun 1.5.06 just in case there was something different about java.lang.reflect.Method in jrockit.  I get this error reported about org.jboss.seam.transaction.TransactionInterceptor$TransactionMetadata which is why we are upgrading from 2.0.3CR1 to 2.1.1GA in the first place.

              2009-01-17 14:53:44,994 INFO  [STDOUT] 14:53:44,994 INFO  [Authenticator] Entering onSuccessfulLogin...
              2009-01-17 14:53:44,996 INFO  [STDOUT] 14:53:44,996 INFO  [Authenticator] Exit onSuccessfulLogin.
              2009-01-17 14:53:45,088 INFO  [STDOUT] 14:53:45,088 WARN  [SessionListener] org.jboss.seam.preRemoveVariable observed
              2009-01-17 14:53:45,093 DEBUG [org.jboss.cache.interceptors.TxInterceptor]  local transaction exists - registering global tx if not present for Thread[http-10.40.102.101-8080-4,5,jboss]
              2009-01-17 14:53:45,112 ERROR [org.jboss.web.tomcat.service.session.JBossCacheService] IOException occurred marshalling value
              java.io.NotSerializableException: org.jboss.seam.transaction.TransactionInterceptor$TransactionMetadata
                      at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
                      at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
              • 4. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                sbasinge

                Duh -- you can run jboss server in eclipse as clustered and set a breakpoint on java.io.SerializationException to see what's going on.  It seems to happen on every EntityHome pojo since TransactionMetaData is not Serializable and the TransactionInterceptor holds on to a reference.

                • 5. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                  sbasinge
                  I think what I've found is that the TransactionInterceptor has a HashMap<AnnotatedElement, TransactionMetadata> that is added to the userInterceptors for the JavaBeanInterceptor.  Since neither AnnotatedElement nor TransactionMetaData are serializable, the EntityHome/EntityQuery classes cannot be serialized.  If I either mark userTransactionas as transient on RootInterceptor, make an empty read/write object methods on TransactionInterceptor, or mark my EntityHome/Query classes with @ByPassInterceptors, I don't get the serialization exceptions.

                  Does this make sense?  Am I using the framework classes incorrectly?
                  • 6. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                    sbasinge

                    What I've done for now is mark the transactionMetadata hashmap on TransactionInterceptor as transient and my serialization issues in POJO based/WAR on a cluster have cleared up.

                    • 7. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                      norman

                      Thanks! Can you put your report and fix in a JIRA so we can make sure this gets looked at.  I haven't seen this issue in our clustering tests, so the more detailed you are on how to reproduce it, the easier it will be for us to verify and fix. 

                      • 8. Re: Diagnosing Session Serialization (seam 2.1.1.GA)

                        Was a JIRA entry ever filed for this?  I ran into the same issue and implemented Scott's fix which did work.  If not, I'll open one.  Thanks.

                        • 9. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                          marx3

                          It's standard way: if you have not serializable resource, you mark it as transient and load it again in @PostActivate. What could be done better in Seam/Jboss is to make clear error message exactly which resource cannot be serialized. For now you have to guess which field causes serialization trouble.

                          • 10. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                            sbasinge
                            Just to be clear, my line 86 in TransactionInterceptor is now:

                            private transient Map<AnnotatedElement,TransactionMetadata> transactionMetadata = new HashMap<AnnotatedElement, TransactionMetadata>();


                            Also, I found some issues with Drools, where our custom Identity had non-transient RuleBase, that's been changed to:

                            private transient RuleBase securityRules;

                            Lastly, running JBoss from eclipse with the --configuration=all in the configuration and breakpointing eclipse for SerializationException, then reviewing traces and variables proved to be invaluable to identify what was having a problem.

                            Hope this helps.
                              Scott.
                            • 11. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                              marius.oancea

                              Is it safe to make this map transient?

                              • 12. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                                sbasinge

                                From what I saw in the code, if the map is empty, or doesn't have the key, it will recreate it.  So on cluster failover there may be a few extra of these lookups, but the code seems to handle it fine.

                                • 13. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                                  norman

                                  I don't recall seeing any.  Please report any issue like this in JIRA so we can get them evaluated and cleaned up in the next release.  Thanks!

                                  • 14. Re: Diagnosing Session Serialization (seam 2.1.1.GA)
                                    marius.oancea
                                    1 2 Previous Next