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

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"?

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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Mon, Sep 22, 2014 at 2:33 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com

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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass