[GE users] qsub preventing -clear (JSV)

reuti reuti at staff.uni-marburg.de
Wed Jul 14 14:49:13 BST 2010

Hi Frederik,

Am 14.07.2010 um 15:31 schrieb fredwag:

> On 07/14/2010 03:21 PM, reuti wrote:
>> Hi,
>> Am 14.07.2010 um 14:51 schrieb fredwag:
>>> in the SGE documentation it is stated, that server side JSVs
>>> shouldn't be scripts. But what are the alternatives? Should one
>>> write a C program or is perl already o.k. (so script meaning bash
>>> or similar?).
>> it's just a performance issue. Nevertheless you can use scripts - how
>> many jobs do you expect to be submitted per second? When you start
> not too many, it's more some like some thousands over the day (which
> _could_ come in some bulks)

then I woud suggest to start with a script and observe the load on the qmaster machine. It might also depend on the usual runtime of a job. For us jobs run usually for days, hence whether the submission takes a few seconds more or less is not an issue.

>> from scratch with e.g. a pure C program, you would need to follow the
>> exact communication protocol for a JSV, while this burden is taken
>> from you with the included libs for bash, perl, tcl and JAVA.
>> When you implement the communication protocol, you can use any
>> programming language you like.
> I was expecting this. I was skeptic due to the docs stating only the
> support of 'script:/...'

You mean the Wiki? In the Wiki the communication protocol is listed in detail.

-- Reuti

>>> So not having answered the previous question, for a more complex
>>> JSV it look like using client side JSV is the right thing. When I
>>> do some mandatory mangling with the qsub option: How do I prevent a
>>> user from using the '-clear' flag in which case any administrator 
>>> defined JSV (in $SGE_ROOT/$SGE_CELL/common/sge_request) will not
>>> be executed?
>> Although the JSV shouldn't fork, it's still possible to use a bash
>> wrapper which start a more complex computation in C when it's bulky.
> it's not so bulky. I got a bit skeptic due to the docs mentioning the
> performance issue.
> So you would say a server side JSV is normally fine (I would use perl
> then), since there's no way to prevent the '-clear'?
> Thanks a lot,
> Frederik
>> -- Reuti
>>> To me it looks like: either server side JSV with performance
>>> problems or client side JSV with the possible user interference...
>>> Thanks a lot for any help, Frederik
>>> ------------------------------------------------------ 
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=267965
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe at gridengine.sunsource.net].
>> ------------------------------------------------------ 
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=267968
>> To unsubscribe from this discussion, e-mail:
>> [users-unsubscribe at gridengine.sunsource.net].
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=267971
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].


To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].

More information about the gridengine-users mailing list