[GE users] qsub preventing -clear (JSV)

fredwag Frederik.Wagner at lrz.de
Wed Jul 14 14:31:17 BST 2010


Hi Reuti,

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)

> 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:/...'

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



More information about the gridengine-users mailing list