Gem go down for WAFileLibrary error

Dario,

This is now well beyond my scope:) Hopefully others can chime in...

Dale

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, March 22, 2013 5:16:30 AM
| Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down
|
|
| Dale,
|
| i understand ( a minimal )  the scope of rc?.d  files and i have do test
| rebooting  the system.
|
| As for magic the GLASS environment  at restart go well and are ready to
| manage web request.
|
| I don't  verify if the down of the system  manage correctly the down of
| Gemstone.
|
| The relative log report :
|
| > - 03/22/13 12:02:40 CET ---
| >     SHUTDOWN command was received from user DataCurator session 2 gem
| >     processId 9073.
| >
| >     SHUTDOWN command was generated by  .
| >     Waiting for all tranlog writes to complete
| >     Waiting for NetRead thread to stop
| >
| >     Now stopping GemStone.
| > ========================================================================
| >
| >     Terminating stone.
| >  ________________________________________________________________
| >
|
| It's right ?????
|
|
|
|
| In my server ubuntu running some GLASS environment.
|
| But from what i understand  the Monty daemontools   environment can
| configured only one galss environment.
|
| The relative script  reference directly the: /etc/default/gemstone
| creating by   ./setupAll.sh
|
| and the bash    gemstone  and  topaz   into /etc/init.d/ also.
|
| These bashs is also call from rc?.d links
|
|
| Anyone have some idea how i can configuring to manage some environment?
|
| The daemontools  etc/sv and etc/service directory  are configurable by
| /etc/default/gemstone
|
| and i think manage by daemontools.
|
| The big problem is relative to the rc?.d  link.
|
| I need to add some rc?.d entry for any specific environment and create all
| relative etc/init.d  script each with specific configuration ?
|
|
| Thanks,
|
| Dario
|
|

embedded replies...

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, March 22, 2013 10:09:52 AM
| Subject: Re: [GS/SS Beta] Gem go down for WAFileLibrary error
|
| Dale,
|
| > Are you using WAGemStoneProductionErrorHandler?
| >
|
| Yes i using the WAGemStoneProductionErrorHandler.
|
| A) The self halt into in a message answer:
|
| a Halt occurred (error 2709)
| DTR: Your request could not be completed. An exception occurred. The
| system administrator has been informed of this error.

Okay, so this behaves as expected...

|
|
| B) The self halt    into a syleBaseCss for example:
|
| styleBaseCss
|
|   self halt.
|   ^'
|   /* CSS DTR  Personalizzazioni */
|   /* *** DTR thought, designed and developed by Dario Trussardi Romano
|   ***
| */
|   .colorBaseSctLcn{
|   color: green;
|   }
|
| don't report any error but go down the relative  gem.

Ahhh ... this is in the Seaside framework code and isn't protected by the WAGemStoneProductionErrorHandler logic ... There are Error handlers that try to prevent a gem from being taken down by an error in the framework, but Halts aren't handled there ...

If you are trying to debug Seaside framework code in PRODUCTION then you have to resort to different tricks.

If you need a stack trace, then use this:

   GRPlatform currentlogError: 'detailed description' title: 'label' shouldCommit: false

You'll get stack dumped to the ObjectLog and the gem log (use false, so you don't have to worry about committing at wrong time).

You might be able snap off a continuation using DebuggerLogEntry class>>createContinuationLabeled:, but you can't always be guaranteed of getting a commit (depends upon where you are in the framework) ... If you plan to try this, do experiments in your sandbox environment before pushing into production...


|
| Thanks,
|
| Dario
|
| P.S.  about your :
|
| > When you fix the scripts, could you issue a pull request for the glassdb
| > fork of daemontools[1] with your updates?
|
|
| I'm not expert about it, but i do it soon

No hurry ... I understand that there is a learning curve (use google to find answers to git/github related questions ... works surprisingly well) ... Moving forward, I will be moving more and more of the GLASS code base to github...

Dale

