Technical FAQ

1. I've now registered and downloaded the software. What do I need to do in order to get up and running?


2. When a file is transferred from a GRIA client to a data stager (or the other way round): is the file transfer secured or does the file need to be encrypted?


3. Why do we have to provide aliases for files in GRIA commands (e.g. gridcli upload MyAlloc image.jpg MyImage) instead of directly passing the file name?


4. In the application wrapper script, it seems that the passed parameters are something like: -i ../stagedzips/input0.zip -o ../stagedzips/output0.zip. Is there any way to get the original file names that have been passed by the client?


5. Why do I get an "java.security.cert.CertPathValidatorException: timestamp check failed" error when trying to access griademo.it-innovation.soton.ac.uk?

I've now registered and downloaded the software. What do I need to do in order to get up and running?

Installation instructions are provided with the download, you may also find the Getting Started page useful.

When a file is transferred from a GRIA client to a data stager (or the other way round): is the file transfer secured or does the file need to be encrypted?

Normally, all transfers are over https, and so are encrypted. However, if the service provider is not using Apache (the endpoint starts http: instead of https:) then the communication isn't encrypted.

Messages are signed (to prevent tampering) whether encryption is used or not.

Why do we have to provide aliases for files in GRIA commands (e.g. gridcli upload MyAlloc image.jpg MyImage) instead of directly passing the file name?

It used to work like that, but people complained that it was too confusing.

In the application wrapper script, it seems that the passed parameters are something like: -i ../stagedzips/input0.zip -o ../stagedzips/output0.zip. Is there any way to get the orignal file names that have been passed by the client?

No, sorry. The conceptual model in GRIA is that the job service retrieves data from the data stagers and writes it into the job workspace. Then the application wrapper unpacks the input data into the job's working directory and starts the job. This model allows the job service to meter (and bill for) network bandwidth, which is obviously a good thing for the service provider as he can use pricing to manage the use of bandwidth, and hence the quality of service seen by the customer, even if he decides not to bill for the network usage!

The data stager itself doesn't have a filename - the conceptual model is that data stagers are equivalent to data on the network! When a file is being transferred over the network, it doesn't have a name when it is actually on the network - it just has some identifiers allowing it to be distinguished from other network traffic. The name you give to a data stager is just a local label allowing you to distinguish it from other stagers and refer back to the same stager later. That name is not converted into a file name or otherwise attached to the data itself.

In fact, all files have the same name while stored in a data staging service - you never see that name because it is local to the data staging service. Right now our data staging service doesn't support streaming, but if we added that you would immediately see that a filename makes no sense, as you would then just pass in the URI and get back a stream without a file name! Hopefully, this makes it clearer why file names are not attached to the data that is being staged.

What this means is that the job service chooses the names for staged data going into or out of the job workspace. The application wrapper has to pick up inputs and store outputs using those names, but of course when it moves them into an execution directory it can use any name it likes, or extract the names from the input or the Work.xml, etc.

Why do I get an "java.security.cert.CertPathValidatorException: timestamp check failed" error when trying to access griademo.it-innovation.soton.ac.uk?

You are attempting to access the old griademo machine. This has been replaced by a new system griademo1.it-innovation.soton.ac.uk, which you can use by generating a keystore following the process described on the getting started page.