Bug 4859 - globusrun-ws staging error after gt4 deployed to tomcat
: globusrun-ws staging error after gt4 deployed to tomcat
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: unspecified
: PC Linux
: P2 normal
: 4.2.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-11-14 05:24 by
Modified: 2008-04-07 14:08 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-11-14 05:24:09
Hello,
I could run 
"globusrun-ws -F aka15.galab.uwindsor.ca:8443 -submit -S -f testjob.xml"
sucessfully through submitting the job to globus container. However, after I
deployed gt4 to tomcat using deploySecureTomcat on host
aka15.galab.uwindsor.ca, the same command gives me a staging error:

 globusrun-ws  -F aka15.galab.uwindsor.ca:8443 -submit -S -f testjob.xml 
 Delegating user credentials...Done.
 Submitting job...Done.
 Job ID: uuid:74ed75e0-73ce-11db-88d6-00034788e658
 Termination time: 11/15/2006 10:54 GMT
 Current job state: StageIn
 Current job state: Failed
 Destroying job...Done.
 Cleaning up any delegated credentials...Done.
 globusrun-ws: Job failed: Staging error for RSL element fileStageIn.
 Unable to set staging factory service endpoint with address null

The Tomcat log shows the following error:

  ...
 INFO: Authorized
"/O=Grid/OU=GlobusTest/OU=simpleCA-aka15.galab.uwindsor.ca/OU=galab.uwindsor.ca/CN=Lichun
Zhu" to invoke
"{http://www.globus.org/namespaces/2004/10/gram/job}createManagedJob".
 Nov 14, 2006 5:54:11 AM org.globus.exec.service.exec.StateMachine
logJobAcceptedINFO: Job 74ed75e0-73ce-11db-88d6-00034788e658 accepted for local
user 'zlc'
 Nov 14, 2006 5:54:11 AM org.globus.exec.service.exec.StateMachine fileCleanUp
SEVERE: A secondary fault occured while trying to gracefully fail.
java.lang.RuntimeException: Unable to set staging factory service endpoint with
address null
        at
org.globus.exec.service.exec.ManagedExecutableJobResource.getReliableFileTransferFactoryEndpoint(ManagedExecutableJobResource.java:1609)
        at
org.globus.exec.service.exec.utils.StagingHelper.submitStagingRequest(StagingHelper.java:146)
        at
org.globus.exec.service.exec.StateMachine.fileCleanUp(StateMachine.java:2759)
        at
org.globus.exec.service.exec.StateMachine.processFailureFileCleanUpState(StateMachine.java:2150)
        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:585)
        at
org.globus.exec.service.exec.StateMachine.processState(StateMachine.java:367)
        at org.globus.exec.service.exec.RunThread.run(RunThread.java:93)
Caused by: java.net.MalformedURLException: unknown protocol: local
        at java.net.URL.<init>(URL.java:395)
        at java.net.URL.<init>(URL.java:283)
        at
org.globus.exec.service.exec.ManagedExecutableJobResource.getReliableFileTransferFactoryEndpoint(ManagedExecutableJobResource.java:1594)
        ... 9 more
 Nov 14, 2006 5:54:12 AM org.globus.exec.service.exec.StateMachine logJobFailed
INFO: Job 74ed75e0-73ce-11db-88d6-00034788e658 failed
 Nov 14, 2006 5:54:12 AM
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain authorize
  ...

It prompts "java.lang.RuntimeException: Unable to set staging factory service
endpoint with address null" at
org.globus.exec.service.exec.ManagedExecutableJobResource.getReliableFileTransfe
and "java.net.MalformedURLException: unknown protocol: local" error at
org.globus.exec.service.exec.ManagedExecutableJobResource.getReliableFileTransferFactoryEndpoint(ManagedExecutableJobResource.java:1594).

My environment is:
OS: Fedora Core 5
Globus: 4.0.2
Tomcat: 5.0.28
JDK: 1.5.07

