Re: [Condor-users] [birdbath] java as executable and UPDATE_INTERVAL

[Matthew Farrellee <matt@xxxxxxxxxxx>]

On Jun 13, 2006, at 5:47 PM, Afrasyab Bashir wrote:

> Hi,
>
> I've three questions (first is very specific to birdbath)
>
> 1) It is about the transfer of executable files. Jaime Frey's in  
> his reply to a query said about the grid protocols (email appended)  
> said that 'jvm' is needed to be mentioned in executables. However,  
> in one of my earlier emails to matt he replied that when using java  
> universe I need not worry about executable as long as
>
> a. The file can be transferred.

That is to say that the file you specify as the executable exists and  
can be transferred. It will not actually be used as the executable  
for the Java Universe.

OR

> b. I set TransferExecutable = false

If you set TransferExecutable=False you do not need to provide a file  
that exists as the executable, because it will never be transferred.


> It, on testing, proved to be right and the job was still executed.  
> The logic behind it was that
>
> a) class file was picked up from the IN condorclassAttr and
> b) location of jvm was picked up from the configure file
>
> Whereas, when I tried writing java in executable then condor  
> started transferring java.exe as executable and failed (and error  
> entries were recorded in the shadow log). I'm using condor's window  
> version.
>
> Keeping above in mind,
>
> QUESTION 1:
>
> If we write java as executable for grid universe types then would  
> the condor again try to transfer java.exe to grid? [This question  
> is in the appended email but may be tortuously presented]

From what  Jamie said in the appended message it sounds like you  
need to specify your JVM as the executable for Grid Universe jobs and  
the JVM will be transferred.

Also, the base64 encoding is only done in submission through  
birdbath. Condor uses its own binary protocol between its components,  
a protocol that does not have the same size increase as base64 encoding.

Someone else will have to answer the other questions in this email...


> 2) Rest of the two questions relate to the update interval which is  
> set to 5 minutes by default. It leads me to presume that the  
> information that I collect from the collector or any other daemon  
> could be 5 minutes old (keeping in view the complete response  
> time). Therefore following is not clear to me.
>
> QUESTION 2.
>
> Is it possible that even when there is a drastic change in machine  
> information but the collector is not updated because it still is  
> not the time to update (i.e. for e.g. a drastic change in machine's  
> load occurred at 3rd minute whereas update interval was set to 5  
> minutes)?
>
> QUESTION 3.
>
> I know it now that birdbath doesn't support updating the values of  
> macros dynamically. What I don't know is if birdbath supports  
> collecting the current value of the macros or not? If yes, then how  
> to collect the current value of update_interval?
>
> I would highly appreciate your response, please.
>
> thanks
>
> Kind Regards
> Afras
>
>
> ----- Original Message -----
> From: Afrasyab Bashir
> To: Condor-Users Mail List
> Sent: Saturday, June 10, 2006 10:59 AM
> Subject: Re: [Condor-users] Condor, Windows, Globus, Java
>
>
> [Jaime Frey]
>
> > Most of the grid protocols have no special support for java.  
> You'd have to specify the jvm as your executable. Condor-C is a  
> notable exception.
>
>
>
> My understanding is
>
> a) When we mention path to Java.exe in condor configure file then  
> its the universe = java which is most important and that is why we  
> don't mention java in executable. [Condor picks up java.exe from  
> the path mentioned on the executing machine]
>
> b) Executable file/s is/are transferred to the executing machine.
>
> So when you say that 'You'd have to specify jvm as your  
> executable'  [in case of grid universe] do you mean
>
> a) java.exe (and files that it depends upon, if any) will be  
> transferred to the executing machine ?
> b) I read somewhere that when condor is transferring files it uses  
> its base64(?) coding that increases the sizes of file to 33%. If  
> that's true then my question is does that hold true for the  
> executable files as well or not?
>
> Could you put me right please.
>
> Thanks
> Afras
> _______________________________________________
> Condor-users mailing list
> To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx  
> with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/condor-users
>
> The archives can be found at either
> https://lists.cs.wisc.edu/archive/condor-users/
> http://www.opencondor.org/spaces/viewmailarchive.action?key=CONDOR