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

[Mariano Martinez Peck via Glass]

On Wed, Sep 24, 2014 at 6:28 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Another bug bites the dust:)
>
> After working with Mariano off-line, it turns out that what happened here
> is that when Mariano fired of the `topaz -l -e` job using the following
> expression:
>
>

I just wanted to say in the mailing list that Dale and the rest of the gang
were very helpful and friendly.
So..thank you very much for your support.


>   cat << EOF | nohup $GEMSTONE/bin/topaz -l -e $4 -I
> $APPLICATION_DIR/.topazini 2>&1 >>
> $APPLICATION_LOG_DIR/${1}_server-${2}.log &
>
> That the $APPLICATION_DIR/.topazini had a `set gemnetid` statement in it
> and the `set gemnetid` turns a linked topaz session (which honors the conf
> file specified by -e flag) into a an RPC session that spawns a separate gem
> process that does not honor the -e flag ...
>
> I've submitted an internal bug (BUG 44664) to throw a warning or error
> when using a `set gemnetid` statement with a topaz session started with a
> -l ...
>


That would be nice, thanks.


>
>
> 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/20140924/2a9c2e0b/attachment-0001.html>