[Glass] tracking down errors that occur in FastCGI gems but not GemTools or tODE.

Dale Henrichs-3 wrote

Since things work in GemTools/tODE, I am suspicious of code in GLASS that
detects whether or not you are running with a GUI attached .. The following
methods are used for those types of tests:

  MCPlatformSupport class>>gemToolsActive
  OBGemStonePlatform class>>canConfirm
  OBGemStonePlatform class>>canInform

A quick pass through senders of these method doesn't reveal anything
interesting to me though ...

I seem to recall some monkey business with synching your timezone to the
system and it seems that a call of some sort is needed, but I don't recall
offhand  ...

Finally there is code that gets triggered during session startup
(SystemLoginNotification class>>sessionStart) ... but that code is not
specific to GemTools/tODE ....

I'll dig around in the time zone code for inspiration, but put this out
there in case this rings the bell for someone else ...

Dale


On Tue, Jan 28, 2014 at 9:42 AM, Paul DeBruicker <[hidden email]> wrote:

> I'm using Chronos on GemStone 3.1.0.4 (upgrading to 3.1.0.5 now) and I've
> been getting errors in its timezone policy lookup code in my FastCGI gems.
>  The same code works fine when I connect with GemTools or tODE.  And if in
> GemTools I attempt to debug the error that the FastCGI gem put on the
> object log it also works fine at that time.
>
>
> Restarting the FastCGI gems doesn't seem to fix the problem with any
> permanence. It also is only happening on the server.  On my laptop the
> FastCGI gems do fine.  The Chronos timezone lookup code may access the file
> system for the initial lookup, but I am pretty sure it has the timezone
> information cached in the stone after that.
>
>
> What are some strategies for figuring out what the problem is?
>
> Thanks
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3 wrote

Hmm, There must be some initialization code that gets executed at startup
for the Chronos libs .. so that must be the point where the difference lies
and a well-placed breakpoint in the init code, that can give you a stack in
GemTools/tODE should provide insight and snapping off a continuation or
dumping a stack into objectlog at that point should complete the picture ...

Dale


On Tue, Jan 28, 2014 at 10:19 AM, Paul DeBruicker <[hidden email]>wrote:

> The Chronos timezone stuff is all orthogonal to the GemStone timezone
> stuff.
> Chronos has its own method for getting time zone transition rules and those
> timezones are only used in the Chronos date and time classes.
>
>
> So its likely not the GemStone timezone stuff.  I'll take a look at the
> other suggestions
>
>
> Maybe instead it could be file permissions or poorly coordinated
> commits/aborts or a gem's view of the repository getting out of sync in
> some
> way.
>
>
>
>
>
>
>
> Dale Henrichs-3 wrote
> > Since things work in GemTools/tODE, I am suspicious of code in GLASS that
> > detects whether or not you are running with a GUI attached .. The
> > following
> > methods are used for those types of tests:
> >
> >   MCPlatformSupport class>>gemToolsActive
> >   OBGemStonePlatform class>>canConfirm
> >   OBGemStonePlatform class>>canInform
> >
> > A quick pass through senders of these method doesn't reveal anything
> > interesting to me though ...
> >
> > I seem to recall some monkey business with synching your timezone to the
> > system and it seems that a call of some sort is needed, but I don't
> recall
> > offhand  ...
> >
> > Finally there is code that gets triggered during session startup
> > (SystemLoginNotification class>>sessionStart) ... but that code is not
> > specific to GemTools/tODE ....
> >
> > I'll dig around in the time zone code for inspiration, but put this out
> > there in case this rings the bell for someone else ...
> >
> > Dale
> >
> >
> > On Tue, Jan 28, 2014 at 9:42 AM, Paul DeBruicker <
>
> > pdebruic@
>
> > > wrote:
> >
> >> I'm using Chronos on GemStone 3.1.0.4 (upgrading to 3.1.0.5 now) and
> I've
> >> been getting errors in its timezone policy lookup code in my FastCGI
> >> gems.
> >>  The same code works fine when I connect with GemTools or tODE.  And if
> >> in
> >> GemTools I attempt to debug the error that the FastCGI gem put on the
> >> object log it also works fine at that time.
> >>
> >>
> >> Restarting the FastCGI gems doesn't seem to fix the problem with any
> >> permanence. It also is only happening on the server.  On my laptop the
> >> FastCGI gems do fine.  The Chronos timezone lookup code may access the
> >> file
> >> system for the initial lookup, but I am pretty sure it has the timezone
> >> information cached in the stone after that.
> >>
> >>
> >> What are some strategies for figuring out what the problem is?
> >>
> >> Thanks
> >> _______________________________________________
> >> Glass mailing list
> >>
>
> > Glass@.gemtalksystems
>
> >> http://lists.gemtalksystems.com/mailman/listinfo/glass
> >>
> >
> > _______________________________________________
> > Glass mailing list
>
> > Glass@.gemtalksystems
>
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Glass-tracking-down-errors-that-occur-in-FastCGI-gems-but-not-GemTools-or-tODE-tp4739918p4739931.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass