Is startup directory added to GS classpath somehow?

We've noticed strange behaviour with GS not starting depending on which files are present in directory it is launched from.

We have a startup script on each server which sets absolute paths for work/deploy/logs/gs home, sets java options etc and then launches gs-agent.sh. If this script is invoked from its directory containing just it and few other shell scripts GS work fine. When we use ssh to invoke it from one host to launch multiple agents on all farm then it fails with exception:

2014-09-30 15:03:24,206  SEVERE [com.gigaspaces.start] - Error while booting system - ; Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at org.jini.rio.boot.RioServiceDescriptor.create(RioServiceDescriptor.java:329)
    at com.gigaspaces.start.SystemBoot.main(SystemBoot.java:384)
Caused by: java.lang.ClassNotFoundException: org.openspaces.security.spring.SpringSecurityManager
    at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.jini.rio.boot.ServiceClassLoader.loadClass(ServiceClassLoader.java:199)
    at org.jini.rio.boot.ServiceClassLoader.loadClass(ServiceClassLoader.java:182)
    at com.gigaspaces.security.SecurityFactory.createSecurityManager(SecurityFactory.java:60)
    at com.gigaspaces.security.service.SecurityInterceptor.<init>(SecurityInterceptor.java:160)
    at com.gigaspaces.security.service.SecurityInterceptor.<init>(SecurityInterceptor.java:92)
    at com.gigaspaces.grid.gsa.GSAImpl.initialize(GSAImpl.java:200)
    at org.jini.rio.jsb.ServiceBeanAdapter.doStart(ServiceBeanAdapter.java:368)
    at org.jini.rio.jsb.ServiceBeanAdapter$1.run(ServiceBeanAdapter.java:297)
    at org.jini.rio.jsb.ServiceBeanAdapter.start(ServiceBeanAdapter.java:310)
    at com.gigaspaces.grid.gsa.GSAImpl.bootstrap(GSAImpl.java:178)
    at com.gigaspaces.grid.gsa.GSAImpl.<init>(GSAImpl.java:145)
    ... 6 more

By experimenting we figured out that the cause of failure is presence of jar files and classes in home directory of account used to run GS. When we invoke startup commands using ssh, they are obviously invoked from home directory and that makes GS dependent to its contents.

I'm sure we don't explicitly add current directory to classpath or system path ourselves.

I've tried diffing info logs and verbose output of agent startup between runs and there are no differences except for timestamps till it fails. List of jars loaded by agent looks perfectly reasonable.

That could be a problem for us if GS would load classes from unknown locations. That could be a security breach for agent.

Has anyone experienced problems like that and which workaround did you apply? Enforced an empty startup directory to avoid conflicts?

asked 2014-10-02 04:58:01 -0500

aliher1911 gravatar image
edit retag flag offensive close merge delete

Comments

Hi,

What user are you using when run it locally and it works? Are you using the same user when using ssh?

Yuval gravatar imageYuval ( 2014-10-02 07:43:26 -0500 )edit

Also are you using some distribution tool for doing it in parallel? What user this tool use? Is it work for you if you just do ssh from one host to another and login with the correct user?

Yuval gravatar imageYuval ( 2014-10-02 08:33:19 -0500 )edit

The ssh execution bit was just a trigger for this behaviour, I was just giving a context for when we observe it and why we don't always change to the $JSHOMEDIR/bin to launch. GSA just fails if we have jars/classes in current work directory when we launch it either interactively or by using ssh.

aliher1911 gravatar imagealiher1911 ( 2014-10-02 12:58:51 -0500 )edit

Hi,

I have tried to reproduce your problem but it works for me. This is what I did: 1. navigate to ../lib/platform/commons directory (under this directory there are jars). [root@support-pc19 commons]# pwd /home/support/gigaspaces-xap-premium-10.1.0-m4/lib/platform/commons 2. start gs-agent.sh from this directory as follows: [root@support-pc19 commons]# ../../../bin/gs-agent.sh

Yuval gravatar imageYuval ( 2014-10-06 01:50:24 -0500 )edit

Hi, In case you still having a problem, p;lease open a support case via SalesForce portal and we will address this issue immediately Regards, Yuval

Yuval gravatar imageYuval ( 2014-10-12 04:07:23 -0500 )edit