Ciao, Dale
        As i write in old e-mail:

                the halt is only for understand.

                I can create a styleBaseCss with dynamic code ( it's not elegant ? ) and it can go into error.

        For example:


        styleBaseCss
 
    ^'
  .colorBaseSctLcn{
  color: green;
  }' ,

        self defineOtherStyle,

        '.colorYellow{
  color: yellow;
  }'
       

        Now the defineOtherStyle method   had dynamically  some style and when execute can erase some error - exception.
       
        It's managed by the system or causing the down of the gem ?

        If i right understand the halt  at this level is not managed by the system and cause the down of the gem.

        OK, the first solution to prevent the down of the gem,  is to don't use dynamic method into WALibrary subclass definition,
       
        but it could be a possibility also in production system ?

        Thanks,

                Dario

embedded...

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Saturday, March 23, 2013 5:15:14 AM
| Subject: Re: [GS/SS Beta] Gem go down for WAFileLibrary error
|
| Ciao, Dale
|
| As i write in old e-mail:
|
| the halt is only for understand.
|
| I can create a styleBaseCss with dynamic code ( it's not elegant ? ) and it
| can go into error.
|
| For example:
|
|
| styleBaseCss
|  
|     ^'
|   .colorBaseSctLcn{
|   color: green;
|   }' ,
|
| self defineOtherStyle,
|
| '.colorYellow{
|   color: yellow;
|   }'
|
|
| Now the defineOtherStyle method   had dynamically  some style and when
| execute can erase some error - exception.
|
| It's managed by the system or causing the down of the gem ?
|
| If i right understand the halt  at this level is not managed by the system
| and cause the down of the gem.
|
| OK, the first solution to prevent the down of the gem,  is to don't use
| dynamic method into WALibrary subclass definition,
|
| but it could be a possibility also in production system ?
|
| Thanks,
|
| Dario
|

There _SHOULD_ be an error handler fairly high up the stack that is intended to handle Errors ... Could you reproduce the problem in your sandbox and provide a copy of the gemstone stack ... there must be a path through the code that isn't protected ...

Dale

Dale,

You need to create a pull request like so:

https://help.github.com/articles/creating-a-pull-request



On 03/26/2013 08:04 AM, Dario Trussardi wrote:

I hit send accidentally.  On github you need to fork Monty's repo and
then push your changes to your fork of his repo.  Once you've done that
you use the github ui as described in the link I sent to create the pull
request.


Hope this helps

Paul


On 03/26/2013 08:04 AM, Dario Trussardi wrote:

Dario,

If you fork the glassdb fork of GemStone_daemontools_setup[1] then I can merge your request directly. As with gemsource, I can add developers to the glassdb project on github allowing direct access to the glassdb repositories, so moving forward I would prefer going with glassdb forks of repositories ...

If you've already issued the pull request to Monty's repo, that's no big deal, I'll be able to get your update through Monty's repo...

Dale

[1] https://github.com/glassdb/GemStone_daemontools_setup

----- Original Message -----
| From: "Paul DeBruicker" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, March 26, 2013 8:17:47 AM
| Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down
|
| I hit send accidentally.  On github you need to fork Monty's repo and
| then push your changes to your fork of his repo.  Once you've done that
| you use the github ui as described in the link I sent to create the pull
| request.
|
|
| Hope this helps
|
| Paul
|
|
| On 03/26/2013 08:04 AM, Dario Trussardi wrote:
| > Dale,
| >
| >> Dario,
| >>
| >> When you fix the scripts, could you issue a pull request for the
| >> glassdb fork of daemontools[1] with your updates?
| >
| > i'm ready to push my update to daemontools but when i do:
| >
| > git push origin master
| >
| > the system answer :
| >
| > *ERROR: Permission to Monty/GemStone_daemontools_setup.git denied to
| > dario,,,,,,,, *git profile
| > *fatal: The remote end hung up unexpectedly *
| > *
| > *It's a my problem or i need to get the push permission for
| > the daemontools  repository ?
| >
| > Thanks,
| > Dario
| >
| >>
| >> Thanks,
| >>
| >> Dale
| >>
| >> [1] https://github.com/glassdb/GemStone_daemontools_setup
| >>
| >> ----- Original Message -----
| >> | From: "Dario Trussardi" <[hidden email]
| >> <mailto:[hidden email]>>
| >> | To: "GemStone Seaside beta discussion" <[hidden email]
| >> <mailto:[hidden email]>>
| >> | Sent: Friday, March 22, 2013 4:14:51 AM
| >> | Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down
| >> |
| >> |
| >> | Dale,
| >> |
| >> | > Dario,
| >> | >
| >> | > Sounds good ... I'm glad we're getting there, finally:)
| >> | >
| >> | > The class BreakpointNotification is only used in 2.4.x, so you are
| >> using a
| >> | > startMaintenance30 script from a 2.4.x distribution ... you
| >> probably need
| >> | > to modify the startMaintenance30 script from your 3.0 product tree...
| >> |
| >> |
| >> | Thehttps://github.com/Monty/GemStone_daemontools_setup  is hold and
| >> writing
| >> | before the Gemstone 3.1 is released
| >> |
| >> |
| >> | The only problem i found is relative to themaintenanceGem30  script
| >> | component of Monty git release ( copy by./ setupAllinto:
| >> | ../seaside/bin/  )
| >> |
| >> | As you write it is setup to work only with 2.4  gemstone release.
| >> |
| >> | I need to integrate the   maintenanceGem30script  with the
| >> | startMaintenance30 script from a   3.1.0.2  distribution
| >> |
| >> | Now all daemontools work well.
| >> |
| >> |
| >> |
| >> |
| >
|
|

