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

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

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


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.


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,


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.


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)?


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.


Kind Regards

----- 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.

Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting

The archives can be found at either