2 Replies Latest reply on Apr 21, 2004 12:56 PM by bie-developer

    JNDI, MBeans and JNP

    bie-developer

      We are having performance issues with JNDI lookups and JSP compilation. This is primarily a problem on Windows, testing on Linux has shown good enough performance.

      It can take up to 25 sec. to complete this lookup:
      10:59:24,328 DEBUG [org.jboss.mq.referenceable.SpyDestinationObjectFactory] SpyDestinationObjectFactory->getObjectInstance()

      This happens only when traffic on queues has been quiet for a while, or the queue was just created (server startup), which would indicate that there is some caching of results going on.

      JSPs: We should probably pre-compile and map them as servlets, but on Linux the compile times are acceptable. On Windows a page can take up to 60 seconds to load if it was not previously compiled, where on Linux (same hardware) the initial compile/load times are 5-7 seconds.

      Brian M.

        • 1. Re: JNDI, MBeans and JNP
          bie-developer

          Jboss is deleting its tmp cache on shutdown. (/server/default/tmp) The result is that every time the server is re-started, all the jsps need to be re-compiled. Again, not such a big problem on Linux, but for some reason this is taking more than 60 seconds per page on Windows. (As much as I'd love to stop supporting Windows as a server environment...)

          I'm not sure how they are related, but some MBean calls which are supposed to be happening locally (within the JVM, not using the RMIAdapter) take a long time (5-20s) to complete. The MBean calls are to security manager methods to apply security policies on JMS queues dynamically. On linux these calls take 1-2ms at the most.

          • 2. Re: JNDI, MBeans and JNP
            bie-developer

            This now looks like a Window task switching problem. If we run our application as a Windows service (our installer for windows creates a service wrapper) or run it using Ant (as a forked process), we see the JVM getting suspended unpredictably. This usually happens during MBean calls. In both cases, JBoss is running as a fork off the main process (either the Java service wrapper or Ant). If we start up JBoss from the command line (using a batch file) everything runs full speed, and is actually very fast. I suspect that windows gives lower priority to sub tasks in it's task switching code, but that's extremely crappy behavior. It's probably not that simple either, and I doubt any information on kernel level behavior is availble from Microsoft..
            This does not seem to be configurable either. Is anyone else running Jboss as a service or forked from an Ant task? I'd like to be able to confirm that this is the problem, so far it has been pretty consistent. Also, this was not a problem before we added JBoss to the application, but we have also re-written a significant portion of our application to integrate it into JBoss and utilize it's services.