Dale,

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, March 26, 2013 10:06:59 AM
| Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down
|
| Dale,
|
| if i right understand:
|
|
| > Dario,
| >
| > If you fork the glassdb fork of GemStone_daemontools_setup[1] then I can
| > merge your request directly.
|
| Yesterday i clone the repository directly not a fork
|
| > As with gemsource,
|
|
| > I can add developers to the glassdb project on github allowing direct
| > access to the glassdb repositories,
|
| Can you ?  With it the push of master repository will works?
|
|
| Now i create a new fork :
| Members of the GemStone_daemontools_setup Network
| Monty created GemStone_daemontools_setup and everyone else forked it. This is
| the family tree.
|
|  Monty / GemStone_daemontools_setup
|   glassdb / GemStone_daemontools_setup
|   dariogithub / GemStone_daemontools_setup

Here you have a fork of Monty's repository instead of the glassdb repository ... any pull request you issue will be against Monty's repository, since you've gone this far, continue your work against Monty's repository, it's probably too much work to "switch horses in mid-stream"
|
|
| > so moving forward I would prefer going with glassdb forks of repositories
| > ...
|
| A this time i need to clone with:
|
| git clone https://github.com/dariogithub/GemStone_daemontools_setup
|
|  manage the change and after push it.

That will make a clone of the repository on your local disk. Then you should create a "topic" branch (lets say its called updateFor3102):

  git checkout -b updateFor3102

Add your script updates to the repository and commit. Then push your changes to your github repo:

  get push origin updateFor3102

Then up on github select the updateFor3102 branch and create a pull request against Monty's repository and you're done...

Dale

Dale,

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, March 26, 2013 2:25:03 PM
| Subject: Re: [GS/SS Beta] Restart in automatic the gem when it go down
|
| Dale,
|
| > | Now i create a new fork :
| > | Members of the GemStone_daemontools_setup Network
| > | Monty created GemStone_daemontools_setup and everyone else forked it.
| > | This is
| > | the family tree.
| > |
| > |  Monty / GemStone_daemontools_setup
| > |   glassdb / GemStone_daemontools_setup
| > |   dariogithub / GemStone_daemontools_setup
| >
| > Here you have a fork of Monty's repository instead of the glassdb
| > repository ... any pull request you issue will be against Monty's
| > repository, since you've gone this far,
| > continue your work against Monty's repository, it's probably too much work
| > to "switch horses in mid-stream"
|
| What do you mean with: continue your work against Monty's repository.
|
| My local disk directory GemStone_daemontools_setup is commit with the change
|
| but i can't push the origin to  ...... ?????
|
| At the command:
|
| git push origin master
|
| the system answer :
|
| ERROR: Permission to Monty/GemStone_daemontools_setup.git denied to
| dario,,,,,,,, git profile
| fatal: The remote end hung up unexpectedly
Dario,

it looks like the local disk copy of the repository was cloned from Monty's repository (Monty / GemStone_daemontools_setup) not your repository (dariogithub / GemStone_daemontools_setup).

