3.0.4: JNDI recovery problem
hlship Apr 7, 2003 12:48 PMJBoss 3.0.4 on Windows XP
I'm attempting to write code to recover gracefully from app server outages.
I'm running a presentation layer in one JVM and JBoss 3.0.4 in another.
I want to be able to bounce JBoss and have my app continue operation.
My app catches NamingException and RemoteException. It then creates a new InitalContext().
What I'm seeing is that after restarting JBoss, I am unable to retrieve objects from JNDI.
The objects that fail are objects that previously were retrieved from JNDI. Here's the order of operations:
new InitalContext()
ic.lookup("vlib/Operations")
PortableRemoteObject.narrow()
... bounce JBoss 3.0.4 ...
catch RemoteException
new InitalContext()
ic.lookup("vlib/Operations")
... returns null, so retry ...
new InitalContext()
ic.lookup("vlib/Operations")
Still returns null, my app fails.
The JMX JNDIView bean (in the restarted JBoss) seems to give the correct results:
Global JNDI Namespace
+- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- RMIXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- UserTransactionSessionFactory (class: org.jboss.tm.usertx.server.UserTransactionSessionFactoryImpl)
+- topic (class: org.jnp.interfaces.NamingContext)
| +- testDurableTopic (class: org.jboss.mq.SpyTopic)
| +- testTopic (class: org.jboss.mq.SpyTopic)
| +- securedTopic (class: org.jboss.mq.SpyTopic)
+- queue (class: org.jnp.interfaces.NamingContext)
| +- A (class: org.jboss.mq.SpyQueue)
| +- testQueue (class: org.jboss.mq.SpyQueue)
| +- ex (class: org.jboss.mq.SpyQueue)
| +- DLQ (class: org.jboss.mq.SpyQueue)
| +- D (class: org.jboss.mq.SpyQueue)
| +- C (class: org.jboss.mq.SpyQueue)
| +- B (class: org.jboss.mq.SpyQueue)
+- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
+- RMIConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
+- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
+- ejb (class: org.jnp.interfaces.NamingContext)
| +- mgmt (class: org.jnp.interfaces.NamingContext)
| | +- MEJB (proxy: $Proxy15 implements interface javax.management.j2ee.ManagementHome,interface javax.ejb.Handle)
| +- jmx (class: org.jnp.interfaces.NamingContext)
| | +- ejb (class: org.jnp.interfaces.NamingContext)
| | | +- Adaptor (proxy: $Proxy19 implements interface org.jboss.jmx.adaptor.interfaces.AdaptorHome,interface javax.ejb.Handle)
+- invokers (class: org.jnp.interfaces.NamingContext)
| +- ALMIGHTYBEAST (class: org.jnp.interfaces.NamingContext)
| | +- pooled (class: org.jboss.invocation.pooled.interfaces.PooledInvokerProxy)
| | +- jrmp (class: org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy)
| | +- http (class: org.jboss.invocation.http.interfaces.HttpInvokerProxy)
+- jmx:ALMIGHTYBEAST:rmi (class: org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl)
+- vlib (class: org.jnp.interfaces.NamingContext)
| +- Book (proxy: $Proxy35 implements interface org.apache.tapestry.vlib.ejb.IBookHome,interface javax.ejb.Handle)
| +- Person (proxy: $Proxy34 implements interface org.apache.tapestry.vlib.ejb.IPersonHome,interface javax.ejb.Handle)
| +- BookQuery (proxy: $Proxy31 implements interface org.apache.tapestry.vlib.ejb.IBookQueryHome,interface javax.ejb.Handle)
| +- Publisher (proxy: $Proxy28 implements interface org.apache.tapestry.vlib.ejb.IPublisherHome,interface javax.ejb.Handle)
| +- Operations (proxy: $Proxy32 implements interface org.apache.tapestry.vlib.ejb.IOperationsHome,interface javax.ejb.Handle)
| +- KeyAllocator (proxy: $Proxy29 implements interface org.apache.tapestry.vlib.ejb.IKeyAllocatorHome,interface javax.ejb.Handle)
+- jmx (class: org.jnp.interfaces.NamingContext)
| +- rmi (class: org.jnp.interfaces.NamingContext)
| | +- RMIAdaptor (class: org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl)
+- UILXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
+- UILConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
vib/Operations is there and appears deployed.
My operating theory is that the InitialContext is not communicating well with the restarted JBoss instance.
Is this a known bug? Fixed in a later release? Is there any kind of logging I can enable to provide more information?