[Glass] GEMSTONE_EXE_CONF higher priority than topaz -e argument ?

[Dale Henrichs via Glass]

Mariano,

Could you again provide me with the three conf files you are currently
using?

With those three files, I should be able to reproduce the problem that you
are seeing myself and then we can move on from there ...

Dale

On Mon, Sep 22, 2014 at 11:11 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Mon, Sep 22, 2014 at 2:45 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 22, 2014 at 2:33 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>> Mariano,
>>>
>>> Good questions.
>>>
>>> Could you please provide me with the two conf files and the header
>>> output from the topaz run and finally how you determine that ".the gem was
>>> actually being executed with the  GEM_TEMPOBJ_CACHE_SIZE of
>>> GEMSTONE_EXE_CONF"?
>>>
>>>
>> The attached gem.conf is the generic one. Pointed from #GEMSTONE_EXE_CONF.
>> The attached seasideServer.conf is the conf file used for -e when I start
>> the seaside gem via topaz.
>> The attached FastCGI_service_server-9035.log is the log of that gem, and
>> as you can see, GEM_TEMPOBJ_CACHE_SIZE has 2000000 which is the value of
>> seasideServer.conf, NOT gem.conf
>>
>> How do I know that the gem is actually being run with a
>> GEM_TEMPOBJ_CACHE_SIZE of 2000000?  Because I am running a large SIXX
>> import, which with the value of gem.conf it crashes with an out of memory
>> exception (expected). If I comment the line of gem.conf so that the -e is
>> the only one, then it works, I can finish the import correctly.
>>
>> Yes, I am using 3.1.0.6.
>>
>
> Ufff....I have more info..... actually.....I found out that I was ALSO
> setting GEM_TEMPOBJ_CACHE_SIZE in my system.conf pointed
> from GEMSTONE_SYS_CONF.... with a very large value. Therefore...when I said
> that the seaside gems were actually taking the value of the gem.conf...it
> might not have been that, but instead, that it was using the one of
> system.conf.
>
> In fact...I have now commented GEM_TEMPOBJ_CACHE_SIZE in both files
> GEMSTONE_SYS_CONF and GEMSTONE_EXE_CONF. And guess what? My sixx import
> crashes immediately (I assume it is using that very small default
> GEM_TEMPOBJ_CACHE_SIZE of 10MB).
>
> So...to conclude...it seems like my GEM_TEMPOBJ_CACHE_SIZE from my
> seasideService.conf is being totally ignored even if printed in its topaz
> log....
>
> As a workaround, I could get the GEM_TEMPOBJ_CACHE_SIZE value and send it
> via -T to the topaz call. However...I am afraid that the rest of the vars I
> define in seasideServer.conf are ignored as well...
>
> I have double checked that the conf file full path passed to -e is
> correct.
>
> Any idea?
>
>
>
>
>>
>> Thanks,
>>
>>
>>
>>> I'm finding out what the precedence between the env var and command line
>>> declaration is supposed to be as we speak...
>>>
>>> Dale
>>>
>>> On Mon, Sep 22, 2014 at 9:25 AM, Mariano Martinez Peck via Glass <
>>> glass at lists.gemtalksystems.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I found a problem now..which I don't know why I didn't have before...
>>>>
>>>> For all my stones and gems, I source an "env" file. So...for everytime
>>>> I was running topaz, I had this variable exported:
>>>>
>>>> export GEMSTONE_EXE_CONF=/path/to/general/gem/file/gem.conf
>>>>
>>>> And then, my seaside gems start this way:
>>>>
>>>> cat << EOF | nohup $GEMSTONE/bin/topaz -l -e $4 -I
>>>> $APPLICATION_DIR/.topazini 2>&1 >>
>>>> $APPLICATION_LOG_DIR/${1}_server-${2}.log &
>>>> ......
>>>>
>>>> Note the "-e $4" which is the full path to a configuration file which
>>>> is similar to what you have in
>>>> /opt/gemstone/product/seaside/etc/seaside3.conf
>>>>
>>>> The problem was that I was defining GEM_TEMPOBJ_CACHE_SIZE in both
>>>> files, the one pointed out from GEMSTONE_EXE_CONF and the one passed to
>>>> topaz via -e.
>>>> In my logs of the gen session opened from topaz, I did notice that the
>>>>  GEM_TEMPOBJ_CACHE_SIZE was printed correctly (the one set in the file sent
>>>> via -e). However....that was not happening...the gem was actually being
>>>> executed with the  GEM_TEMPOBJ_CACHE_SIZE of GEMSTONE_EXE_CONF.
>>>>
>>>> So...my first question is... is it expected that GEMSTONE_EXE_CONF has
>>>> precedence or higher priority than what I send via -e to topaz?
>>>>
>>>> If true...then shouldn't the topaz session log tell me the
>>>>  GEM_TEMPOBJ_CACHE_SIZE it will really use?
>>>>
>>>> thanks in advance
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140922/bf65bdb2/attachment-0001.html>