If you want to push fixes you have to have cloned your repository from dariogithub / GemStone_daemontools_setup ... =your .git/config file should have an entry that looks something like this:

  [remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = https://github.com/dariogithub/GemStone_daemontools_setup.git

My guess is that the "origin" entry is pointing at Monty's repo...

Dale

Dale,

The log relative o the gem who handled the request with the error report:


 _____________________________________________________________________________
|             GemStone/S64 Object-Oriented Data Management System             |
|                    Copyright (C) VMware, Inc. 1986-2012                     |
|                            All rights reserved.                             |
|                           Covered by U.S Patents:                           |
|            6,256,637 Transactional virtual machine architecture             |
|              6,360,219 Object queues with concurrent updating               |
|                  6,567,905 Generational Garbage Collector.                  |
| 6,681,226 Selective Pessimistic Locking for a Concurrently Updateable Database
+-----------------------------------------------------------------------------+
|    PROGRAM: topaz, Linear GemStone Interface (Linked Session)               |
|    VERSION: 3.1.0.2, Beta  Wed Nov 28 16:23:21 2012                         |
|      BUILD: gss64_3_1_0_x_branch-29651                                      |
|  BUILT FOR: x86-64 (Linux)                                                  |
|       MODE: 64 bit                                                          |
| RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue |
| Feb 19 12:18:21 UTC 2013) 2002MB                                            |
| PROCESS ID: 9228      DATE: 03/28/13 09:47:31 CET                           |
|   USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000)                        |
 _____________________________________________________________________________
|   GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone                       |
|_____________________________________________________________________________|
neither .topazini nor $HOME/.topazini were found
topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 851/851
[Info]: libssl-3.1.0.2-64.so: loaded
[Info]: User ID: DataCurator
[Info]: Repository: working
[Info]: Session ID: 4
[Info]: GCI Client Host: <Linked>
[Info]: Page server PID: -1
[Info]: Login Time: 03/28/13 09:47:31.566 CET
[Info]: libicudata-3.1.0.2-64.so: loaded
[Info]: libicuuc-3.1.0.2-64.so: loaded
[Info]: libicui18n-3.1.0.2-64.so: loaded
Gave this VM preference for OOM killer, Wrote to /proc/9228/oom_score_adj value 250
[03/28/13 09:47:31.638 CET]
  gci login: currSession 1 rpc gem processId -1 OOB keep-alive interval -1
