On Jun 26, 2008, at 12:45 PM, Steven Timm wrote:
1) using the globusrun-ws -submit -batch and globusrun-ws -monitor
combination both with the -subject option, it completes without
errors.
The same combination, but requiring streaming as well,
we get this error:
[...]
globusrun-ws: Job failed: Staging error for RSL element fileCleanUp.
----------------------------
Any idea what might be causing the above error? Note
that we *do* get the standard output back somehow despite the error.
This sounds like Florian Lengyel's problem. What IP shows up in $GL/
etc/globus_wsrf_gram/globus_gram_fs_map_config.xml ? That controls
the GridFTP server used for cleanup operations.
--------------------------------------------------------
I note that there's the following error in container-real.log:
2008-06-26 12:28:26,294 ERROR impl.QueryAggregatorSource
[Timer-8,pollGetMultiple:149] Exception Getting Multiple Resource
Properties from https://131.225.166.2:9443/wsrf/services/ReliableFileTransferFactoryService
: java.rmi.RemoteException: Failed to serialize resource property
org
.globus
.transfer
[EMAIL PROTECTED];
nested exception is:
org.apache.commons.dbcp.DbcpException: java.sql.SQLException:
null, message from server: "Host 'fnpcosg1.fnal.gov' is not allowed
to connect to this MySQL server".
Is this rft-related?
Yes, that would be the database server setup in $GL/etc/
globus_wsrf_rft/jndi-config.xml
2) Above you say that the globusrun-ws client will be modified in
globus 4.2 to expect the hostname to which it sent the
query originally... is this part of a bigger change in 4.2 about
the way that globus deals with hostnames? Is there any chance
it can be back-ported into the 4.0.x branch--or anything that
would break if it happened?
Don't know, this was the first I learned about it when I was talking
to a GRAM developer about your problem.
Is there any way that globus could move to a model similar
to that which Condor already uses, namely to allow a server to bind
to a particular IP only and use that IP for all communication
inbound and outbound? Since it's likely that the 4.0.x set of
clients will be with us for a while, it would be good to come
up with a solution that's more generic than requiring a client update.
Right. Don't know.
3) you agreed with me that moving my service ip to an alternate
network interface such as eth2 might help, but even so, it would
only help if that interface were the default route to the rest
of the world, wouldn't it?
[...]
If so, then it implies that for the moment, the globus container
must for consistency be run with a GLOBUS_HOSTNAME that matches the
default IP by which you talk to the rest of the world. Is this
correct?
Also don't know, it's been a while since I've done any real network
work. Your argument sounds reasonable, but if it were me, I'd just go
experimentally verify one way or the other.
Charles
