Big Problem

[sbahal]

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,
Sanjay

[raja05]

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

jboss.j2ee:jndiName=EJBA,service=EJB

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

-Raj

[adrian.brock]

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

Regards,
Adrian

[sbahal]

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,
Sanjay

[adrian.brock]

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.

Regards,
Adrian

[sbahal]

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
ble
11:44:08,676 ERROR [STDERR] at sun.rmi.transport.StreamRemoteCall.exceptionR
eceivedFromServer(StreamRemoteCall.java:247)
11:44:08,676 ERROR [STDERR] at sun.rmi.transport.StreamRemoteCall.executeCal
l(StreamRemoteCall.java:223)
11:44:08,686 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.j
ava:133)
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
kerProxy.invoke(JRMPInvokerProxy.java:135)
11:44:08,696 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invok
e(InvokerInterceptor.java:108)
11:44:08,696 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke
(TransactionInterceptor.java:77)
11:44:08,696 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(Se
curityInterceptor.java:80)
11:44:08,706 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionIntercept
or.invoke(StatelessSessionInterceptor.java:111)
11:44:08,706 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(Client
Container.java:76)
11:44:08,716 ERROR [STDERR] at $Proxy73.validateBank(Unknown Source)
11:44:08,716 ERROR [STDERR] at com.acs.lockbox.controller.EpayService.valida
teBank(EpayService.java:353)
11:44:08,716 ERROR [STDERR] at com.acs.lockbox.ejb.epay.EpayServiceEJB.valid
ateBank(EpayServiceEJB.java:117)
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
ativeMethodAccessorImpl.java:39)
11:44:08,726 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
ke(DelegatingMethodAccessorImpl.java:25)
11:44:08,736 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3
24)
11:44:08,736 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$Conta
inerInterceptor.invoke(StatelessSessionContainer.java:660)
11:44:08,746 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedCo
nnectionInterceptor.invoke(CachedConnectionInterceptor.java:186)
11:44:08,746 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.i
nvokeNext(AbstractTxInterceptor.java:107)
11:44:08,746 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptorBM
T.invokeNext(AbstractTxInterceptorBMT.java:144)
11:44:08,756 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorBMT.invoke
(TxInterceptorBMT.java:62)
11:44:08,756 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanc
eInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
11:44:08,766 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.inv
oke(SecurityInterceptor.java:130)
11:44:08,766 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(L
ogInterceptor.java:208)
11:44:08,766 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invok
e(StatelessSessionContainer.java:313)
11:44:08,776 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java
:738)
11:44:08,776 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MB
eanServerImpl.java:517)
11:44:08,786 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.
invoke(JRMPInvoker.java:383)
11:44:08,786 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor47.invoke(
Unknown Source)
11:44:08,786 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
ke(DelegatingMethodAccessorImpl.java:25)
11:44:08,796 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3
24)
11:44:08,796 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(Unic
astServerRef.java:261)
11:44:08,796 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.j
ava:148)
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
port.java:144)
11:44:08,816 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMess
ages(TCPTransport.java:460)
11:44:08,816 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$Connection
Handler.run(TCPTransport.java:701)
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


Thanks
Sanjay

[adrian.brock]

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?

Regards,
Adrian

[sbahal]

Adrian:
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.

Thanks
Sanjay

[adrian.brock]

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.

Regards,
Adrian

[sbahal]

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){

}