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.
--
[Message sent by forum member 'netmackan']
View Post: http://forums.java.net/node/897798