Skip to main content

EJB call takes 5-10 seconds on GlassFish 3, ~1 sec on GlassFish 2

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
20 replies [Last post]
netmackan
Offline
Joined: 2005-06-26

I am trying to understand why our standalone application making an EJB call takes about 5-10 seconds longer to start when running agains GlassFish 3.1 compared to GlassFish 2. See below.
Anyone having an idea about what the problem could be?
Could it be the error about the findDerbyClient or javadb client jar file that is the problem?

GlassFish 2:
$ time bin/signserver getstatus brief all
CP: /opt/glassfish3.1/glassfish/lib/gf-client.jar:./conf:./lib/SignServer-AdminCLI.jar:./res/cesecore::./conf/glassfish:/opt/glassfish3.1/glassfish/lib/appserv-rt.jar
Current version of server is : SignServer 3.5.0alpha0

real 0m1.743s
user 0m1.580s
sys 0m0.136s

GlassFish 3.1.2:
$ time bin/signserver getstatus brief all
CP: /opt/glassfish3.1/glassfish/lib/gf-client.jar:./conf:./lib/SignServer-AdminCLI.jar:./res/cesecore::./conf/glassfish:/opt/glassfish3.1/glassfish/lib/appserv-rt.jar
Jul 17, 2013 8:26:07 PM com.sun.enterprise.v3.server.CommonClassLoaderServiceImpl findDerbyClient
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
Current version of server is : SignServer 3.5.0alpha0

real 0m12.764s
user 0m13.237s
sys 0m0.396s

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
xcallejas
Offline
Joined: 2009-07-29

The method that are you calling is returning and object?

netmackan
Offline
Joined: 2005-06-26

Yes, the getStatus operation I was testing with returned an object.

However, switching to calling another session bean method with a void return time still gave a significant slow response.

heliofrota
Offline
Joined: 2004-05-25

Hi,

5 - 10 sec a method call ?
what the all config server hardware and software ?

Regards,
Helio

2013/7/26

> The method that are you calling is returning and object?
>
> --
>
> [Message sent by forum member 'xcallejas']
>
> View Post: http://forums.java.net/node/**897798
>
>
>

--
Helio Frota
JUG Leader - CEJUG
http://www.cejug.org/
http://www.linkedin.com/in/heliofrota

netmackan
Offline
Joined: 2005-06-26

Good question. My feeling was that it is only the first call (per start of the client application) that takes a long time.

I modified my application like this to printout what is taking time:

            startClock();
            System.out.println("Looking up WorkerSession");
            final IWorkerSession.IRemote workerSession = getWorkerSession();
            printTime();

            startClock();
            System.out.println("Calling reloadConfiguration 1");
            workerSession.reloadConfiguration(workerId);
            printTime();

            System.out.println("Calling reloadConfiguration 2");
            workerSession.reloadConfiguration(workerId);
            printTime();

Which produced the following output:

time bin/signserver reload all
CP: /opt/glassfish3.1/glassfish//lib/gf-client.jar:./conf:./lib/SignServer-AdminCLI.jar:./res/cesecore::./conf/glassfish:/opt/glassfish3.1/glassfish//lib/appserv-rt.jar

Looking up WorkerSession
Jul 27, 2013 7:39:50 PM com.sun.enterprise.v3.server.CommonClassLoaderServiceImpl findDerbyClient
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
2013-07-27 19:39:50,844 DEBUG [ServiceLocator] Glassfish JNDI name: org.signserver.ejb.interfaces.IWorkerSession$IRemote
Time for call: 4403

Calling reloadConfiguration 1
Time for call: 314

Calling reloadConfiguration 2
Time for call: 602

real 0m5.792s
user 0m8.553s
sys 0m0.440s

It is now quite obvious the problem is with the JNDI lookup.

guojun.shan
Offline
Joined: 2012-10-26

get reply from ejb designer: that is normal, not an issue.

netmackan
Offline
Joined: 2005-06-26

Hi Guojun Shan,

Are you saying that a lookup of an remote EJB now taking twice as much time as from GFv2 is not an issue?

Is this really normal?
For me it means that my command line interface will be very slow (for those that want to use GFv3 so probably most will use JBoss 7 instead)

Regards,
Markus

mvatkina
Offline
Joined: 2005-04-04

Hi Markus,

The v2 test referenced in your 1st post

GlassFish 2:
$ time bin/signserver getstatus brief all
CP: /opt/glassfish3.1/glassfish/lib/gf-client.jar:./conf:./lib/SignServer-AdminCLI.jar:./res/cesecore::./conf/glassfish:/opt/glassfish3.1/glassfish/lib/appserv-rt.jar

As you can see it has 3.1 and gf-client.jar which does not exist on v2.

And one more question: is security manager involved? If yes, can you test with and without security manager enabled?

-marina

netmackan
Offline
Joined: 2005-06-26

mvatkina wrote:
Hi Markus,
As you can see it has 3.1 and gf-client.jar which does not exist on v2.

And one more question: is security manager involved? If yes, can you test with and without security manager enabled?
-marina

Hi Marina,

Sorry the output stating that the glassfish3.1 path was used in the v2 test must be a copy-past error. I re-did the tests now and got the same results when specifying the correct paths.

