clustering exception....

[deanhiller2000]

So, we add the distributable tag in web.xml.  That resulted in the following exception(though this exception never occurred in non-clustered mode AND it doesn't seem to affect the app at all...it only affects clustering not working)....

fillInParams happens to be a conversation scoped action bean that injected the user from the session(ie. the logged in user).  It holds conversation state and has an action method as well.  Any ideas on why this would occur?  I searched but don't see anyone with similar problems here....

2009-08-18 09:13:01,017 WARN  [org.jboss.web.tomcat.service.session.InstantSnapshotManager./portal] (http-0.0.0.0-8080-8) N/A Failed to replicate session SDH6JZRK9BV3qKjvHqiStg_
org.jboss.seam.RequiredException: @In attribute requires non-null value: fillInParams.user
        at org.jboss.seam.Component.getValueToInject(Component.java:2297)
        at org.jboss.seam.Component.injectAttributes(Component.java:1703)
        at org.jboss.seam.Component.inject(Component.java:1521)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.ConversationInterceptor.aroundInvoke(ConversationInterceptor.java:65)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:118)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
        at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
        at net.voicelog.custom.PageBFillInReportParams_$$_javassist_7.hashCode(PageBFillInReportParams_$$_javassist_7.java)
        at java.util.HashMap$Entry.hashCode(HashMap.java:720)
        at java.util.AbstractMap.hashCode(AbstractMap.java:461)
        at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.<init>(SimpleCachableMarshalledValue.java:74)
        at org.jboss.ha.framework.server.SimpleCachableMarshalledValue.<init>(SimpleCachableMarshalledValue.java:80)
        at org.jboss.web.tomcat.service.session.distributedcache.spi.SessionSerializationFactory.createMarshalledValue(SessionSerializationFactory.java:74)
        at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.getMarshalledValue(AbstractJBossCacheService.java:641)
        at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.putSession(AbstractJBossCacheService.java:405)
        at org.jboss.web.tomcat.service.session.ClusteredSession.processSessionReplication(ClusteredSession.java:1194)
        at org.jboss.web.tomcat.service.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1635)
        at org.jboss.web.tomcat.service.session.JBossCacheManager.storeSession(JBossCacheManager.java:294)
        at org.jboss.web.tomcat.service.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
        at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:120)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
        at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
        at org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn.invoke(ClusteredSingleSignOn.java:672)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:619)

[deanhiller2000]

What is very interesting is that the Map used in this case is different than the Session map and it is totally empty.  I was stepping through the seam code to figure this out.  Is there some kind of annotation I need to outject into this replication session map or someething?  Why is the Map different than the normal Session Map(which is why my object is null)???

How do the internals of seam work with replication exactly so I can debug this more?

thanks for any info,
Dean

[kapitanpetko]

You also need this in components.xml to get proper replication of the SMPC.

<core:init distributable="true"/>

You need to make sure that everything you outject is Serializable.

Read this for more info: Clustering and EJB Passivation

[deanhiller2000]

sorry, I forgot to mention that we have that already. 

do I need my EJB3 entity beans to implement Mutable as well?  ie the documentation was not exactly clear on this and I assumed no since Hibernate already knows if my User is dirty or not since it proxied the user object. 

I am stumped still.  One interesting note though is that the design seems nice in that when clustering fails, the applicaiton doesn't fail usually...it keeps working just fine...nice design though we have one specific screen that when clustering is broke, the app is broke..not sure why yet.

Anyone know more detail about clustering to help me step through the seam code more efficiently? 

[kapitanpetko]

Dean Hiller wrote on Aug 19, 2009 19:22:


do I need my EJB3 entity beans to implement Mutable as well?  ie the documentation was not exactly clear on this and I assumed no since Hibernate already knows if my User is dirty or not since it proxied the user object. 

You don't need to implement Mutalble for this to work, it just makes replication more efficient. I has actually nothing to do with
Hibernate, session replication doesn't know anything about Hibernate.

Are you sure you set up clustering correctly? I.e., did you verify that replication works? Or is it failing for just this one object?
It might help if you could show the code that outjects User.