testjob.xml: 
  <?xml version="1.0" encoding="UTF-8"?>
  <job>
    <executable>/usr/local/java/bin/java</executable>
    <directory>${GLOBUS_USER_HOME}</directory>
    <argument>Hello</argument>
    <stdout>${GLOBUS_USER_HOME}/stdout</stdout>
    <stderr>${GLOBUS_USER_HOME}/stderr</stderr>
    <fileStageIn>
        <transfer>          
<sourceUrl>gsiftp://aka15.galab.uwindsor.ca:2811/home/zlc/test/Hello.class</sourceUrl>
<destinationUrl>file:///${GLOBUS_USER_HOME}/Hello.class</destinationUrl>
        </transfer>
    </fileStageIn>
    <fileStageOut>
        <transfer>
<sourceUrl>file:///${GLOBUS_USER_HOME}/stdout</sourceUrl>
<destinationUrl>gsiftp://aka15.galab.uwindsor.ca:2811/tmp/stdout</destinationUrl>
        </transfer>
    </fileStageOut>
    <fileCleanUp>
        <deletion>
            <file>file:///${GLOBUS_USER_HOME}/Hello.class</file>
        </deletion>
        <deletion>
            <file>file:///${GLOBUS_USER_HOME}/stdout</file>
        </deletion>
    </fileCleanUp>
  </job>


Any help will be appreciated.

Thank you very much.
------- Comment #1 From 2006-11-14 20:47:06 -------
Please follow the steps described in section 4.2.1 in
http://www.globus.org/toolkit/docs/4.0/common/javawscore/admin-index.html#javawscore-admin-tomcat-deploying
------- Comment #2 From 2007-10-05 21:19:46 -------
Pointing the CLASSPATH environment to axis-url.jar as described
in section 4.2.1 on the webpage Jarek mentions doesn't work for me
(for software versions see below).

I can see two reasons

1. $CATALINA_HOME/common/lib/ does not contain axis-url.jar after
   deploying GT into it. I found it in 
   $CATALINA_HOME/webapps/wsrf/WEB-INF/lib/ instead. 

2. After pointing CLASSPATH to axis-url.jar in the right location it
   still didn't work for me because the CLASSPATH gets overwritten
   during the startup of tomcat.
   In the Tomcat versions i used (see below) $CATALINA_HOME/bin/startup.sh
   calls $CATALINA_HOME/bin/catalina.sh which sources
   $CATALINA_HOME/bin/setclasspath.sh. And here the CLASSPATH gets
   overwritten.

A solution could be modifying setclasspath.sh by adding the existing
CLASSPATH instead of overwriting it or by just adding
$CATALINA_HOME/webapps/wsrf/WEB-INF/lib/axis-url.jar to it.


Versions:
Tomcat: 5.0.28, 5.5.25
GT (java ws core, ws-gram): 4.0 branch
------- Comment #3 From 2008-04-02 09:37:37 -------
Investigating this issue turned up another issue.  In the AxisServlet, we force
the factory finder to use our
org.globus.axis.configuration.EngineConfigurationFactoryServlet instead of the
default.  In order to do this, we called
EngineConfigurationFactoryServlet.class to force the classloader to load the
class.  Then we update the configuration.  This worked in jvm 1.4, but not in
jvm 1.5.  I have replaced this with the more cannonical
Class.forName("org.globus.axis.configuration.EngineConfigurationFactoryServlet");
and this works for both jvms.  This eliminates the cannot find service error
thrown by the tomcat
------- Comment #4 From 2008-04-04 10:26:51 -------
Ok, in order for this to work, axis-url.jar needs to be on the startup
classpath, which is implied in the documentation.  However, the tomcat
initialization files call the setclasspath.sh (or .bat) file which overwrites
the user-set classpath.  I'm adding a flag to tomcat.xml.  The
-Dlocal.invocations=true flag when passed to the tomcat deploy task, will
concat a line to the setclasspath.* files that adds axis-url.jar to the
classpath.  This should allow local invocations to be successful.  The previous
setclasspath files are copied to setclasspath.*.bak