[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] [birdbath] java as executable and UPDATE_INTERVAL
- Date: Wed, 14 Jun 2006 10:17:06 -0500
- From: Matthew Farrellee <matt@xxxxxxxxxxx>
- Subject: 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
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
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.
----- 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
> 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
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
You can also unsubscribe by visiting
The archives can be found at either