1 2 Previous Next 17 Replies Latest reply on Mar 31, 2005 3:40 AM by oabidian

    Stateful session bean failed to passivate and save state...

    madadi

      Dear all..

      I am getting a problem with statefull session bean .i am using jboss-3.2.1 after 10 min i am getting following message.

      10:26:35,113 WARN [AbstractInstanceCache] failed to passivate, id=dvyw0hll-5
      javax.ejb.EJBException: Could not passivate; failed to save state; CausedByException is:
      javax.naming.InitialContext
      at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:378)
      at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:85)
      at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:156)
      at org.jboss.ejb.plugins.AbstractInstanceCache.release(AbstractInstanceCache.java:192)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy.ageOut(LRUEnterpriseContextCachePolicy.java:274)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.kickOut(LRUEnterpriseContextCachePolicy.java:446)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.run(LRUEnterpriseContextCachePolicy.java:405)
      at java.util.TimerThread.mainLoop(Timer.java:435)
      at java.util.TimerThread.run(Timer.java:385)
      java.io.NotSerializableException: javax.naming.InitialContext
      at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148)
      at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
      at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1827)
      at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:480)
      at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1214)
      at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
      at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.passivateSession(StatefulSessionFilePersistenceManager.java:370)
      at org.jboss.ejb.plugins.StatefulSessionInstanceCache.passivate(StatefulSessionInstanceCache.java:85)
      at org.jboss.ejb.plugins.AbstractInstanceCache.tryToPassivate(AbstractInstanceCache.java:156)
      at org.jboss.ejb.plugins.AbstractInstanceCache.release(AbstractInstanceCache.java:192)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy.ageOut(LRUEnterpriseContextCachePolicy.java:274)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.kickOut(LRUEnterpriseContextCachePolicy.java:446)
      at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy$OveragerTask.run(LRUEnterpriseContextCachePolicy.java:405)
      at java.util.TimerThread.mainLoop(Timer.java:435)
      at java.util.TimerThread.run(Timer.java:385)


      what could be the reason ?

      regards
      madadi

        • 1. Re: Stateful session bean failed to passivate and save state
          darranl

          When will people start to read the stack traces that they post on these forums?

          java.io.NotSerializableException: javax.naming.InitialContext

          • 2. Re: Stateful session bean failed to passivate and save state
            oabidian

            What a smart reply: "why arent people read the stack trace?". That exception should not be happening: when a bean is passivated , the JNDI ENC must be maintained as part of the bean's conversational state. And it is the duty of the container.
            I wish JBoss would one day work properly.
            Not to mention (which is completely unrelated problem) the documentation from jboss that states that you should be able to specify under
            <mbean code="org.jboss.jms.jndi.JMSProviderLoader" ...>
            <attribute name="ProviderURL">
            ...

            This attribute name is not supported (deprecated, but nowhere in jboss 4.0.1 this is stated), as I found out after lots of painful digging (moving towards old jboss version, where tadaaaa, I finaly see the warning message: is deprecated.
            Very poor indeed.
            And dont say its free, that does not justify this noddie quality

            • 3. Re: Stateful session bean failed to passivate and save state
              starksm64

              Try reading the ejb spec more carefully. There is no requirement to passivate an InitialContext. The spec states that there is a requirement to passivate the Context corresponding to ENC:


              A reference to the environment naming context (that is, the java:comp/env JNDI context) or any of its subcontexts.



              • 4. Re: Stateful session bean failed to passivate and save state
                darranl

                oabidian, You may want to go back and have a look at the EJB specification it may help your understanding of the requirements of the container.

                In the EJB 2.1 specification section 7.4.1 there is a list of the items that can be referenced by a bean that is being passivated, the item relating to JNDI contexts is: -

                A reference to the environment naming context (that is, the java:comp/env JNDI context) or any of its subcontexts.


                The InitialContext is the root context of the server, it is not the environment naming context or a sub-context of the environment naming context.

                So back to my original post, yes the stack trace did contain enough information to inform the original poster what the problem was.

                • 5. Re: Stateful session bean failed to passivate and save state
                  oabidian

                  scott.stark@jboss.org, so why then the Enterprise Java Beans, second edition (can be found on http://safari.oreilly.com) they state that the Context (InitialContext) should be dealt with by the container? Even the examples they give the Context is not transient, nor they deal with it in the Active and Passivate methods? I might be missunderstanding something here, but what I gathered from what I read so far is that the "protected javax.naming.Context jndiContext;" should be dealt by the container. Correct me if I am wrong,
                  Regards,
                  Art.

                  • 6. Re: Stateful session bean failed to passivate and save state
                    darranl

                    Yes it does look as if you may have found a mistake in the book. The only definitive guide is the EJB specification available for download from Sun.

                    From oreilly the session bean chapter can be downloaded for free for the 4th edition. The example does show as you say that the InitialContext is referenced and not handled by ejbPassivate and ejbActivate. At the end of the chapter it does however go on to say that the bean can only hold onto a javax.naming.Context if it references the JNDI ENC.

                    The setSessionContext should be rewritten as: -

                    public void setSessionContext(javax.ejb.SessionContext cntx) {
                     ejbContext = cntx;
                     try {
                     Context context = new InitialContext();
                     jndiContext = context.lookup("java:comp/env");
                     } catch(NamingException ne) {
                     throw new EJBException(ne);
                     }
                    }
                    


                    Then all lookups using the jndiContext should ommit the "java:comp/env".

                    I expect that the reason this has not been discovered sooner is because when executed the client will be calling remove before the need for passivation so noone will have seen the bean being passivated.

                    • 7. Re: Stateful session bean failed to passivate and save state
                      oabidian

                      darranl,
                      This is not working either!

                      • 8. Re: Stateful session bean failed to passivate and save state
                        oabidian

                        I am sorry to say it but I am not convinced about the quality of this.

                        • 9. Re: Stateful session bean failed to passivate and save state
                          darranl

                          Ok, I will have a look this, I will get back to you tomorrow.

                          • 10. Re: Stateful session bean failed to passivate and save state
                            darranl

                            Ok I have had a look at passivation of JNDI ENC references, here is the session bean that I have created: -

                            package com.darranl.encstateful.implementation;
                            
                            import javax.ejb.CreateException;
                            import javax.ejb.EJBException;
                            import javax.ejb.SessionBean;
                            import javax.ejb.SessionContext;
                            import javax.naming.Context;
                            import javax.naming.InitialContext;
                            import javax.naming.NamingException;
                            
                            /**
                             *
                             * @author Darran L
                             */
                            public class ENCStatefulBean implements SessionBean {
                            
                             /** */
                             private static final long serialVersionUID = 3257283621751632952L;
                            
                             /** */
                             private SessionContext ejbContext;
                            
                             /** */
                             private Context jndiContext;
                            
                             /** */
                             private String message;
                            
                             /**
                             *
                             * @throws CreateException
                             */
                             public void ejbCreate() {
                             message = "";
                             }
                            
                             public void addString(final String string) {
                             message += string;
                             }
                            
                             public String getString() {
                             return message;
                             }
                            
                             /**
                             * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
                             */
                             public void setSessionContext(final SessionContext ejbContext) {
                             this.ejbContext = ejbContext;
                             try {
                             Context ctx = new InitialContext();
                             jndiContext = (Context) ctx.lookup("java:comp/env");
                             } catch (NamingException e) {
                             throw new EJBException("Unable to lookup JNDI Context", e);
                             }
                             }
                            
                             /**
                             * @see javax.ejb.SessionBean#ejbRemove()
                             */
                             public void ejbRemove() {
                             }
                            
                             /**
                             * @see javax.ejb.SessionBean#ejbActivate()
                             */
                             public void ejbActivate() {
                             System.out.println("ejbActivate");
                             }
                            
                             /**
                             * @see javax.ejb.SessionBean#ejbPassivate()
                             */
                             public void ejbPassivate() {
                             System.out.println("ejbPassivate");
                             }
                            
                            }


                            My client calls create followed by addString, the client then waits long enough for the bean to be passivated.

                            The bean is passivated with no error.

                            The client then calls the getString method, the bean is activated correctly and the string is returned.

                            In all of this not a single error is reported.

                            Can you please post the full code of your session bean and the error that you are getting.


                            • 11. Re: Stateful session bean failed to passivate and save state
                              oabidian

                              I am having a strange problem. Let me describe it shortly.
                              I am having a simple java class, lets call it MyUtil. This class does a
                              jndi = new InitialContext( props ) in the constructor and uses this "jndi" object to look up a remote home of a session bean, and then create a reference to the remote interface (using the retrieved home with the jndi). The "props" for the jndi = new InitialContext( props ) is set up in that way that it is pointing to a remote box situated somewhere else in the local lan. This MyUtil class has a method that just simply calls a method on the remote referenc obtained in the constructor. Now, this class (MyUtil) is used by a local session bean. The odd thing that happens is that when the local session bean uses the instance of the MyUtil, even though it looks like the MyUtil it did obtained a remote reference to the session bean on the remote box, the result of the call it actually is happening on the local box (eventualy the remote session bean - well the one it should be called on the remote box- generates some entity beans). When the MyUtil is uses in the exact same way but by a client app and not a local sessio bean, the remote session bean (on the remote box) is actually called as expected: on the remote box and not on the local box (as it happens when accessed from the local session bean). I have to mention that the session bean that the MyUtil is trying to access on the remote box, it does exists (deployed) on the local box too, but the jndi context is definately created for the remote box.
                              I susspect this has to do with the NamingService and how it does the NamingService association, but i am not sure why, how and what happens. Could anyone please help?

                              [/img]

                              • 12. Re: Stateful session bean failed to passivate and save state
                                oabidian

                                I found what was it: even though i am using a different InitialContext (created to point to the remote box), the Session bean B 's JNDI name existing localy in the ENV it takes over, and any lookups (even using different InitialContext's) is done using this exisiting jndi name. I wonder if this is a bug in the NamingService implementation? Differrent NamingContext associated with different NamingServers should not override eachother.
                                Thoughts?
                                Art.

                                • 13. Re: Stateful session bean failed to passivate and save state
                                  darranl

                                  What is the String that you are passing into the call to lookup?

                                  • 14. Re: Stateful session bean failed to passivate and save state
                                    oabidian

                                    The JNDI name of the session bean: SomeSBHomeRemote.JNDI_NAME (which is: public static final String JNDI_NAME="ejb/SomeSBRemote";) So it will be the same deployed on the local box and the remote box, and the session bean is deployed on box computers. But on the local box I am using a InitialContext set up to point to the remote box. So I dont think why it has this featuretter and overrides the lookup. It looks to me that it binds the JNDI name to a NaminServer and any subsequent lookups (en usiveng different NamingServers) are done via this binding. This is not desired at all: whats the point of having NamingServers if on can overtake the other (functionality wise)?

                                    1 2 Previous Next