Hi,
Am 10.04.2014 um 12:41 schrieb Arnau Bria:
> some user is running a new application that uses drmaa for sending jobs
> to our SGE cluster (2011.11p1-2).
>
> We have a client side jsv perl script that rejects all jobs that try to
> specify the binding strategy (as we already do it in the jsv itself).
> (First solution would be modify the jsv so it does not reject
> the job as we already set all binding values, but I want to understand
> what is happening). There's only one jsv script, and I'm sending the
> job with "-jsv jsv_script".
So there is no server-side JSV in the game?
> When we run this application, it tries to submit several jobs, but it
> fails because in some point the binding strategy is set and the jsv
> script rejects the job.
> From my test, the binding strategy is set by the jsv itself. So call 1
> has no binding strategy, call 2 inherits the binding from call 1, and
> so on ....
>
> the basic structure of my jsv is:
> ---------------------------
> jsv_on_start(sub {
> jsv_send_env();
> });
> jsv_on_verify(sub {
> %params = jsv_get_param_hash();
> [...]
> here I do all the modifications, if any $do_correct=1;
> [...]
> if ($do_correct) {
> jsv_correct('corrected');
> }else{
> jsv_accept('accepted');
> }
> }
> jsv_main();
> ---------------------------
>
> and a submission looks like:
>
>
> DEBUG: jsv_on_verify start
> DEBUG: params hash loaded:
> DEBUG: binding value from params hash:
> DEBUG: setting binding case 1
> DEBUG: the job has been corrected. calling jsv_correct
> queued 8778860: emt0.0.0.traindir.e81295f2c09a11e3a369002264a1a0ac
> (virtual_free=2048M h_vmem=2048M h_stack=10M)
>
>
> DEBUG: jsv_on_verify start
> DEBUG: params hash loaded:
> DEBUG: binding value from params hash:
> DEBUG: setting binding case 1
> DEBUG: the job has been corrected. calling jsv_correct
> DEBUG: jsv_on_verify start
> DEBUG: params hash loaded:
> DEBUG: binding value from params hash: linear
> DEBUG: job reject because binsing is already set
> DEBUG: the job has been accepted. calling jsv_accept
> queued 8778884: emt0.0.bundle.traindir.e81295f2c09a11e3a369002264a1a0ac
> (virtual_free=2048M h_vmem=2048M h_stack=10M)
> [...]
>
> so, in the first block binding value is empty, but in the second block,
> there's a call to jsv_correct but the job is not submitted. so the
> submission is passed to the same JSV instance, and now the biding param
> has a value.
The server-side JSV will stay alive. Do you observer this for the client side
JSV too?
> from man page:
>
> This function can only be used in jsv_on_verify(). After it has been called,
> the function jsv_on_verify() has to return immediately.
>
> but it's not returning ....
It's meant, that your Perl script has to return and doesn't do any further
processing.
-- Reuti
> in which circunstances this jsv_correct does not submit a job ?
> I've tried to clean the params hash in several ways but it always has
> the values, also a call to jsv_clear_params, but that function is no
> valid in the perl module:
>
> "jsv_clear_params" is not exported by the JSV module
>
> $ grep jsv_clear_params /usr/share/gridengine/util/resources/jsv/JSV.pm
> $
>
> So, anyone could explain what is happening here?
>
> Thanks in advance,
> Arnau
>
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
