Am 11.04.2014 um 11:04 schrieb Arnau Bria:

> On Fri, 11 Apr 2014 10:46:12 +0200
> Reuti Reuti wrote:
> 
> [...]
> 
>>>>> 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>`?
> 
> # qconf -sc
> #name               shortcut   type        relop requestable consumable 
> default  urgency 
> #----------------------------------------------------------------------------------------
> [...]
> h_vmem              h_vmem     MEMORY      <=    YES         YES        0     
>    0
> [...]
> slots               s          INT         <=    YES         YES        1     
>    1000
> [...]
> virtual_free        vf         MEMORY      <=    YES         YES        0     
>    0
> 
> the only ones with consumable != NO .
> 
> # qconf -se node-hp0303
> hostname              node-hp0303.linux.crg.es
> load_scaling          NONE
> complex_values        h_vmem=126G,virtual_free=126G

> 
> any problem with those resources? 

No, they are fine,

About DEBUG output you posted in your first email: the second block was from 
one submission command?

-- Reuti


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

Reply via email to