This helps. Thank you very much. Best regards, Francois.
On 8/3/07, Martin Feller <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > > > > >
