Changes between Version 28 and Version 29 of RemoteJob

Timestamp:

Apr 5, 2011, 7:37:51 AM (13 years ago)

Author:

tonig

Comment:

added FAQs

RemoteJob

@@ -197 +197 @@
 
 
-=== Job submission ===
-
-Given that RBoinc takes care of uploading the files, will it be
-important to ensure that input files for different WUs have 
-different names, so they don't conflict?
-
-    The scientist can and reuse whatever names and contents he
-    likes. The only thing that matters is the file content at the
-    moment of submission. The RBoinc server will generate internal
-    unique names (which are hidden from the user).
-
-
-Will files with identical names conflict
-when they end up in the ''download'' directory?
-
-    No, it will be handled correctly: file names are made
-    unique (in fact, equal to the file's MD5), even though the
-    submitter used the same name for different contents. (It's fairly
-    common e.g. for 1000 WUs to have in common at least one of the
-    inputs).
-
-
-Will there be a problem if a user send simultaneously 1000 jobs by a
-script?
-
-    It's perfectly fine (common indeed).
-
-=== Retrieve ===
-
-How does the manual retrieve operation affect workunits once a job has
-been performed?
-
-    Retrieve will free up space taken on the server by the results of
-    the completed WUs. Currently running, scheduled, and future WUs
-    will be otherwise unaffected (e.g., ''step1'' may depend on ''step0''
-    through the chaining mechanism).
-
-    Note, however, that a {{{boinc_retrieve -stop ...}}}  command will
-    stop the chaining machinery, ie. the generation of new WUs. This is 
-    a ''stop'' operation, which should not be confused with a ''retrieve''.
-
-
-And what about the results if you don't perform a "retrieve"?  
-
-    The results are kept on the server until the issuing scientist
-    retrieves them. (In fact, they may fill up the server if
-    forgotten.)
-
+=== Portability and server coexistence ===
+
+Is your application directly compatible with
+Windows?
+
+    The '''client''' scripts are likely portable with minor changes
+    (just install a good Perl interpreter and the required modules).
+
+
+Is it possible to use your commands with different BOINC projects?
+
+    Normally a ''RBoinc server'' is tied to the corresponding
+    ''Boinc server'' (but it can talk to any of its applications).  The
+    ''RBoinc clients'' can talk to multiple servers using different URLs
+    ('''-url''' option).
+
+
+I was thinking of having several Boinc projects to assign easily each
+of them to a specific group of users.  Should I be installing multiple
+servers with their own URLs?
+
+    Yes - that will be the most flexible solution (e.g. you wil be
+    able to perform maintenance on each of them separately, make
+    firewall rules, etc). Alternatively, you can create several
+    applications on the same server, if you prefer.
+
+
+=== Server and installation ===
 
 What is the relationship between RBoinc and the assimilator?
@@ -266 +246 @@
 
 
+
+
+What is ''ENCODE_EXECUTABLE'' ?
+
+    It's an optional script to pre-process files before submission, e.g. for a server-side sanity check, or reformatting, etc.
+
+
+What is ETC_DIR => "$cgi/etc" ?  Do I have to copy files included in server/etc ? Which ones will be used ?
+
+    Most notably, the files which are supplied as defaults (if any), e.g. those marked as         {{{<rboinc immutable="true"/>}}} or  {{{<rboinc optional="true"/> }}}     in the template. 
+
+
+What is  "process.sh"? Is it a daemon? What if server is restarted ?
+
+    ''process'' created automatically by the boinc_submit_server in each GROUP directory. (It's at the end of the server submission script.) It's invoked in two cases:
+
+      1. as the last step of the submission, when everything has been set up. It will create_work and exit.
+      1. it will be invoked by the assimilator. if chaining is required,  it will create_work for the next "chain step" (depending on the one which just ended successfully) and exit.
+
+    Therefore its execution is short and usually triggered by a daemon; stopping/restarting boinc will not affect it.
+
+
+=== Job submission ===
+
+Given that RBoinc takes care of uploading the files, will it be
+important to ensure that input files for different WUs have 
+different names, so they don't conflict?
+
+    The scientist can and reuse whatever names and contents he
+    likes. The only thing that matters is the file content at the
+    moment of submission. The RBoinc server will generate internal
+    unique names (which are hidden from the user).
+
+
+Will files with identical names conflict
+when they end up in the ''download'' directory?
+
+    No, it will be handled correctly: file names are made
+    unique (in fact, equal to the file's MD5), even though the
+    submitter used the same name for different contents. (It's fairly
+    common e.g. for 1000 WUs to have in common at least one of the
+    inputs).
+
+
+Will there be a problem if a user send simultaneously 1000 jobs by a
+script?
+
+    It's perfectly fine (common indeed).
+
+=== Retrieve ===
+
+How does the manual retrieve operation affect workunits once a job has
+been performed?
+
+    Retrieve will free up space taken on the server by the results of
+    the completed WUs. Currently running, scheduled, and future WUs
+    will be otherwise unaffected (e.g., ''step1'' may depend on ''step0''
+    through the chaining mechanism).
+
+    Note, however, that a {{{boinc_retrieve -stop ...}}}  command will
+    stop the chaining machinery, ie. the generation of new WUs. This is 
+    a ''stop'' operation, which should not be confused with a ''retrieve''.
+
+
+And what about the results if you don't perform a "retrieve"?  
+
+    The results are kept on the server until the issuing scientist
+    retrieves them. (In fact, they may fill up the server if
+    forgotten.)
+
+
+
 The scientist may request the output at any time.  Is it also possible
 to retrieve automatically the output in a predefined folder when a job is
@@ -278 +330 @@
 
 
-=== Portability and server coexistence ===
-
-Is your application directly compatible with
-Windows?
-
-    The '''client''' scripts are likely portable with minor changes
-    (just install a good Perl interpreter and the required modules).
-
-
-Is it possible to use your commands with different BOINC projects?
-
-    Normally a ''RBoinc server'' is tied to the corresponding
-    ''Boinc server'' (but it can talk to any of its applications).  The
-    ''RBoinc clients'' can talk to multiple servers using different URLs
-    ('''-url''' option).
-
-
-I was thinking of having several Boinc projects to assign easily each
-of them to a specific group of users.  Should I be installing multiple
-servers with their own URLs?
-
-    Yes - that will be the most flexible solution (e.g. you wil be
-    able to perform maintenance on each of them separately, make
-    firewall rules, etc). Alternatively, you can create several
-    applications on the same server, if you prefer.
-
 
 (Many thanks to Boris Dayma).