7 Replies Latest reply on Aug 2, 2005 12:30 AM by krblock

    Tutorial Example throws "Lookup of java:/comp/env/ failed"

    john_anderson_ii

      Actually, what's in the jboss-web.xml file might be more important in this instance. Here is an example of a working configuration:

      web.xml

       <ejb-ref >
       <description>[CDATA[The CMP Beans Facade]]</description>
       <ejb-ref-name>ejb/Facade</ejb-ref-name>
       <ejb-ref-type>Session</ejb-ref-type>
       <home>HugeFacadeHome</home>
       <remote>HugeFacade</remote>
       </ejb-ref>
      
      


      jboss-web.xml
       <ejb-ref>
       <ejb-ref-name>ejb/Facade</ejb-ref-name>
       <jndi-name>ejb/resume/Facade</jndi-name>
       </ejb-ref>
      


      Servlet.init() Method
       public void init() throws ServletException {
       try{
       Context context = new InitialContext();
       Object ref = context.lookup("java:/comp/env/ejb/Facade");
       home = (HugeFacadeHome) PortableRemoteObject.narrow(ref,
       HugeFacadeHome.class);
       }catch(NamingException e){
       throw new ServletException("init(): JNDI lookup of HugeFacade "+
       "failed. Message: " + e.getMessage());
       }
       }
      



      JBoss actually maintains the JNDI directory, so the entry in web.xml just maps to the entry in jboss-web.xml. I guess maybe other containers might implement JNDI differently. So the ejb-ref-name elements have to match up between the two while the jndi-name element of the jboss-web.xml file really sets the JNDI name of the object.

      I don't know why I have to lookup() an object with "java:/comp/env/ejb/Facade" when I set the JNDI name to "ejb/resume/Facade", but I do. I think it may be because the path given by the ejb-ref-name element is mapped to the actual path in JNDI maintained by JBoss. That way the code remains completely container independent so I could plug a websphere-web.xml file into it. Not entirely sure though.

        • 1. InstanceAlreadyExistsException: jboss.web:name=JkRequest
          kkoster

          Hi,

          I'm testing a web-application in JBoss4.0.0 with heavy load.
          JBoss is connected to Apache2 by mod_jk2.
          Sometimes I encounter a following Exception.

          2004-11-17 19:22:45,654 ERROR [org.apache.commons.modeler.Registry] Error registering jboss.web:name=JkRequest4,type=RequestProcessor,worker=jk-192.168.1.165-8009
          javax.management.InstanceAlreadyExistsException: jboss.web:name=JkRequest4,type=RequestProcessor,worker=jk-192.168.1.165-8009 already registered.
          at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:755)
          at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
          at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:324)
          at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
          at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
          at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:119)
          at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
          at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:131)
          at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
          at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:242)
          at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
          at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1397)
          at java.security.AccessController.doPrivileged(Native Method)
          at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1392)
          at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:359)
          at org.apache.commons.modeler.Registry.registerComponent(Registry.java:871)
          at org.apache.jk.common.ChannelSocket.registerRequest(ChannelSocket.java:436)
          at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:443)
          at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352)
          at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
          at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
          at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
          at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
          at java.lang.Thread.run(Thread.java:534)
          2004-11-17 19:22:45,661 WARN [org.apache.jk.common.ChannelSocket] Error registering request

          This is reproducible with a simple servlet which does nothing.


          After this exception, I found another error once.

          2004-12-02 20:53:24,563 ERROR [org.jboss.cache.TransactionTable] addLock(): transaction entry not found for (gtx=<192.168.1.164:32910>:7453)
          2004-12-02 20:53:24,563 ERROR [org.jboss.cache.TransactionTable] addLock(): transaction entry not found for (gtx=<192.168.1.164:32910>:7453)
          2004-12-02 20:53:24,565 ERROR [org.jboss.cache.TransactionTable] addUndoOperation(): transaction not found (gtx=<192.168.1.164:32910>:7453)
          2004-12-02 20:53:24,569 ERROR [org.jboss.cache.TransactionTable] addModification(): transaction not found (gtx=<192.168.1.164:32910>:7453)
          2004-12-02 20:53:24,573 ERROR [org.jboss.cache.TreeCache] rollback(): entry for transaction <192.168.1.164:32910>:7453 not found (transaction has possibly already been rolled back)
          2004-12-02 20:53:24,583 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheManager] processSessionRepl: failed with exception: org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=dl360g3ap1/26801, BranchQual=, localId=26801] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.IllegalStateException: cannot find transaction entry for <192.168.1.164:32910>:7453)
          2004-12-02 20:53:39,607 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          2004-12-02 20:53:54,618 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          2004-12-02 20:54:09,628 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          2004-12-02 20:54:09,633 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheManager] processSessionRepl: failed with exception: java.lang.RuntimeException: JBossCacheService: exception occurred in cache put after retry ...
          2004-12-02 20:54:24,659 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          2004-12-02 20:54:39,670 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          2004-12-02 20:54:54,681 ERROR [org.jboss.cache.lock.IdentityLock] lock could not be acquired after 15000 ms. Lock map ownership Read lock owners: []
          Write lock owner: <192.168.1.164:32910>:7453

          My app does HttpSessionReplication and doesn't use TreeCache for other feature.
          This error is found only once, not reproducible.
          I cannot judge this error is derived from InstanceAlreadyExistsException.


          What I want to know is

          What causes this InstanceAlreadyExistsException?
          Is this InstanceAlreadyExistsException negligible for application's performance and correct behavior?

          • 2. Re: Tutorial Example throws
            zhgs

            I have encountered the same problem.
            My environment is win2k + eclipse 3.1 + JBoss IDE 1.4.1 + JDK1.4.2
            + JBoss 4.0.2
            But the application works under JBoss 3.2.7.
            Can anyone give an answer?

            • 3. Re: Tutorial Example throws
              zhgs

              Following is the error message:
              21:48:58,906 INFO [STDOUT] java.lang.ClassCastException
              21:48:58,906 INFO [STDOUT] at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
              21:48:58,921 INFO [STDOUT] at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
              21:48:58,921 INFO [STDOUT] at tutorial.web.ComputeServlet.init(ComputeServlet.java:54)
              21:48:58,921 INFO [STDOUT] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091)
              21:48:58,921 INFO [STDOUT] at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:750)
              21:48:58,921 INFO [STDOUT] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
              21:48:58,937 INFO [STDOUT] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
              21:48:58,937 INFO [STDOUT] at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
              21:48:58,937 INFO [STDOUT] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
              21:48:58,937 INFO [STDOUT] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
              21:48:58,937 INFO [STDOUT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
              21:48:58,937 INFO [STDOUT] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
              21:48:58,937 INFO [STDOUT] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
              21:48:58,953 INFO [STDOUT] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
              21:48:58,953 INFO [STDOUT] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
              21:48:58,953 INFO [STDOUT] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
              21:48:58,953 INFO [STDOUT] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
              21:48:58,968 INFO [STDOUT] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
              21:48:58,968 INFO [STDOUT] at java.lang.Thread.run(Thread.java:534)

              • 4. Re: Tutorial Example throws

                guys,

                Good news & bad news...:))

                I was faced with the same problem. I tried for two days (one overnighter too), without much luck. The error message here is very deceptive (due to the actual exception being wrapped around by the ServletException). The actual cause is that the PortableRemoteObject.narrow() throws a "ClassCastException". Which is wrapped around by a ServletException("lookup failed") in the servlet code.

                After many hours of google searches landed on the below which was of much help from the jboss-devel mailing list.
                http://www.mail-archive.com/jboss-development@lists.sourceforge.net/msg29292.html

                I have confirmed that the problem only exists with the jboss-4.0.2 (jdk1.4.2_08/jdk1.5.0_03 & winxp_sp2). However, the problem does not exist with jboss-4.0.1 & 4.0.1sp1. I have successfully reproduced this on my home computer as well as the work computer. I believe this is a bug in 4.0.2.

                rgds,
                -kcs

                • 5. Re: Tutorial Example throws

                  guys,

                  Upon further investigation, this doesn't seem to be a bug. This is apparently related to the change in the classloader for the jboss-4.0.2, which is using servelet spec classloading (as opposed to jboss-4.0.1sp1 which uses a flat class loader) according to Adrian. refer to: http://jira.jboss.com/jira/browse/JBAS-1775.

                  rgds,
                  -kcs

                  • 6. Re: Tutorial Example throws
                    krblock

                    I understand I can work around this, however, following the instructions in the JBoss IDE 1.4 Tutorial led me to this problem. The Tutorial encouraged the duplication of objects in the packaging. Since this is not permitted anymore, what is the recommended packaging approach?

                    Eliminating the EJB-client.jar from the Web.war works for the example in the tutorial.

                    • 7. Re: Tutorial Example throws
                      krblock

                      The following thread gives another suggestion on how to work around this.

                      http://www.jboss.org/index.html?module=bb&op=viewtopic&t=59192