[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] Multi-query for completed jobs



Hello

You can use the Condor perl module to do the option number 1.
You will submit your jobs using the perl module and an appropriate
callback in the perl module will be called upon completion of every job.
You can count jobs there and invoke different code when different jobs
complete.
Perl module does exactly what you have described in the option  number 1
- he checks the log file. That way you will not have to deal with
parsing and etc..

Of course, if you need this is C, you will have to wrap the perl calls
in C and from within perl callback invoke something that will
"signal/write to pipe/write something in rendezvous directory/another
option" your C program. Or  just do what ever you need to do upon first
job completion inside the perl callback.

Regards,

Gabriel Kliot
Technion - Israel Institute of Technology


> -----Original Message-----
> From: condor-users-bounces@xxxxxxxxxxx 
> [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Peter Troeger
> Sent: Friday, October 07, 2005 10:42 AM
> To: Condor-Users Mail List
> Subject: [Condor-users] Multi-query for completed jobs
> 
> 
> Hi,
> 
> I want to determine programatically (in C) if any job of a number of 
> jobs is completed / failed. I have a list of the job names, 
> as well as 
> according log files. Currently I see three possibilities for 
> doing this:
> 
> 1.) Go iteratively through all logfiles and search for the "Finish" 
> term. This might be optimized by checking the modification 
> time of the 
> files.
> 2.) Ask iteratively condor_history until it finds at least 
> one job to be 
> completed. It is possible to give multiple job ID's to 
> condor_history in 
> the query ("-constraint"), but with a large set of jobs I 
> might run into 
> a problem with the maximum length of a command line.
> 3.) Ask iteratively condor_q  and wait until at least one of 
> the jobs is 
> removed from the queue.
> 
> I experienced some bad performance with condor_history in Condor 
> 6.7.12., some maybe number 1 is the most appropriate solution ? Any 
> other ideas ?
> 
> Thank you,
> Peter Tröger.
> _______________________________________________
> Condor-users mailing list
> Condor-users@xxxxxxxxxxx 
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>