9 Replies Latest reply on Sep 3, 2003 2:38 PM by sbahal

    Big Problem

    sbahal Newbie

      I have a problem:
      I have a 3-tier application. A Tomcat/JSP front and , JBoss/EJB Middle-end and a JBoss/EJB backend. The three layers are indpendent of each other but ofcourse talk to each other. Any of the layers can re-deploy/hotdeploy itself. This is when the problem occurs- I think. I guess some old EJB references are held and by some layer- so at execution time it throws exceptions- as the refrences may have become invalid.
      The exceptions are of the type -Remote Exception:java.rmi.NoSuchObjectException: no such object in table.
      Seems like a complex issue- I really can't even pinpoint the cause. I don't know what the answer may be. But the problem goes away- if I restart JBoss.
      Ideas suggestions welcome.
      Thanks a lot,

        • 1. Re: Big Problem
          Raja Master

          Can you try having a "Depends" tag on the other ejb components.
          For e.g., if ur EJB A has a jndi of "EJBA"

          and you have EJB B depending on EJBA, have a


          which will stop EJB B when EJB A is redeployed. So all of your components would be invalidated when one of them is redeployed.


          • 2. Re: Big Problem
            Adrian Brock Master

            Most likely it is the InitialContext that is invalid.
            Are you caching that?


            • 3. Re: Big Problem
              sbahal Newbie

              Raja- I could not understand your point.
              Adrin- let me elaborate the situation:
              In my 3-tier app everything is initiated by the front end client- that essentially has done a lookup and issues a create() on the lookup. If the create() throws an exception - it has some retry mechanism built in.
              The middle layer only has StateLess EJBs. Some of these EJBs will call on the backend EJBs- they too are StateLess. Each time an EJB is created in the middlelayer - it would do a lookup and isssue a create() on the backend EJB.
              So my thinking is if a create() is issued on the middle layer and if a EJB already exists - the server would provide it from the pool. This EJB may have a bad reference to a backend EJB- beacuase of the backend redeploy (or whatever). Is this a valid line of thinking?

              Adrian- the InitialContext is not cached - each create on the middlelayer - would do the lookup and everything.

              What are the workarounds or how to handle this.

              Thanks a lot,

              • 4. Re: Big Problem
                Adrian Brock Master

                No that is not how it works. You get a remote object
                from the server when you jndi lookups or ejb creates.
                This is invalidated by the server reboot (not a redeploy).

                Post the stacktrace of the error and the jboss version.


                • 5. Re: Big Problem
                  sbahal Newbie

                  The exception I get in the middleEnd is:
                  Remote Exception Exception: java.rmi.NoSuchObjectException: no such object in table.
                  In this case the backend simply re-deployed (not rebooted)- and the front end issued a create() on a cached binding. If the front reboots still I get the same error in the middleEnd.
                  But if I restart JBoss in the middleEnd - everything gets resolved.
                  Version: JBoss_3_0_8 on Windows NT.
                  The stack trace is:
                  11:44:08,666 ERROR [STDERR] java.rmi.NoSuchObjectException: no such object in ta
                  11:44:08,676 ERROR [STDERR] at sun.rmi.transport.StreamRemoteCall.exceptionR
                  11:44:08,676 ERROR [STDERR] at sun.rmi.transport.StreamRemoteCall.executeCal
                  11:44:08,686 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.j
                  11:44:08,686 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker_
                  Stub.invoke(Unknown Source)
                  11:44:08,686 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvo
                  11:44:08,696 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invok
                  11:44:08,696 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke
                  11:44:08,696 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(Se
                  11:44:08,706 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionIntercept
                  11:44:08,706 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(Client
                  11:44:08,716 ERROR [STDERR] at $Proxy73.validateBank(Unknown Source)
                  11:44:08,716 ERROR [STDERR] at com.acs.lockbox.controller.EpayService.valida
                  11:44:08,716 ERROR [STDERR] at com.acs.lockbox.ejb.epay.EpayServiceEJB.valid
                  11:44:08,726 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(
                  Native Method)
                  11:44:08,726 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(N
                  11:44:08,726 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
                  11:44:08,736 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3
                  11:44:08,736 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$Conta
                  11:44:08,746 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedCo
                  11:44:08,746 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.i
                  11:44:08,746 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptorBM
                  11:44:08,756 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorBMT.invoke
                  11:44:08,756 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanc
                  11:44:08,766 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.inv
                  11:44:08,766 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(L
                  11:44:08,766 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invok
                  11:44:08,776 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java
                  11:44:08,776 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MB
                  11:44:08,786 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.
                  11:44:08,786 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor47.invoke(
                  Unknown Source)
                  11:44:08,786 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
                  11:44:08,796 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3
                  11:44:08,796 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(Unic
                  11:44:08,796 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.j
                  11:44:08,806 ERROR [STDERR] at java.security.AccessController.doPrivileged(N
                  ative Method)
                  11:44:08,806 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Trans
                  11:44:08,816 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMess
                  11:44:08,816 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$Connection
                  11:44:08,816 ERROR [STDERR] at java.lang.Thread.run(Thread.java:536)
                  11:44:08,826 ERROR [lockbox] EpayService.validateBank result: BankAccount:Error:
                  Remote Exception Exception:java.rmi.NoSuchObjectException: no such object in table


                  • 6. Re: Big Problem
                    Adrian Brock Master

                    This shows your middle tier has a reference to a remote object
                    from the other tier that is no longer valid.
                    I don't understand how you can lookup the home then
                    use create on the home to get remote object that is wrong?

                    Just a guess try disabling distributed garbage collection
                    or no explicit gc. (Can't remember the parameters off the
                    top of my head).

                    You do know that you need a DTM for this kind of behaviour
                    if you expect the transaction context to be propagated?


                    • 7. Re: Big Problem
                      sbahal Newbie

                      I can not find the params in the documentation or the service file nor the search on the site.

                      In the secenerio described - I do not see a fresh EJB being created- in the middle layer- even though the front end client always issues a create() on already looked up reference. If a fresh EJB would get created in the middlelayer- it would do a backend lookup and and issue a create.


                      • 8. Re: Big Problem
                        Adrian Brock Master

                        Which params?

                        It is the middle -> backend connection that is stale.
                        Any work done by the client will make no difference it is
                        doesn't know anything about the backend.


                        • 9. Re: Big Problem
                          sbahal Newbie

                          1. Params - I meant for the Reomte GC.
                          2. Yes - it is the middleend that fails. Currently I am trying to use the workaround to catch the exception and re-initialize the EJB:

                          } catch (NoSuchObjectException nsoe){
                          try { initializeEJB();
                          } catch (Exception e){}
                          } catch (RemoteException re){