Jan,
Falkon runs in user space (not system administrator space). The
pre-requisites to compile Falkon are Java 1.4 and ANT, and to run Falkon
are Java 1.4. The rest of the needed software is all bundled in the
Falkon SVN repository. The rest of the software stack is: 1) GT4 Java
WS-Core container, 2) ploticus (for graphs), 3) 500 line web server (to
view graphs remotely), and 4) the various pieces of the Falkon framework
(service code, worker code, command line client, GUI monitor). So,
basically, the end user just needs Java and ANT, which are both
downloadable and installable in a matter of 10~20 min.
I am not sure how clean (or up-to-date) the installation instructions
are, but basically I (as the main developer of Falkon) can get the
entire software stack from SVN in 6.10 minutes (from a LAN connected
machine), compile in 1.01 min, configure things to suit the environment
in a a matter of minutes (2 configuration files control everything), and
be up and running on the order of O(10 min). If you need to get Java
and ANT as well, make it O(30 min). If you want to use security and
need to setup your security credentials (which you would have to as well
for other services such as GRAM4), then that could further add to the
time it takes to get up and running, but that is out of my control.
The biggest challenge for new applications that want to use Falkon will
be to either wrap the existing command line client, or to change the
command line client to suit their needs. However, if an application
already has support for GRAM, the transition to Falkon should be
relatively straight forward as the semantics are similar (define job
description, submit, wait for notification of completion).
I hope its clear that the middleware at a grid site does not need to
change at the site level. Falkon will be a user level process that runs
on behalf of the user who configured and started it, will allocate
resources via GRAM4, dispatch tasks via WS calls directly to compute
resources (out of band of GRAM), etc. Once its configured at a site
with the GRAM4 server location, number of resources needed (upper and
lower bounds), the time resources are needed for, etc, starting and
stopping Falkon is a 1 command invocation. Once started, Falkon will
monitor the Falkon queue, and increase the number of resources when the
queue grows, and shrink the number of resources when the queue is empty
(all within the bounds specified in the configuration of Falkon).
If you happen to try Falkon out, I'd be happy to hear back feedback
about how easy it was to setup to run some simple sleep jobs, and even
more how easy/difficult it was to use the client API to integrate into
your existing application!
Cheers,
Ioan
Jan Ploski wrote:
[EMAIL PROTECTED] schrieb am 11/12/2007 02:48:50 PM:
Jan Ploski wrote:
... You still have to "package small jobs
into big jobs" in an application-specific manner, but the module takes
care of all the synchronization required to run the "big job" at the
target site.
BTW, with Falkon, you do not have to package many jobs together to
increase efficiency, every job gets handled separately and things are
still quite efficient. We have some applications that have job durations
in the 10~100 ms range, and for those, we do package multiple jobs
together to decrease the overhead per job, but this is done all internal
within Falkon by setting some configuration options. More details about
all these are in the paper.
Ioan,
Thanks for the interesting references! Still, I don't think your solution
would be useful to the original poster. From a user's perpective, what are
the prerequisites to use Falkon? Few people have the capability to
replace/upgrade the middleware at their sites or the time to work it out
by themselves. Based on my experience, users want something which they can
understand and deploy in half an hour...
Regards,
Jan Ploski
