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

Mon Sep 22 11:11:33 PDT 2014

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/e4cd4ee0/attachment-0001.html>