successful login
topaz 1> topaz 1> topaz 1> topaz 1> [474610177 sz:5 cls: 135169 GsFile] aGsFile
topaz 1> topaz 1> topaz 1> topaz 1> daemon Server started on port 9011
-----------------------------------------------------
GemStone: Error         Nonfatal
a Halt occurred (error 2709)
Error Category: 231169 [GemStone] Number: 2709  Arg Count: 1 Context : 620691201 exception : 620691457
Arg 1: [20 sz:0 cls: 76289 UndefinedObject] nil
topaz > exec iferr 1 : where
==> 1 AbstractException >> _signalWith:             (envId 0) @6 line 25   [methId 4459777]
2 AbstractException class >> signal             (envId 0) @3 line 5   [methId 4371457]
3 Object >> halt                                (envId 0) @2 line 5   [methId 3530241]
4 DTRFileLibrary >> styleBaseCss                (envId 0) @2 line 3   [methId 607109377]
5 WAFileLibrary >> documentOf:                  (envId 0) @2 line 2   [methId 139530497]
6 [] in  WAFileLibrary >> handle:               (envId 0) @4 line 20   [methId 154888449]
7 WARequestContext >> respond:                  (envId 0) @3 line 4   [methId 140762881]
8 WAFileLibrary >> handle:                      (envId 0) @16 line 17   [methId 139531265]
9 WAAbstractFileLibrary class >> handle:        (envId 0) @3 line 2   [methId 139561217]
10 WAFileHandler >> responseForContext:          (envId 0) @21 line 15   [methId 140190977]
11 WAFileHandler >> handleFiltered:              (envId 0) @2 line 2   [methId 140190209]
12 [] in  WARequestHandler >> handle:            (envId 0) @3 line 4   [methId 156260609]
13 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
14 WADynamicVariable class >> use:during:        (envId 0) @2 line 4   [methId 139584513]
15 [] in  WARequestContext >> push:during:       (envId 0) @2 line 5   [methId 156247041]
16 ExecBlock >> ensure:                          (envId 0) @2 line 12   [methId 3706625]
17 WARequestContext >> push:during:              (envId 0) @3 line 6   [methId 140760577]
18 WARequestHandler >> handle:                   (envId 0) @2 line 4   [methId 140777217]
19 WADispatcher >> handleFiltered:named:         (envId 0) @3 line 5   [methId 140712449]
20 WADispatcher >> handleFiltered:               (envId 0) @8 line 6   [methId 140710145]
21 [] in  WARequestHandler >> handle:            (envId 0) @3 line 4   [methId 156260609]
22 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
23 WADynamicVariable class >> use:during:        (envId 0) @2 line 4   [methId 139584513]
24 [] in  WARequestContext >> push:during:       (envId 0) @2 line 5   [methId 156247041]
25 ExecBlock >> ensure:                          (envId 0) @2 line 12   [methId 3706625]
26 WARequestContext >> push:during:              (envId 0) @3 line 6   [methId 140760577]
27 WARequestHandler >> handle:                   (envId 0) @2 line 4   [methId 140777217]
28 [] in  WAServerAdaptor >> handleRequest:      (envId 0) @3 line 4   [methId 155661057]
29 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
30 WAServerAdaptor >> handleRequest:             (envId 0) @2 line 5   [methId 140271617]
31 WAServerAdaptor >> handle:                    (envId 0) @2 line 4   [methId 140276481]
32 [] in  WAServerAdaptor >> process:            (envId 0) @2 line 6   [methId 155664129]
33 ExecBlock >> ensure:                          (envId 0) @2 line 12   [methId 3706625]
34 WAServerAdaptor >> process:                   (envId 0) @4 line 7   [methId 140274177]
35 [] in  WAFastCGIAdaptor >> process:           (envId 0) @2 line 6   [methId 185098753]
36 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @2 line 11   [methId 150141441]
37 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
38 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @11 line 12   [methId 138220801]
39 ExecBlock >> ensure:                          (envId 0) @2 line 12   [methId 3706625]
40 TransientRecursionLock >> critical:           (envId 0) @11 line 12   [methId 29283585]
41 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId 0) @3 line 5   [methId 135530497]
42 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @6 line 9   [methId 138221569]
43 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
44 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0) @2 line 17   [methId 135530753]
45 WAFastCGIAdaptor >> process:                  (envId 0) @3 line 4   [methId 182936065]
46 [] in  WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4   [methId 185098241]
47 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
48 WAFastCGIAdaptor >> answerResponderRole:      (envId 0) @2 line 5   [methId 182935809]
49 FSResponderRole >> answer                     (envId 0) @3 line 4   [methId 182140673]
50 FSRole >> handleConnection                    (envId 0) @3 line 5   [methId 182137601]
51 FSConnection >> unsafeServe                   (envId 0) @5 line 8   [methId 181664257]
52 [] in  FSConnection >> safeServe              (envId 0) @2 line 8   [methId 186241281]
53 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
54 [] in  FSConnection >> safeServe              (envId 0) @2 line 9   [methId 186288385]
55 ExecBlock >> on:do:                           (envId 0) @3 line 42   [methId 3737345]
56 [] in  FSConnection >> safeServe              (envId 0) @2 line 12   [methId 184832001]
57 ExecBlock >> ensure:                          (envId 0) @2 line 12   [methId 3706625]
58 FSConnection >> safeServe                     (envId 0) @2 line 15   [methId 181660673]
59 FSConnection >> serve                         (envId 0) @2 line 4   [methId 181668097]
60 [] in  FSSocketServer >> listen:              (envId 0) @3 line 15   [methId 185155585]
61 GsProcess >> _start                           (envId 0) @7 line 16   [methId 4480769]
62 GsNMethod class >> _gsReturnToC               (envId 0) @1 line 1   [methId 4446721]
  [GsProcess 620691201]
topaz 1> topaz 1> [268 sz:0 cls: 68097 Boolean] true
topaz 1>
[Info]: Logging out at 03/28/13 09:56:37 CET


I hope this can help,

                Dario

Dear Dario

> topaz > exec iferr 1 : where
> ==> 1 AbstractException >> _signalWith:             (envId 0) @6 line 25   [methId 4459777]
> 2 AbstractException class >> signal             (envId 0) @3 line 5   [methId 4371457]
> 3 Object >> halt                                (envId 0) @2 line 5   [methId 3530241]

