Francois:
When you submit a job via GramJob in non-batch mode you register for
state change notifications of that job and a small GT container is
started behind the scenes that catches notifications sent by the server
belonging to your job.
Incoming notifications are then forwarded to GramJob.deliver() and
GramJob then calls stateChanged() of all registered GramJobListeners.
If you submit a job in batch-mode, no registration for state change
notifications of your job takes place and no container is started up
for you on the client-side to catch notification messages.
So you cannot submit jobs in batch mode and expect to get information
about the jobs states magically.
You must make sure to have a NotificationConsumerManager running which
is done transparently to you in GramJob.
You can also startup you own NotificationConsumerManager and register
another class/object for dealing with incoming notifications for your
GramJobs. Condor-G does it: Another instance than GramJob is responsible
for dealing with notifications of GramJobs and the jobs are sent to the
GT container in batch-mode.
WS-GRAM does the same when submitting transfer requests RFT.
Some information about:
* Chapter 13 of the book "Globus Toolkit 4: Programming Java Services"
or online
http://gdp.globus.org/gt4-tutorial/singlehtml/progtutorial_0.2.1.html#chap_core_notif
Hope this helps,
Martin
Hi,
I have a basic Java GRAM Client (code attached), based upon globusrun code.
When submitting a job in bacth mode (the submitting returns instantly,
and we get a "job handle" as return), we don't wait (as it returns
instantly).
In non batch mode, the call is blocking. There is this "stateChanged"
callback function that is called each time the status of the job changed
(and for example, we can delete the job when it's "done") and prints the
new status (try the code).
According to the author of the code, in batch mode, the callback
function is not called and so on... (we don't wait, we don't received
the state changes, etc..). So to be aware of the state of the job, we
must "pull" it, with the "job handle" given. But how to have a "push"
way, like in non-batch mode? I mean, can we submit 100 jobs in
batchmode, and a callback function called each time the state of a job
changes ?
My unexperience may make my ideas not clear, sorry for that. :-)
Here is the link of the IBM tutorial, and the code attached.
http://www.ibm.com/developerworks/grid/library/gr-wsgram/index.html
Best regards,
Francois.
On 8/2/07, * [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Francois,
i think i don't understand what you want to do.
Can you try to explain it a little more, please?
What should be done in batch mode and what exactly is
batch mode for you?
What exactly do you mean by "starting my batch mode"?
Martin
> Hi,
>
> I have a simple GRAM Client in Java. It implements the
GramJobListener
> interface, so that in interactive mode, with the callback function
> "stateChanged", i can cacth the changes in the state of the
GramJob, and
> destroy the job when it's "done".
>
> But i would like to do exactly the same in batch mode. I mean,
launching
> my
> batch mode, and getting the output/destroying the job when it's
"done".
> Can
> we use that "stateChanged" callback too? Is there another way to
do that?
>
>
> Cheers,
> Francois.
>
