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

[Mariano Martinez Peck via Glass]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140922/786eb3cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gem.conf
Type: application/octet-stream
Size: 222 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140922/786eb3cd/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seasideService.conf
Type: application/octet-stream
Size: 180 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140922/786eb3cd/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FastCGI_service_server-9035.log
Type: application/octet-stream
Size: 4724 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140922/786eb3cd/attachment-0005.obj>