Means you have a “self halt” or similar in:


Best
        -Tobias

Dario,

It looks like the standard seaside error handling mechanism is not on the stack when serving up the filelibrary requests ...

This makes sense at one level, because you are not producing html, so you really cannot insert a seaside debugger in the request chain .... so handling a halt here doesn't make sense either because the only way to handle a halt correctly is to have a debugger pop up with a developer driving ...

Of course, with GemStone, since we can snap off continuations, but you have to be able safely _commit_ the continuations for that to work ... GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: is on the stack and there _is_ an Error handler there which is the "last chance" handler for Seaside errors. In the case of error, an internal error handler is called and the error is logged to the gem log and processing is "safely" continued... if we were to hard-wire a Halt handler at this point it would interfere with normal debugging activities...

To handle production Halts raised from the Seaside framework or below, we'd have to add a pluggable handler (like WAExceptionHandler) that would snap off continuations on a Halt and then resume execution at a point higher up the stack to cover non-session-related Halts.

As I look at this the proper place to install a "last chance Halt handler" is in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: , inside the transactionMutex ... it would be safe to catch a Halt at that point, snap off a continuation and add it the Object Log, with the expectation that the ensuing commit would preserve the continuation ...

A generic mechanism that was safe under all conditions would take a bit of work to put together, but if you were willing to hand edit GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock:, you could simply add a Halt handler that simply logged the halt stack to the gem log and then did a resume ... which would probably help you isolate your issue ...

A continuation could be snapped off as well for debugging using DebuggerLogEntry>>createContinuationLabeled: and #addToLog, but this takes just a bit more work to get right...

Dale

