So I think your best bet is to have some background services in the portal that you attach or detach to a portal session. In other words, you can have the CoG objects alive even when a user logs out. So basically a session of your own that is only loosely connected to the portal session. This way you get the benefits of both worlds. For example:
-login happens register(username, statefulObject); -logout happens -stuff happens in the background -login happens statefulObject = retrieve(username) ... Some more specific answers inline. On Tue, 2008-02-12 at 14:38 -0200, Matias Alberto Gavinowich wrote: > Hi, > > I am writing to see if anyone can give me any pointers on monitoring > file transfer and job submission tasks on the Grid. What I would like > to do is to be able to present detailed information such as status of > the job (ideally even if sent to a PBS batch system) and progress > (e.g. in percentage) of a file transfer, even if the user logs out and > then back in into the portal (so registering a listener in the session > is not enough in my case). The monitoring that the batch job > submission portlet in OGCE provides is pretty much what I want for the > job case. > > Now the issue I am having with this: I am trying to apply the Java CoG > Kit abstractions. That is, I have studied the code for the batch job > submission portlet and I know it employs the GramJob class in the > (jGlobus?) part of the CoG API. I haven't tried to do this for file > transfers so I also don't know how it would be done in that case. > > Nevertheless, using the abstractions I was only able to register a > listener in the session, which constrained me mainly to synchronous or > almost synchronous executions. What I like about the abstractions is > their simplicity and implementation of object oriented concepts. If I > used e.g. the GramJob class, then as far as I know I need to build the > rsl. > > These are therefore the main items I am in doubt about: > > Is it possible to use the CoG Abstractions for the purpose I > described? Or at least is there a way to get the native job handle > from the abstractions and build a GramJob object just for the purpose > of monitoring the task, that is, combine both techniques? The only > handle I could get my hands on was a urn:cog handle that I didn't know > what to use for. The internals of the implementation are not much exposed by the abstractions API. So you'd probably have to use the implementation APIs directly. > > I am not sure the extent up to which GramJob works with GT4 (WS-based) > execution, It doesn't. But GT4 has a GramJob of its own. Though fairly different from the pre-ws gram one. > I have seen that a GramJobPreWS object is also used in the > portlet I studied, can I get this GramJob class to work with any > provider (at least any globus provider, namely gt2 and gt4)? > > How would this be done for file transfers? Same principles apply. > > I would greatly appreciate your comments on these topics. If there's a > way to combine approaches so as to get the advantages of using the > abstractions, that would be great. If anyone has further examples on > how to achieve such monitoring without the abstractions, that would > also be helpful. Even examples on monitoring using the abstractions > only in the same session - though I would really like to be able to > span sessions - would come in handy. > > I'd like to add I once tried to do this by using the gt2 fault > tolerant provider and trying to checkpoint and reconnect to tasks, but > I was never able to get this to work, even from the command line. Hmm. I just removed that one from SVN. Hasn't been maintained in a while and you're the only person I heard of to have tried to use it. Mihael > > Thank you a lot for your help, > > Matt >
