Am 11.04.2014 um 10:18 schrieb Arnau Bria:
> On Thu, 10 Apr 2014 17:49:30 +0200
> Reuti Reuti wrote:
>
>> Hi,
> Hi Reuti,
>
>>> 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?
> Nope....
> 1) qsub -jsv ...
> 2) $cwd/.sge_request
> 3) $HOME/.sge_request
> 4) $SGE_ROOT/$SGE_CELL/common/sge_request
> 5) Global configuration
> 1, 2, 3 do not exists
>
> 4:
> /usr/share/gridengine/antcluster/common/sge_request does not exists...
Usually it's there but only some comments inside.
> and 5)
> # qconf -sconf|grep url
> jsv_url none
Good.
> *I'm testing it directly from the sge master. On sge submit hosts
> sge_request exists and it's content it:
>
> # grep -v "#" /usr/share/gridengine/antcluster/common/sge_request|grep .
> -w e
> -jsv /usr/local/bin/jsv.pl
>
>
>>> 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?
>
> Sorry, but I don't have any server-side jsv... so, how can it stay
> alive? if it's not defined, does it have a default value
If it would be there, it wouldn't quit but stay in a loop until the content of
the referenced url changes.
What about any consumable complex - `qconf -sc` and attached by `qconf -me
<exechost>`?
-- Reuti
>>> 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.
> it does...
>
>
> jsv_on_start(sub {
> jsv_send_env();
> });
>
> jsv_on_verify(sub {
> jsv_log_info ("DEBUG: jsv_on_verify start");
> [...]
> Several if / else
> [...]
>
> if ($do_correct) {
> jsv_log_info ('DEBUG: the job has been corrected. calling
> jsv_correct');
> jsv_correct('Job is corrected');
> return;
> }
> jsv_log_info ('DEBUG: the job has been accepted. calling
> jsv_accept');
> jsv_accept('Job is accepted');
> return;
> });
>
> jsv_main();
>
>
>> -- Reuti
> Cheers,
> Arnau
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
