Hi, Thanks for the answers I received.
I see how the schema your mention would work, although I am not sure how I would implement it. I envision a web service that could receive a listener as a parameter and return some kind of id to retrieve it, or perhaps something based on the whole collections of jobs for a user, which would resemble your example more closely. I guess - I am not sure - that this would imply making the listener also serializable, and using a stateful web service instead of a plainly standard one, so it would have to live in the GT4 container. Is what I described you meant? As for GT2 vs GT4, I am a bit lost with the GramJob classes, I am reading mainly the javadoc at http://www.cogkit.org/release/4_1_4/api/jglobus/index.html and also some others I found in other sites like globus, but I am not really sure which are pre-WS (GT2) and which are WS (GT4). I put some further thought into the problem and I think I would run into some more problems with TaskGraphs (from Abstractions). I hoped I could do a kind of full monitoring of the status so that if a user submitted a TaskGraph I would be able to tell which task in the taskgraph was executing and the progress corresponding to that specific task, and present this to the user in the portal. Perhaps I trying to squeeze more out of it than I should? It would be nice to be able to submit complex (composed) tasks to the grid and provide that kind of granular monitoring, so I would be able to tell the user 'Your job has staged the input files, run, and is now staging the output files back to your directory, and this last step is complete at 65%'. By the way, thanks for letting me know I should not be using the gt2 fault tolerant provider, you saved me some time trying to reedit my experiments with it. Regards, Matt On Feb 12, 2008 4:10 PM, Mihael Hategan <[EMAIL PROTECTED]> wrote: > 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 > > > >
