2 Replies Latest reply on Jun 5, 2003 1:37 PM by gturner

    Linux VM on fast SMP hardware triggers JBossMQ bug? (Connect

    gturner

      I have an application (ear) that has been kicking around for a year now, been in production for 3 months. Runs on JBoss 3.0.7.

      I recently bought a *real* development workstation - dual Xeon P4 2.4Ghz, SCSI disks, the works... deployment of the ear fails on this hardware!

      The stacktrace below has a peculiar class, AuditInteceptor, which I've added to the interceptor chain, and all it does during Container.start() is connect to a Topic which has been deployed in a separate service.xml file.

      2003-06-05 09:04:37,630 395023 WARN [org.jboss.system.ServiceController] (main:jboss.j2ee:service=EjbModule,url=file%/usr/local/java/jboss-3.0.7_jakarta-tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/phoenix.ear/26.phoenix.ear-contents/phoenix-ejb.jar file:/usr/local/java/jboss-3.0.7_jakarta-tomcat-4.1.24/server/default/tmp/deploy/server/default/deploy/phoenix.ear/26.phoenix.ear-contents/phoenix-ejb.jar jboss.j2ee:jndiName=phoenix/entity/Catalog,service=EJB) Problem starting service jboss.j2ee:jndiName=phoenix/entity/Catalog,service=EJB
      org.jboss.mq.SpyJMSException: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection timed out)
      at org.jboss.mq.Connection.authenticate(Connection.java:876)
      at org.jboss.mq.Connection.(Connection.java:232)
      at org.jboss.mq.Connection.(Connection.java:310)
      at org.jboss.mq.SpyConnection.(SpyConnection.java:59)
      at org.jboss.mq.SpyConnectionFactory.createTopicConnection(SpyConnectionFactory.java:78)
      at com.newedgenetworks.phoenix.ejb.jboss.AuditInterceptor.start(AuditInterceptor.java:230)
      at org.jboss.ejb.EntityContainer.start(EntityContainer.java:385)
      at org.jboss.ejb.Container.invoke(Container.java:782)
      at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003)
      at $Proxy4.start(Unknown Source)
      at org.jboss.system.ServiceController.start(ServiceController.java:413)
      at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
      at $Proxy20.start(Unknown Source)
      at org.jboss.ejb.EjbModule.startService(EjbModule.java:404)
      at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165)
      at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003)
      at $Proxy4.start(Unknown Source)
      at org.jboss.system.ServiceController.start(ServiceController.java:413)
      at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
      at $Proxy10.start(Unknown Source)
      at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:395)
      at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814)
      at org.jboss.deployment.MainDeployer.start(MainDeployer.java:806)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591)
      at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
      at $Proxy3.deploy(Unknown Source)
      at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:435)
      at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentScanner.java:656)
      at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
      at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:266)
      at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165)
      at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003)
      at $Proxy0.start(Unknown Source)
      at org.jboss.system.ServiceController.start(ServiceController.java:413)
      at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
      at $Proxy2.start(Unknown Source)
      at org.jboss.deployment.SARDeployer.start(SARDeployer.java:232)
      at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591)
      at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:324)
      at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
      at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324)
      at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221)
      at org.jboss.Main.boot(Main.java:148)
      at org.jboss.Main$1.run(Main.java:381)
      at java.lang.Thread.run(Thread.java:536)
      Caused by: java.net.ConnectException: Connection timed out
      at java.net.PlainSocketImpl.socketConnect(Native Method)
      at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
      at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
      at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
      at java.net.Socket.connect(Socket.java:426)
      at java.net.Socket.connect(Socket.java:376)
      at java.net.Socket.(Socket.java:291)
      at java.net.Socket.(Socket.java:147)
      at javax.net.DefaultSocketFactory.createSocket(DashoA6275)
      at org.jboss.mq.il.oil.OILServerIL.createConnection(OILServerIL.java:563)
      at org.jboss.mq.il.oil.OILServerIL.checkConnection(OILServerIL.java:507)
      at org.jboss.mq.il.oil.OILServerIL.authenticate(OILServerIL.java:289)
      at org.jboss.mq.Connection.authenticate(Connection.java:869)
      ... 84 more


      These exception are poping out very slowly, one per entity bean, two minutes apart.

      Production, QA, and other servers have been running JBoss on 2 or even 4 Sparc cpus on Solaris 8, though they're much slower than the 2 Xeons.

        • 1. Re: Linux VM on fast SMP hardware triggers JBossMQ bug? (Con
          gturner

          Found an interesting commit log message from over a year ago...


          >From: Brian Weaver <weave at users.sourceforge.net>
          >To: jboss-development at lists.sourceforge.net
          >Subject: [JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil
          >OILClientIL.java OILClientILService.java OILServerIL.java
          >OILServerILFactory.java OILServerILService.java
          >Date: Thu, 10 Jan 2002 05:38:18 -0800
          >
          > User: weave
          > Date: 02/01/10 05:38:17
          >
          > Modified: src/main/org/jboss/mq/il/oil OILClientIL.java
          > OILClientILService.java OILServerIL.java
          > OILServerILFactory.java OILServerILService.java
          > Log:
          > Changed the constants in the file to be all upper case words, without
          > having the 'm_' prepended to each constant.
          >
          > Added some fixes to make the code behave better under linux, which has
          > problems with non-preemptable I/O. See the java bug database and search
          > on 'J2SE_PREEMPTCLOSE' for more information on the linux problem.
          >
          > Synchronized the close() method of the OILClientIL.java file to prevent
          > concurrent access in the checkSocket() method which was not
          > synchronized.
          >
          > Also, changed many of the 'protected' and 'package' level variables and
          > method to private. This allows JIT compilers to 'trivially' optimize
          > those sections of code since access is at most restrictive levels. This
          > did not cause any compile or runtime issues with the testsuite since
          > none of the members were referenced from other classes.
          >
          > Finally, marked some of the classes final to allow JIT compilers
          >additional
          > hints for optimizations. Since the classes are not extended in JBoss
          > this does not appear to be a problem [I could be wrong, it wouldn't be
          > the first time! If so then I'm sure someone will joyfully revert my
          > changes and inform me of my erronous assumptions. Cheers!]

          • 2. Re: Linux VM on fast SMP hardware triggers OIL bug
            gturner

            I switched from using the OIL invocation layer to using the JVM invocation layer and the applications deploys normally again.