Also note that GlassFish 2 is working fine but it is GlassFish v3.1 that is much slower.

No security managers are added in my code. To be sure I set up a new minimal application only doing the lookup and calling one EJB method and got the same results. All jars on the classpath was then gf-client.jar and appserv-rt.jar.

I also run the application in the NetBeans IDE profiler. The attached images shows that the time is spent in a large number of method invokations under org.glassfish.gmbal.typelib.

Could that give a clue about the problem or should I do some other tests?

Best regards,
Markus

netmackan
Offline
Joined: 2005-06-26

So the conclusion is perhaps that GlassFish >=3 is just slower on initial EJB lookups and maybe not se well suited for command line tools just starting up, making one EJB call and then terminates. Is that correct?

mvatkina
Offline
Joined: 2005-04-04

It was always slower on the initial lookup and we didn't notice much regression between 2.x and 3.x. But it might be a good idea to ping an EJB on startup to avoid delays later.

-marina

netmackan
Offline
Joined: 2005-06-26

The attached profiling images/snapshot seems to have fallen off from my post so I uploaded them here instead:
http://wwwpriv.primekey.se/~markus/glassfish3/

guojun.shan
Offline
Joined: 2012-10-26

sorry, actually I'm not the right person to answer it. I will let engineers in EJB container answer this question.

guojun.shan
Offline
Joined: 2012-10-26

i'm not sure whether my test case is simiar with yours.
when I debug it:
for a remote lookup like: ctx.lookup("java:global/app1/module1/ejbname").
actually there are two lookup invocation:
one for ctx.lookup("java:global/app1/module1/ejbname", it will return a Reference . then on client it will lookup the content of the reference: ctx.lookup("java:global/app1/module1/ejbname_...Internal_RemoteBusinessHome".
after second lookup return, there will be EJB intialization work like lookupRemote30BusinessObject() which involve some client side class generation and loading.
so the total time of lookup a remote EJB is a bit long.

it seems in current design of EJB container, it is very expensive to lookup a remote EJB for the first time.

netmackan
Offline
Joined: 2005-06-26

I am using the class name of the remote interface for lookup so not exactly the same as using the "java:global:". Could that be the issue?

My lookup code:

class ServiceLocator {
   // ...
   InitialContext initialContext = new InitialContext();

   public <T> T lookupRemote(final Class<T> remoteInterface) throws NamingException {;
      try {
           // Try using GlassFish JNDI
           beanInterface = (T) initialContext.lookup(
                   getGlassfishJNDIName(remoteInterface));
       } catch (NamingException ex) {
           try {
               // Then try using JBoss 7 JNDI
               beanInterface = (T) initialContext.lookup(getJBoss7JNDIName(remoteInterface));
           } catch (NamingException exx) {
               LOG.error("Error looking up signserver interface", exx);
               throw ex;
           }
       }
   }  
   private String getGlassfishJNDIName(final Class remoteInterface) {
      return remoteInterface.getName();
   }
   // ...
}

IWorkerSession.IRemote workerSession = ServiceLocator.getInstance().lookupRemote(IWorkerSession.IRemote.class);
mgainty
Offline
Joined: 2004-05-21

if you really want to lose the jndi lookup plumbing

refactor your EJB code to POJI annotated with @Remote

http://www.javaworld.com/javaworld/jw-08-2006/jw-0814-ejb.html?page=2

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

> To: users@glassfish.java.net
> Subject: Re: Re: EJB call takes 5-10 seconds on GlassFish 3, ~1 sec on ..
> From: forums@java.net
> Date: Mon, 29 Jul 2013 03:23:21 -0500
>
> i'm not sure whether my test case is simiar with yours. when I debug it: for
> a remote lookup like: ctx.lookup("java:global/app1/module1/ejbname").
> actually there are two lookup invocation: one for
> ctx.lookup("java:global/app1/module1/ejbname", it will return a Reference .
> then on client it will lookup the content of the reference:
> ctx.lookup("java:global/app1/module1/ejbname_...Internal_RemoteBusinessHome".
> after second lookup return, there will be EJB intialization work like
> lookupRemote30BusinessObject() which involve some client side class
> generation and loading. so the total time of lookup a remote EJB is a bit
> long. it seems in current design of EJB container, it is very expensive to
> lookup a remote EJB.
>
> --
>
> [Message sent by forum member 'guojun.shan']
>
> View Post: http://forums.java.net/node/897798
>
>

netmackan
Offline
Joined: 2005-06-26

Hi Martin Gainty,

Thanks for your suggestion. My problem is on the client side though. The client application looks up the Remote EJB and makes some EJB calls. I don't think it is possible to use @Remote EJB annotations on the client side right?

Best regards,
Markus

mvatkina
Offline
Joined: 2005-04-04

You can inject an EJB into a static field of the main class of an application client if you use an appclient container to run it.

-marina

guojun.shan
Offline
Joined: 2012-10-26

and it is much quicker to lookup the same remote EJB again in the same application.

netmackan
Offline
Joined: 2005-06-26

There must be a problem here somewhere. See our run times for our JUnit test suite:

GlassFish 3: 120 min
GlassFish 2: 30 min
JBoss 7: 30 min

heliofrota
Offline
Joined: 2004-05-25

INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.

this step is probably messing your test.

regards,
Helio