----- Original Message -----
| From: "Dario Trussardi" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, March 28, 2013 2:13:51 AM
| Subject: Re: [GS/SS Beta] Gem go down for WAFileLibrary error
|
| Dale,
|
| > embedded...
| >
| > ----- Original Message -----
| > | From: "Dario Trussardi" <[hidden email]>
| > | To: "GemStone Seaside beta discussion" <[hidden email]>
| > | Sent: Saturday, March 23, 2013 5:15:14 AM
| > | Subject: Re: [GS/SS Beta] Gem go down for WAFileLibrary error
| > |
| > | Ciao, Dale
| > |
| > | As i write in old e-mail:
| > |
| > | the halt is only for understand.
| > |
| > | I can create a styleBaseCss with dynamic code ( it's not elegant ? )
| > | and it
| > | can go into error.
| > |
| > | For example:
| > |
| > |
| > | styleBaseCss
| > |  
| > |     ^'
| > |   .colorBaseSctLcn{
| > |   color: green;
| > |   }' ,
| > |
| > | self defineOtherStyle,
| > |
| > | '.colorYellow{
| > |   color: yellow;
| > |   }'
| > |
| > |
| > | Now the defineOtherStyle method   had dynamically  some style and
| > | when
| > | execute can erase some error - exception.
| > |
| > | It's managed by the system or causing the down of the gem ?
| > |
| > | If i right understand the halt  at this level is not managed by the
| > | system
| > | and cause the down of the gem.
| > |
| > | OK, the first solution to prevent the down of the gem,  is to don't use
| > | dynamic method into WALibrary subclass definition,
| > |
| > | but it could be a possibility also in production system ?
| > |
| > | Thanks,
| > |
| > | Dario
| > |
| >
| > There _SHOULD_ be an error handler fairly high up the stack that is
| > intended to handle Errors ... Could you reproduce the problem in your
| > sandbox and provide a copy of the gemstone stack ... there must be a path
| > through the code that isn't protected ...
|
| The log relative o the gem who handled the request with the error report:
|
|
|  _____________________________________________________________________________
| |             GemStone/S64 Object-Oriented Data Management System
| |             |
| |                    Copyright (C) VMware, Inc. 1986-2012
| |                    |
| |                            All rights reserved.
| |                            |
| |                           Covered by U.S Patents:
| |                           |
| |            6,256,637 Transactional virtual machine architecture
| |            |
| |              6,360,219 Object queues with concurrent updating
| |              |
| |                  6,567,905 Generational Garbage Collector.
| |                  |
| | 6,681,226 Selective Pessimistic Locking for a Concurrently Updateable
| | Database
| +-----------------------------------------------------------------------------+
| |    PROGRAM: topaz, Linear GemStone Interface (Linked Session)
| |    |
| |    VERSION: 3.1.0.2, Beta  Wed Nov 28 16:23:21 2012
| |    |
| |      BUILD: gss64_3_1_0_x_branch-29651
| |      |
| |  BUILT FOR: x86-64 (Linux)
| |  |
| |       MODE: 64 bit
| |       |
| | RUNNING ON: 2-CPU monviso x86_64 (Linux 3.2.0-38-generic #61-Ubuntu SMP Tue
| | |
| | Feb 19 12:18:21 UTC 2013) 2002MB
| | |
| | PROCESS ID: 9228      DATE: 03/28/13 09:47:31 CET
| | |
| |   USER IDS: REAL=dario (1000) EFFECTIVE=dario (1000)
| |   |
|  _____________________________________________________________________________
| |   GEMSTONE_GLOBAL_DIR = /DTRDataBase/opt3102/gemstone
| |   |
| |_____________________________________________________________________________|
| neither .topazini nor $HOME/.topazini were found
| topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz> topaz>
| topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 851/851
| [Info]: libssl-3.1.0.2-64.so: loaded
| [Info]: User ID: DataCurator
| [Info]: Repository: working
| [Info]: Session ID: 4
| [Info]: GCI Client Host: <Linked>
| [Info]: Page server PID: -1
| [Info]: Login Time: 03/28/13 09:47:31.566 CET
| [Info]: libicudata-3.1.0.2-64.so: loaded
| [Info]: libicuuc-3.1.0.2-64.so: loaded
| [Info]: libicui18n-3.1.0.2-64.so: loaded
| Gave this VM preference for OOM killer, Wrote to /proc/9228/oom_score_adj
| value 250
| [03/28/13 09:47:31.638 CET]
|   gci login: currSession 1 rpc gem processId -1 OOB keep-alive interval -1
| successful login
| topaz 1> topaz 1> topaz 1> topaz 1> [474610177 sz:5 cls: 135169 GsFile]
| aGsFile
| topaz 1> topaz 1> topaz 1> topaz 1> daemon Server started on port 9011
| -----------------------------------------------------
| GemStone: Error         Nonfatal
| a Halt occurred (error 2709)
| Error Category: 231169 [GemStone] Number: 2709  Arg Count: 1 Context :
| 620691201 exception : 620691457
| Arg 1: [20 sz:0 cls: 76289 UndefinedObject] nil
| topaz > exec iferr 1 : where
| ==> 1 AbstractException >> _signalWith:             (envId 0) @6 line 25
| [methId 4459777]
| 2 AbstractException class >> signal             (envId 0) @3 line 5   [methId
| 4371457]
| 3 Object >> halt                                (envId 0) @2 line 5   [methId
| 3530241]
| 4 DTRFileLibrary >> styleBaseCss                (envId 0) @2 line 3   [methId
| 607109377]
| 5 WAFileLibrary >> documentOf:                  (envId 0) @2 line 2   [methId
| 139530497]
| 6 [] in  WAFileLibrary >> handle:               (envId 0) @4 line 20
| [methId 154888449]
| 7 WARequestContext >> respond:                  (envId 0) @3 line 4   [methId
| 140762881]
| 8 WAFileLibrary >> handle:                      (envId 0) @16 line 17
| [methId 139531265]
| 9 WAAbstractFileLibrary class >> handle:        (envId 0) @3 line 2   [methId
| 139561217]
| 10 WAFileHandler >> responseForContext:          (envId 0) @21 line 15
| [methId 140190977]
| 11 WAFileHandler >> handleFiltered:              (envId 0) @2 line 2
| [methId 140190209]
| 12 [] in  WARequestHandler >> handle:            (envId 0) @3 line 4
| [methId 156260609]
| 13 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 14 WADynamicVariable class >> use:during:        (envId 0) @2 line 4
| [methId 139584513]
| 15 [] in  WARequestContext >> push:during:       (envId 0) @2 line 5
| [methId 156247041]
| 16 ExecBlock >> ensure:                          (envId 0) @2 line 12
| [methId 3706625]
| 17 WARequestContext >> push:during:              (envId 0) @3 line 6
| [methId 140760577]
| 18 WARequestHandler >> handle:                   (envId 0) @2 line 4
| [methId 140777217]
| 19 WADispatcher >> handleFiltered:named:         (envId 0) @3 line 5
| [methId 140712449]
| 20 WADispatcher >> handleFiltered:               (envId 0) @8 line 6
| [methId 140710145]
| 21 [] in  WARequestHandler >> handle:            (envId 0) @3 line 4
| [methId 156260609]
| 22 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 23 WADynamicVariable class >> use:during:        (envId 0) @2 line 4
| [methId 139584513]
| 24 [] in  WARequestContext >> push:during:       (envId 0) @2 line 5
| [methId 156247041]
| 25 ExecBlock >> ensure:                          (envId 0) @2 line 12
| [methId 3706625]
| 26 WARequestContext >> push:during:              (envId 0) @3 line 6
| [methId 140760577]
| 27 WARequestHandler >> handle:                   (envId 0) @2 line 4
| [methId 140777217]
| 28 [] in  WAServerAdaptor >> handleRequest:      (envId 0) @3 line 4
| [methId 155661057]
| 29 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 30 WAServerAdaptor >> handleRequest:             (envId 0) @2 line 5
| [methId 140271617]
| 31 WAServerAdaptor >> handle:                    (envId 0) @2 line 4
| [methId 140276481]
| 32 [] in  WAServerAdaptor >> process:            (envId 0) @2 line 6
| [methId 155664129]
| 33 ExecBlock >> ensure:                          (envId 0) @2 line 12
| [methId 3706625]
| 34 WAServerAdaptor >> process:                   (envId 0) @4 line 7
| [methId 140274177]
| 35 [] in  WAFastCGIAdaptor >> process:           (envId 0) @2 line 6
| [methId 185098753]
| 36 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
| (envId 0) @2 line 11   [methId 150141441]
| 37 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 38 [] in  GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
| (envId 0) @11 line 12   [methId 138220801]
| 39 ExecBlock >> ensure:                          (envId 0) @2 line 12
| [methId 3706625]
| 40 TransientRecursionLock >> critical:           (envId 0) @11 line 12
| [methId 29283585]
| 41 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: (envId
| 0) @3 line 5   [methId 135530497]
| 42 [] in  GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock:
| (envId 0) @6 line 9   [methId 138221569]
| 43 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 44 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: (envId 0)
| @2 line 17   [methId 135530753]
| 45 WAFastCGIAdaptor >> process:                  (envId 0) @3 line 4
| [methId 182936065]
| 46 [] in  WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4
| [methId 185098241]
| 47 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 48 WAFastCGIAdaptor >> answerResponderRole:      (envId 0) @2 line 5
| [methId 182935809]
| 49 FSResponderRole >> answer                     (envId 0) @3 line 4
| [methId 182140673]
| 50 FSRole >> handleConnection                    (envId 0) @3 line 5
| [methId 182137601]
| 51 FSConnection >> unsafeServe                   (envId 0) @5 line 8
| [methId 181664257]
| 52 [] in  FSConnection >> safeServe              (envId 0) @2 line 8
| [methId 186241281]
| 53 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 54 [] in  FSConnection >> safeServe              (envId 0) @2 line 9
| [methId 186288385]
| 55 ExecBlock >> on:do:                           (envId 0) @3 line 42
| [methId 3737345]
| 56 [] in  FSConnection >> safeServe              (envId 0) @2 line 12
| [methId 184832001]
| 57 ExecBlock >> ensure:                          (envId 0) @2 line 12
| [methId 3706625]
| 58 FSConnection >> safeServe                     (envId 0) @2 line 15
| [methId 181660673]
| 59 FSConnection >> serve                         (envId 0) @2 line 4
| [methId 181668097]
| 60 [] in  FSSocketServer >> listen:              (envId 0) @3 line 15
| [methId 185155585]
| 61 GsProcess >> _start                           (envId 0) @7 line 16
| [methId 4480769]
| 62 GsNMethod class >> _gsReturnToC               (envId 0) @1 line 1
| [methId 4446721]
|   [GsProcess 620691201]
| topaz 1> topaz 1> [268 sz:0 cls: 68097 Boolean] true
| topaz 1>
| [Info]: Logging out at 03/28/13 09:56:37 CET
|
|
| I hope this can help,
|
| Dario
|
|