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

[Dale Henrichs via Glass]

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:

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

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140924/6286b24f/attachment.html>