Smalltalk › Gemtalk › GLASS

Take advantage of the largest STIC '12 conference discounts by registering this week

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

111 messages Options

123456

Dale Henrichs

Re: Weird WASession behavior

Lawrence,

One of the sticky wickets with GemStone is that classes are versioned. When you change a class definition (new instance variable, new superclass, etc.) you get a new version of a class.

The development environment (with autoMigrate enables) will automatically migrate all of your instances of the old class to the new class version, but direct references to classes from an object (like class variables or instance variables) are not fixed. References to classes in methods are automatically fixed up, because the reference is not directly to the class but to the association for the class....

In Smalltalk (and Seaside) it is a common practice to store a reference to a class in a class variable and in GemStone this can result in problems like you are seeing, so it is likely that something like this is going on ...

I suppose this behavior should be called out more prominently, but that doesn't help you;( right now.

To avoid this problem in the future you should store the name of the class and do a look up on demand (`Smalltalk at: #className` will work portably) or you can store the association for the class and return the value on access (`Smalltalk associationAt: #className` should be a portable way of of finding the association for the class which you can then store ...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Sunday, January 29, 2012 10:22:03 AM
| Subject: [GS/SS Beta] Weird WASession behavior
|
| Hello,
| I'm seeing behavior which I can't understand. I have a subclass of
| WASession which I
| use to store a reference to a user once the user logins into the
| system.
|
| I use a WATask for the login, like this:
|
| go
| | user component |
| self call: self userLoginView.
| (self userLoginView user)
| ifTrue: [
| component := self firstComponentToDisplayForUser: self
| userLoginView user.
| [ component notNil ]
| whileTrue: [
| self call: component.
| component := component nextComponentToBeDisplayed ] ]
|
| Now, all of my users are stored on the class side of my User class
| in an RcIdentityKeyDictionary.
|
| I also have a subclass of WASession, which I have added a "user"
| instance variable to. Logging into
| the system pretty much entails setting that user instance variable on
| the session class.
|
| Now, for the strange behavior. When I log in, I get a user object
| that is empty of all of its data.
| The user in the RcIdentityKeyDictionary looks fine and I swear I'm
| returning it, upon lookup.
|
| Could something be holding onto an old instance of the user,
| through the session or task classes?
| I tried recycling the Gems but that did not make any difference. I
| did make some changes to the
| login task. I tried rerunning its initialize method but that didn't
| seem to help.
|
| Any ideas? I'm kind of stumped.
|
| Thanks,
|
| Larry

Larry Kellogg

Re: Weird WASession behavior

Dale,

On Jan 29, 2012, at 4:20 PM, Dale Henrichs wrote:

> Lawrence,
>
> One of the sticky wickets with GemStone is that classes are versioned. When you change a class definition (new instance variable, new superclass, etc.) you get a new version of a class.
>

Yes, I know, I have struggled with this issue in the past but have been away from it for a few years. I remember having to write
all kinds of migration scripts in my last job, and, when the system became huge, it was impossible to get enough downtime and cpu
cycles to migrate all of the objects. So, eventually, objects became cast in concrete, with no shape changes possible.

> The development environment (with autoMigrate enables) will automatically migrate all of your instances of the old class to the new class version, but direct references to classes from an object (like class variables or instance variables) are not fixed. References to classes in methods are automatically fixed up, because the reference is not directly to the class but to the association for the class....
>

How can I tell if auto-migrate is enabled in my Gemstone environment? I hope it is, by default, for now.

> In Smalltalk (and Seaside) it is a common practice to store a reference to a class in a class variable and in GemStone this can result in problems like you are seeing, so it is likely that something like this is going on ...
>
> I suppose this behavior should be called out more prominently, but that doesn't help you;( right now.
>
> To avoid this problem in the future you should store the name of the class and do a look up on demand (`Smalltalk at: #className` will work portably) or you can store the association for the class and return the value on access (`Smalltalk associationAt: #className` should be a portable way of of finding the association for the class which you can then store ...
>

I will have to look at my code some more but I do not think I am storing a reference to the class (User) in a class variable, but instead , just
storing instances of the class User in the class variable (an RcIdentityKeyDictionary), with the key being a string. So, my instances should be auto-migrated if I change the
shape of the User object, right?

I think I hit a situation where the system was hanging onto the class of the login task, causing me problems. I don't quite know how that
happened, but I believe it was because I accidentally quoted out part of the initialize method on the login task so that it no longer worked correctly.

Regards,

Larry

Dale Henrichs

Re: Weird WASession behavior

Larry,

In GemTools autoMigrate is enabled. In topaz autoMigrate is not enabled. If you use GsDeployer to do your loads in topaz and GemTools, the GsDeployer will enable autoMigrate ...

GsDeployer has some batch load methods that work only under certain conditions (which explains why I haven't talked up GsDeployer that much:( ...

Recently, I have done some work on the migration process for upgrading ss3.gemstone.com and I think that it will be a good example of what things people need to concern themselves with when doing efficient system migrations.

Seaside itself holds onto the class when you register a component. If you have been modifying your component class you might need to re-register the component to refresh the class version.

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Sunday, January 29, 2012 2:33:32 PM
| Subject: Re: [GS/SS Beta] Weird WASession behavior
|
| Dale,
|
| On Jan 29, 2012, at 4:20 PM, Dale Henrichs wrote:
|
| > Lawrence,
| >
| > One of the sticky wickets with GemStone is that classes are
| > versioned. When you change a class definition (new instance
| > variable, new superclass, etc.) you get a new version of a class.
| >
|
| Yes, I know, I have struggled with this issue in the past but have
| been away from it for a few years. I remember having to write
| all kinds of migration scripts in my last job, and, when the system
| became huge, it was impossible to get enough downtime and cpu
| cycles to migrate all of the objects. So, eventually, objects became
| cast in concrete, with no shape changes possible.
|
| > The development environment (with autoMigrate enables) will
| > automatically migrate all of your instances of the old class to
| > the new class version, but direct references to classes from an
| > object (like class variables or instance variables) are not fixed.
| > References to classes in methods are automatically fixed up,
| > because the reference is not directly to the class but to the
| > association for the class....
| >
|
| How can I tell if auto-migrate is enabled in my Gemstone
| environment? I hope it is, by default, for now.
|
|
| > In Smalltalk (and Seaside) it is a common practice to store a
| > reference to a class in a class variable and in GemStone this can
| > result in problems like you are seeing, so it is likely that
| > something like this is going on ...
| >
| > I suppose this behavior should be called out more prominently, but
| > that doesn't help you;( right now.
| >
| > To avoid this problem in the future you should store the name of
| > the class and do a look up on demand (`Smalltalk at: #className`
| > will work portably) or you can store the association for the class
| > and return the value on access (`Smalltalk associationAt:
| > #className` should be a portable way of of finding the association
| > for the class which you can then store ...
| >
|
| I will have to look at my code some more but I do not think I am
| storing a reference to the class (User) in a class variable, but
| instead , just
| storing instances of the class User in the class variable (an
| RcIdentityKeyDictionary), with the key being a string. So, my
| instances should be auto-migrated if I change the
| shape of the User object, right?
|
| I think I hit a situation where the system was hanging onto the
| class of the login task, causing me problems. I don't quite know
| how that
| happened, but I believe it was because I accidentally quoted out part
| of the initialize method on the login task so that it no longer
| worked correctly.
|
| Regards,
|
| Larry
|
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Sunday, January 29, 2012 10:22:03 AM
| > | Subject: [GS/SS Beta] Weird WASession behavior
| > |
| > | Hello,
| > | I'm seeing behavior which I can't understand. I have a subclass
| > | of
| > | WASession which I
| > | use to store a reference to a user once the user logins into the
| > | system.
| > |
| > | I use a WATask for the login, like this:
| > |
| > | go
| > | | user component |
| > | self call: self userLoginView.
| > | (self userLoginView user)
| > | ifTrue: [
| > | component := self firstComponentToDisplayForUser: self
| > | userLoginView user.
| > | [ component notNil ]
| > | whileTrue: [
| > | self call: component.
| > | component := component nextComponentToBeDisplayed ] ]
| > |
| > | Now, all of my users are stored on the class side of my User
| > | class
| > | in an RcIdentityKeyDictionary.
| > |
| > | I also have a subclass of WASession, which I have added a
| > | "user"
| > | instance variable to. Logging into
| > | the system pretty much entails setting that user instance
| > | variable on
| > | the session class.
| > |
| > | Now, for the strange behavior. When I log in, I get a user
| > | object
| > | that is empty of all of its data.
| > | The user in the RcIdentityKeyDictionary looks fine and I swear
| > | I'm
| > | returning it, upon lookup.
| > |
| > | Could something be holding onto an old instance of the user,
| > | through the session or task classes?
| > | I tried recycling the Gems but that did not make any difference.
| > | I
| > | did make some changes to the
| > | login task. I tried rerunning its initialize method but that
| > | didn't
| > | seem to help.
| > |
| > | Any ideas? I'm kind of stumped.
| > |
| > | Thanks,
| > |
| > | Larry
|
|

Larry Kellogg

Re: Fatal Internal Notification from Gem

In reply to this post by Dale Henrichs

On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:

> Lawrence,
>
> I see that you have since solved your issues here, but I do want to clarify a few points.
>
> First off, in the stack below I can't tell which Seaside error handler you are using. Since you are running your Seaside instance on AWS, you need to be using an error handler that produces continuations for your errors. To determine the error handler, print the following expression:
>
> WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
> Running in AWS I would recommend that you use the WAGemStoneProductionErrorHandler (see [1] for options and details), since you don't want arbitrary users to be able to open inspectors on your server. When errors occur, the user is provided with feedback (that you can control) and a continuation is snapped off that you can debug from your development image[2].

Dale,
You know, it's funny, I set the error handler to the production one, like you said,

WAGemStoneProductionErrorHandler is returned from WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler, but, yet,
when the system throws a walkback, the nginx gateway goes down, and I do not get a continuation snapped off. Do I have to
do something else to enable that behavior?

Lawrence

>
> I didn't see an error handler on the stack so I am curious which error handler you are using.
>
> The undefined Swazoo variable is actually a bug[3] in the script. The most recent scripts (with this bugfix and other cleanups) can be found here[4].
>
> Dale
>
> [1] http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
> [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
> [3] http://code.google.com/p/glassdb/issues/detail?id=158
> [4] http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Monday, January 16, 2012 12:21:36 PM
> | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> |
> | James,
> | Well, I think I traced the crash to the fact that I has mistakenly
> | reintroduced some code that was trying to call out to Cloudfork.
> | I removed that code and everything seems to be running better now,
> | but it is a little too early to tell, for sure.
> |
> | Looking through the log files, and in particular, a Swazoo server
> | log file, I guess this
> | walkback brought down the Gem. Is this of any help?
> |
> | Thanks for the tips with regards to writing a little shell script
> | to restart my Ges.
> | I'll do that. With all the moving parts, I'm amazed that I have
> | gotten as much up
> | and running as I have. ;-)
> |
> | Regards,
> |
> | Larry
> |
> |
> |
> |
> | The object with object ID 81065893475386368 does not exist.
> | Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1 Context :
> | 361105409
> | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
> | 81065893475386368
> |
> | Now executing the following command saved from "iferr 1":
> | where
> | ==> 1 GsProcess class >> installPartialContinuation:atLevel:value: @2
> | line 1 [GsMethod 4487425]
> | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod 212791041]
> | 3 WAPartialContinuation >> valueWithPossibleArguments: @2 line 2
> | [GsMethod 218326273]
> | 4 ComplexBlock in WAComponent >> show:onAnswer:delegation: @7 line 7
> | [GsMethod 194749185]
> | 5 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments: @12
> | line 8 [GsMethod 116163585]
> | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2 [GsMethod
> | 194735873]
> | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod 194731009]
> | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
> | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2 [GsMethod
> | 278171137]
> | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn: @53 line 47
> | [GsMethod 259119617]
> | 11 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments: @6
> | line 4 [GsMethod 116163585]
> | 12 WAActionCallback >> evaluateWithArgument: @3 line 2 [GsMethod
> | 176951297]
> | 13 WACallback >> evaluateWithFieldValues: @5 line 2 [GsMethod
> | 177495553]
> | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line 10
> | [GsMethod 177951489]
> | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
> | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod 177951489]
> | 17 ComplexBlock in WAActionPhaseContinuation >> runCallbacks @7 line
> | 4 [GsMethod 202613505]
> | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 21 WARenderLoopContinuation >> withNotificationHandlerDo: @3 line 2
> | [GsMethod 202608385]
> | 22 ComplexVCBlock in WAActionPhaseContinuation >> runCallbacks @8
> | line 3 [GsMethod 202613505]
> | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | [GsMethod 2304001]
> | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6 [GsMethod
> | 202613505]
> | 26 WAActionPhaseContinuation >> handleRequest @1 line 2 [GsMethod
> | 202614017]
> | 27 ComplexBlock in WASessionContinuation >> basicValue @3 line 2
> | [GsMethod 202625537]
> | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7 line 3
> | [GsMethod 202627073]
> | 32 WASessionContinuation >> basicValue @4 line 2 [GsMethod
> | 202625537]
> | 33 WASessionContinuation >> value @3 line 5 [GsMethod 202623745]
> | 34 WASession >> handleFiltered: @14 line 10 [GsMethod 202205441]
> | 35 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | 176192513]
> | 36 ComplexBlock in WADeprecatedToolFilter >> handleFiltered: @3 line
> | 2 [GsMethod 203213313]
> | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3 [GsMethod
> | 203213313]
> | 41 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | 176192513]
> | 42 ComplexBlock in WATimingToolFilter >> handleFiltered: @4 line 3
> | [GsMethod 203208449]
> | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 45 WATimingToolFilter >> handleFiltered: @8 line 4 [GsMethod
> | 203208449]
> | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4 [GsMethod
> | 178568961]
> | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 50 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | 177805825]
> | 51 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | [GsMethod 176176129]
> | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 54 WARequestContext >> push:during: @7 line 6 [GsMethod 176176129]
> | 55 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | 56 WASession >> handle: @10 line 11 [GsMethod 202210561]
> | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod 176153857]
> | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod 176155137]
> | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod 176146945]
> | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod 202644225]
> | 61 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | 176192513]
> | 62 ComplexBlock in WAExceptionFilter >> handleFiltered: @3 line 3
> | [GsMethod 178300417]
> | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line 3
> | [GsMethod 177803521]
> | 67 WAExceptionHandler class >> handleExceptionsDuring:context: @2
> | line 2 [GsMethod 177810177]
> | 68 WAExceptionFilter >> handleFiltered: @4 line 3 [GsMethod
> | 178300417]
> | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4 [GsMethod
> | 178568961]
> | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 73 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | 177805825]
> | 74 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | [GsMethod 176176129]
> | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 77 WARequestContext >> push:during: @7 line 6 [GsMethod 176176129]
> | 78 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | 79 WADispatcher >> handleFiltered:named: @7 line 5 [GsMethod
> | 179090945]
> | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod 179087617]
> | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4 [GsMethod
> | 178568961]
> | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 85 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | 177805825]
> | 86 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | [GsMethod 176176129]
> | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 89 WARequestContext >> push:during: @7 line 6 [GsMethod 176176129]
> | 90 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4 line 4
> | [GsMethod 176816641]
> | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 95 WAServerAdaptor >> handleRequest: @6 line 5 [GsMethod 176816641]
> | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod 176817921]
> | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6 [GsMethod
> | 176817153]
> | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod 176817153]
> | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line 6
> | [GsMethod 209224705]
> | 102 ComplexBlock in GRGemStonePlatform >>
> | seasideProcessRequestWithRetry:resultBlock: @12 line 11 [GsMethod
> | 175179265]
> | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 104 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 106 ComplexVCBlock in GRGemStonePlatform >>
> | seasideProcessRequestWithRetry:resultBlock: @18 line 12 [GsMethod
> | 175179265]
> | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | [GsMethod 2304001]
> | 109 TransientRecursionLock >> critical: @15 line 8 [GsMethod
> | 21159937]
> | 110 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
> | @39 line 5 [GsMethod 175179265]
> | 111 ComplexBlock in GRGemStonePlatform >>
> | seasideProcessRequest:adaptor:resultBlock: @7 line 9 [GsMethod
> | 175179521]
> | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 113 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 115 GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock:
> | @32 line 17 [GsMethod 175179521]
> | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod 209224705]
> | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod 203002625]
> | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod 203002113]
> | 119 URIResolution >> visitResource: @1 line 2 [GsMethod 185922561]
> | 120 ComplexBlock in URIResolution >> visitChildrenOf:advancing: @10
> | line 7 [GsMethod 185924097]
> | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
> | 122 URIResolution >> visitChildrenOf:advancing: @15 line 5
> | [GsMethod 185924097]
> | 123 URIResolution >> resolveTransparentComposite: @2 line 2
> | [GsMethod 185924609]
> | 124 URIResolution >> resolveServerRoot: @1 line 2 [GsMethod
> | 185920257]
> | 125 ServerRootComposite >> helpResolve: @1 line 2 [GsMethod
> | 186024449]
> | 126 URIResolution >> visitResource: @1 line 2 [GsMethod 185922561]
> | 127 URIResolution class >> resolveRequest:startingAt: @3 line 2
> | [GsMethod 185802241]
> | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod 186053889]
> | 129 ComplexBlock in HTTPConnection >> produceResponseFor: @9 line 5
> | [GsMethod 185650433]
> | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 131 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 133 HTTPConnection >> produceResponseFor: @23 line 6 [GsMethod
> | 185650433]
> | 134 HTTPConnection >> getAndDispatchMessages @9 line 9 [GsMethod
> | 185651201]
> | 135 ComplexBlock in HTTPConnection >> interact @7 line 6 [GsMethod
> | 185651457]
> | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 137 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 139 ComplexVCBlock in HTTPConnection >> interact @12 line 9
> | [GsMethod 185651457]
> | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
> | [GsMethod 116163329]
> | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8
> | [GsMethod 116163329]
> | 144 ComplexVCBlock in HTTPConnection >> interact @19 line 13
> | [GsMethod 185651457]
> | 145 HTTPConnection >> interact @26 line 18 [GsMethod 185651457]
> | 146 HTTPServer >> acceptConnection @14 line 13 [GsMethod 186054145]
> | 147 ComplexBlock in HTTPServer >> start @13 line 6 [GsMethod
> | 186054913]
> | 148 ComplexBlock in BlockClosure >> repeat @3 line 5 [GsMethod
> | 19138561]
> | 149 ComplexVCBlock in HTTPServer >> start @14 line 6 [GsMethod
> | 186054913]
> | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod 4501249]
> | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
> | [GsProcess 361105409]
> | topaz 1> GemStone Smalltalk Compiler Errors:
> | GemToGemAnnouncement uninstallStaticHandler.
> | System beginTransaction.
> | (ObjectLogEntry
> | fatal: '8080: topaz exit'
> | object:
> | 'port: ', Swazoo printString, ' ',
> | * ^1
> | *******
> | 'pid: ', (System gemVersionReport at: 'processId')
> | printString) addToLog.
> | System commitTransaction.
> |
> | 1: [1031] undefined symbol
> |
> | Now executing the following command saved from "iferr 1":
> | where
> | Stack is not active
> | topaz 1> Sun Jan 15 18:16:58 UTC 2012
> | Sun Jan 15 18:16:58 UTC 2012
> |
> | hostcalldebugger invoked in process 1590, at 01/15/2012 06:16:58
> | PM.598 UTC
> | notifying stone of fatal error
> |
> | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
> |
> |
> | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
> |
> | > Larry,
> | >
> | > GemStone has a lot of moving parts and it can be confusing to tell
> | > which piece is involved. In your case the stone log reports that a
> | > gem (with PID 1590) crashed. When the gem was started, was there a
> | > script that redirected output to a file? If so, do you have that
> | > file available?
> | >
> | > A typical explanation for this sort of problem is running out of
> | > temporary object cache in a gem. Doing so will cause the gem to
> | > crash and not be able to report anything to the object log (as it
> | > would do for a non-fatal error). Depending on what the user
> | > clicked on, your code may have taken a different path, or tried to
> | > load different objects.
> | >
> | > Auto-restarting a gem is typically done with a shell script (e.g.,
> | > bash). You can have a loop that checks for the existence of a file
> | > and if it is present (or absent, depending on your preference),
> | > then start the gem. When the gem crashes, control will return to
> | > the script and the loop will continue. If you want to stop the
> | > loop you can manually remove (or create) the flag file (or just
> | > manually kill the process running the shell script).
> | >
> | > -James
> | >
> | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
> | >
> | >> Hello,
> | >> So, my GLASS server has been running for days on Amazon's service.
> | >> I logged in many
> | >> times a day, and worked with it, no problems.
> | >>
> | >> I gave the server information to someone else to try, and the
> | >> server crashed with the
> | >> following error: (from the seaside.log)
> | >>
> | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with processId
> | >> 1384 is now the Symbol Creation Gem.
> | >> Session 3 with processId 1383 is now the Admin Gem.
> | >>
> | >> Session 4 with processId 1382 is now the Page Reclaim Gem for
> | >> extents 0 through 0.
> | >>
> | >> --- 01/15/2012 06:16:58 PM UTC ---
> | >> Fatal Internal Error Notification from Gem, user = DataCurator
> | >> Session = 6
> | >> Gem hostName = localhost , Gem processId = 1590,
> | >> current CommitRecord = 2376
> | >>
> | >> =======================================
> | >>
> | >> Any idea on how I can debug something like this? I have no idea
> | >> what happened.
> | >> There are no walkbacks in the Debug option on the Gemtools
> | >> launcher. All I know is
> | >> that the user was clicking around with FIrefox and it crashed.
> | >>
> | >> Furthermore, is there an easy way for me to restart my Gems once
> | >> they go down?
> | >> I start them with this:
> | >>
> | >> WAGemStoneRunSeasideGems default
> | >> name: 'Swazoo';
> | >> adaptorClass: WAGsSwazooAdaptor;
> | >> ports: #(8080).
> | >> WAGemStoneRunSeasideGems restartGems.
> | >>
> | >> After the crash, I restarted the Gems and the server process was
> | >> fine.
> | >>
> | >> Regards,
> | >>
> | >> Larry
> | >
> |
> |

Larry Kellogg

Re: Running SeasideGems, confusion

In reply to this post by Dale Henrichs

>
> |
> | I have noticed kind of a funny thing with regards to sessions.
> | After logging out, and going back to my login task, sometimes a
> | valid login attempt will just clear the fields and do nothing.
> | Hitting the new session button fixes this issue. Maybe I'm not
> | resetting something properly.
>
> I think I need a more explicit example of the problem to understand what might be happening.
>

Dale,
Well, I think it is the session time out. Like I mentioned, I have a login task for my
app. If I log in, and work, log out, I can log back in immediately without the screen having
to be refreshed and generating a new session. But, if I am outside the time out period, 20 minutes,
currently, then I have to hit the page a second time to log in.

Do you think it is working as designed?

Lawrence

Dale Henrichs

Re: Running SeasideGems, confusion

Okay, I think I understand now ... I have seen the same behavior on SS3 ... when the session times out, the current page is refreshed instead of taking you all the way back to the default page ... I noticed this in SS3 and thought "that is a nice feature, because being taken back to the home page when timing out on a project page is quite annoying"...Perhaps it is a bug instead of a feature ...

I haven't tracked that down to tell whether it is a feature or a bug ...

Has anyone else noticed this behavior?

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Sunday, February 5, 2012 7:51:44 PM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| >
| > |
| > | I have noticed kind of a funny thing with regards to sessions.
| > | After logging out, and going back to my login task, sometimes a
| > | valid login attempt will just clear the fields and do nothing.
| > | Hitting the new session button fixes this issue. Maybe I'm not
| > | resetting something properly.
| >
| > I think I need a more explicit example of the problem to understand
| > what might be happening.
| >
|
| Dale,
| Well, I think it is the session time out. Like I mentioned, I have
| a login task for my
| app. If I log in, and work, log out, I can log back in immediately
| without the screen having
| to be refreshed and generating a new session. But, if I am outside
| the time out period, 20 minutes,
| currently, then I have to hit the page a second time to log in.
|
| Do you think it is working as designed?
|
| Lawrence
|
|

Dale Henrichs

Re: Fatal Internal Notification from Gem

In reply to this post by Larry Kellogg

Lawrence,

Are you getting an error message in your log file?

Perhaps you are getting some secondary errors during error handling that is defeating the normal error handling process?

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Sunday, February 5, 2012 7:43:34 PM
| Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
|
|
| On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
|
| > Lawrence,
| >
| > I see that you have since solved your issues here, but I do want to
| > clarify a few points.
| >
| > First off, in the stack below I can't tell which Seaside error
| > handler you are using. Since you are running your Seaside instance
| > on AWS, you need to be using an error handler that produces
| > continuations for your errors. To determine the error handler,
| > print the following expression:
| >
| > WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
| > Running in AWS I would recommend that you use the
| > WAGemStoneProductionErrorHandler (see [1] for options and
| > details), since you don't want arbitrary users to be able to open
| > inspectors on your server. When errors occur, the user is provided
| > with feedback (that you can control) and a continuation is snapped
| > off that you can debug from your development image[2].
|
| Dale,
| You know, it's funny, I set the error handler to the production
| one, like you said,
|
| WAGemStoneProductionErrorHandler is returned from WAAdmin
| applicationExceptionHandlingDefaults at: #exceptionHandler, but,
| yet,
| when the system throws a walkback, the nginx gateway goes down, and I
| do not get a continuation snapped off. Do I have to
| do something else to enable that behavior?
|
| Lawrence
|
|
|
| >
| > I didn't see an error handler on the stack so I am curious which
| > error handler you are using.
| >
| > The undefined Swazoo variable is actually a bug[3] in the script.
| > The most recent scripts (with this bugfix and other cleanups) can
| > be found here[4].
| >
| > Dale
| >
| > [1] http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
| > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
| > [3] http://code.google.com/p/glassdb/issues/detail?id=158
| > [4] http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, January 16, 2012 12:21:36 PM
| > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
| > |
| > | James,
| > | Well, I think I traced the crash to the fact that I has
| > | mistakenly
| > | reintroduced some code that was trying to call out to
| > | Cloudfork.
| > | I removed that code and everything seems to be running better
| > | now,
| > | but it is a little too early to tell, for sure.
| > |
| > | Looking through the log files, and in particular, a Swazoo
| > | server
| > | log file, I guess this
| > | walkback brought down the Gem. Is this of any help?
| > |
| > | Thanks for the tips with regards to writing a little shell
| > | script
| > | to restart my Ges.
| > | I'll do that. With all the moving parts, I'm amazed that I have
| > | gotten as much up
| > | and running as I have. ;-)
| > |
| > | Regards,
| > |
| > | Larry
| > |
| > |
| > |
| > |
| > | The object with object ID 81065893475386368 does not exist.
| > | Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1
| > | Context :
| > | 361105409
| > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
| > | 81065893475386368
| > |
| > | Now executing the following command saved from "iferr 1":
| > | where
| > | ==> 1 GsProcess class >>
| > | installPartialContinuation:atLevel:value: @2
| > | line 1 [GsMethod 4487425]
| > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
| > | 212791041]
| > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2 line 2
| > | [GsMethod 218326273]
| > | 4 ComplexBlock in WAComponent >> show:onAnswer:delegation: @7
| > | line 7
| > | [GsMethod 194749185]
| > | 5 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments:
| > | @12
| > | line 8 [GsMethod 116163585]
| > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
| > | [GsMethod
| > | 194735873]
| > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod 194731009]
| > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
| > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
| > | [GsMethod
| > | 278171137]
| > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn: @53
| > | line 47
| > | [GsMethod 259119617]
| > | 11 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments:
| > | @6
| > | line 4 [GsMethod 116163585]
| > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
| > | [GsMethod
| > | 176951297]
| > | 13 WACallback >> evaluateWithFieldValues: @5 line 2 [GsMethod
| > | 177495553]
| > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line 10
| > | [GsMethod 177951489]
| > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
| > | 177951489]
| > | 17 ComplexBlock in WAActionPhaseContinuation >> runCallbacks @7
| > | line
| > | 4 [GsMethod 202613505]
| > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 21 WARenderLoopContinuation >> withNotificationHandlerDo: @3 line
| > | 2
| > | [GsMethod 202608385]
| > | 22 ComplexVCBlock in WAActionPhaseContinuation >> runCallbacks @8
| > | line 3 [GsMethod 202613505]
| > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod 2304001]
| > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
| > | [GsMethod
| > | 202613505]
| > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
| > | [GsMethod
| > | 202614017]
| > | 27 ComplexBlock in WASessionContinuation >> basicValue @3 line 2
| > | [GsMethod 202625537]
| > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7 line 3
| > | [GsMethod 202627073]
| > | 32 WASessionContinuation >> basicValue @4 line 2 [GsMethod
| > | 202625537]
| > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
| > | 202623745]
| > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
| > | 202205441]
| > | 35 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | 176192513]
| > | 36 ComplexBlock in WADeprecatedToolFilter >> handleFiltered: @3
| > | line
| > | 2 [GsMethod 203213313]
| > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
| > | [GsMethod
| > | 203213313]
| > | 41 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | 176192513]
| > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered: @4 line
| > | 3
| > | [GsMethod 203208449]
| > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 45 WATimingToolFilter >> handleFiltered: @8 line 4 [GsMethod
| > | 203208449]
| > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | [GsMethod
| > | 178568961]
| > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 50 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
| > | 177805825]
| > | 51 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | [GsMethod 176176129]
| > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | 176176129]
| > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
| > | 56 WASession >> handle: @10 line 11 [GsMethod 202210561]
| > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod 176153857]
| > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
| > | 176155137]
| > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
| > | 176146945]
| > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
| > | 202644225]
| > | 61 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | 176192513]
| > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered: @3 line 3
| > | [GsMethod 178300417]
| > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line 3
| > | [GsMethod 177803521]
| > | 67 WAExceptionHandler class >> handleExceptionsDuring:context: @2
| > | line 2 [GsMethod 177810177]
| > | 68 WAExceptionFilter >> handleFiltered: @4 line 3 [GsMethod
| > | 178300417]
| > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | [GsMethod
| > | 178568961]
| > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 73 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
| > | 177805825]
| > | 74 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | [GsMethod 176176129]
| > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | 176176129]
| > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
| > | 79 WADispatcher >> handleFiltered:named: @7 line 5 [GsMethod
| > | 179090945]
| > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
| > | 179087617]
| > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | [GsMethod
| > | 178568961]
| > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 85 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
| > | 177805825]
| > | 86 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | [GsMethod 176176129]
| > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | 176176129]
| > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
| > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4 line 4
| > | [GsMethod 176816641]
| > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 95 WAServerAdaptor >> handleRequest: @6 line 5 [GsMethod
| > | 176816641]
| > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod 176817921]
| > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
| > | [GsMethod
| > | 176817153]
| > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod 176817153]
| > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line 6
| > | [GsMethod 209224705]
| > | 102 ComplexBlock in GRGemStonePlatform >>
| > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
| > | [GsMethod
| > | 175179265]
| > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 104 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 106 ComplexVCBlock in GRGemStonePlatform >>
| > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
| > | [GsMethod
| > | 175179265]
| > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod 2304001]
| > | 109 TransientRecursionLock >> critical: @15 line 8 [GsMethod
| > | 21159937]
| > | 110 GRGemStonePlatform >>
| > | seasideProcessRequestWithRetry:resultBlock:
| > | @39 line 5 [GsMethod 175179265]
| > | 111 ComplexBlock in GRGemStonePlatform >>
| > | seasideProcessRequest:adaptor:resultBlock: @7 line 9 [GsMethod
| > | 175179521]
| > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 113 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 115 GRGemStonePlatform >>
| > | seasideProcessRequest:adaptor:resultBlock:
| > | @32 line 17 [GsMethod 175179521]
| > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
| > | 209224705]
| > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod 203002625]
| > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
| > | 203002113]
| > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | 185922561]
| > | 120 ComplexBlock in URIResolution >> visitChildrenOf:advancing:
| > | @10
| > | line 7 [GsMethod 185924097]
| > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | 122 URIResolution >> visitChildrenOf:advancing: @15 line 5
| > | [GsMethod 185924097]
| > | 123 URIResolution >> resolveTransparentComposite: @2 line 2
| > | [GsMethod 185924609]
| > | 124 URIResolution >> resolveServerRoot: @1 line 2 [GsMethod
| > | 185920257]
| > | 125 ServerRootComposite >> helpResolve: @1 line 2 [GsMethod
| > | 186024449]
| > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | 185922561]
| > | 127 URIResolution class >> resolveRequest:startingAt: @3 line 2
| > | [GsMethod 185802241]
| > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod 186053889]
| > | 129 ComplexBlock in HTTPConnection >> produceResponseFor: @9 line
| > | 5
| > | [GsMethod 185650433]
| > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 131 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 133 HTTPConnection >> produceResponseFor: @23 line 6 [GsMethod
| > | 185650433]
| > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
| > | [GsMethod
| > | 185651201]
| > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
| > | [GsMethod
| > | 185651457]
| > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 137 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line 9
| > | [GsMethod 185651457]
| > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
| > | [GsMethod 116163329]
| > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8
| > | [GsMethod 116163329]
| > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line 13
| > | [GsMethod 185651457]
| > | 145 HTTPConnection >> interact @26 line 18 [GsMethod 185651457]
| > | 146 HTTPServer >> acceptConnection @14 line 13 [GsMethod
| > | 186054145]
| > | 147 ComplexBlock in HTTPServer >> start @13 line 6 [GsMethod
| > | 186054913]
| > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5 [GsMethod
| > | 19138561]
| > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6 [GsMethod
| > | 186054913]
| > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod 4501249]
| > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
| > | [GsProcess 361105409]
| > | topaz 1> GemStone Smalltalk Compiler Errors:
| > | GemToGemAnnouncement uninstallStaticHandler.
| > | System beginTransaction.
| > | (ObjectLogEntry
| > | fatal: '8080: topaz exit'
| > | object:
| > | 'port: ', Swazoo printString, ' ',
| > | * ^1
| > | *******
| > | 'pid: ', (System gemVersionReport at: 'processId')
| > | printString) addToLog.
| > | System commitTransaction.
| > |
| > | 1: [1031] undefined symbol
| > |
| > | Now executing the following command saved from "iferr 1":
| > | where
| > | Stack is not active
| > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
| > | Sun Jan 15 18:16:58 UTC 2012
| > |
| > | hostcalldebugger invoked in process 1590, at 01/15/2012 06:16:58
| > | PM.598 UTC
| > | notifying stone of fatal error
| > |
| > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
| > |
| > |
| > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
| > |
| > | > Larry,
| > | >
| > | > GemStone has a lot of moving parts and it can be confusing to
| > | > tell
| > | > which piece is involved. In your case the stone log reports
| > | > that a
| > | > gem (with PID 1590) crashed. When the gem was started, was
| > | > there a
| > | > script that redirected output to a file? If so, do you have
| > | > that
| > | > file available?
| > | >
| > | > A typical explanation for this sort of problem is running out
| > | > of
| > | > temporary object cache in a gem. Doing so will cause the gem to
| > | > crash and not be able to report anything to the object log (as
| > | > it
| > | > would do for a non-fatal error). Depending on what the user
| > | > clicked on, your code may have taken a different path, or tried
| > | > to
| > | > load different objects.
| > | >
| > | > Auto-restarting a gem is typically done with a shell script
| > | > (e.g.,
| > | > bash). You can have a loop that checks for the existence of a
| > | > file
| > | > and if it is present (or absent, depending on your preference),
| > | > then start the gem. When the gem crashes, control will return
| > | > to
| > | > the script and the loop will continue. If you want to stop the
| > | > loop you can manually remove (or create) the flag file (or just
| > | > manually kill the process running the shell script).
| > | >
| > | > -James
| > | >
| > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
| > | >
| > | >> Hello,
| > | >> So, my GLASS server has been running for days on Amazon's
| > | >> service.
| > | >> I logged in many
| > | >> times a day, and worked with it, no problems.
| > | >>
| > | >> I gave the server information to someone else to try, and the
| > | >> server crashed with the
| > | >> following error: (from the seaside.log)
| > | >>
| > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
| > | >> processId
| > | >> 1384 is now the Symbol Creation Gem.
| > | >> Session 3 with processId 1383 is now the Admin Gem.
| > | >>
| > | >> Session 4 with processId 1382 is now the Page Reclaim Gem
| > | >> for
| > | >> extents 0 through 0.
| > | >>
| > | >> --- 01/15/2012 06:16:58 PM UTC ---
| > | >> Fatal Internal Error Notification from Gem, user =
| > | >> DataCurator
| > | >> Session = 6
| > | >> Gem hostName = localhost , Gem processId = 1590,
| > | >> current CommitRecord = 2376
| > | >>
| > | >> =======================================
| > | >>
| > | >> Any idea on how I can debug something like this? I have no
| > | >> idea
| > | >> what happened.
| > | >> There are no walkbacks in the Debug option on the Gemtools
| > | >> launcher. All I know is
| > | >> that the user was clicking around with FIrefox and it crashed.
| > | >>
| > | >> Furthermore, is there an easy way for me to restart my Gems
| > | >> once
| > | >> they go down?
| > | >> I start them with this:
| > | >>
| > | >> WAGemStoneRunSeasideGems default
| > | >> name: 'Swazoo';
| > | >> adaptorClass: WAGsSwazooAdaptor;
| > | >> ports: #(8080).
| > | >> WAGemStoneRunSeasideGems restartGems.
| > | >>
| > | >> After the crash, I restarted the Gems and the server process
| > | >> was
| > | >> fine.
| > | >>
| > | >> Regards,
| > | >>
| > | >> Larry
| > | >
| > |
| > |
|
|

Larry Kellogg

Re: Fatal Internal Notification from Gem

On Feb 6, 2012, at 12:09 PM, Dale Henrichs wrote:

> Lawrence,
>
> Are you getting an error message in your log file?
>
> Perhaps you are getting some secondary errors during error handling that is defeating the normal error handling process?
>

Does this shed any light on the issue: This is what happens after my error...

topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
-----------------------------------------------------
GemStone: Error Nonfatal
A hard break was received.
Error Category: 231169 [GemStone] Number: 6004 Arg Count: 1 Context : 455741697
Arg 1: [268870145 sz:33 cls: 74753 String] interrupted for Seaside debugging

Now executing the following command saved from "iferr 1":
where
==> 1 System class >> signal:args:signalDictionary: @8 line 15 [GsMethod 3241473]
2 GRGemStonePlatform >> generateHardBreak @5 line 7 [GsMethod 269769473]
3 GRGemStonePlatform >> openDebuggerOn: @1 line 3 [GsMethod 119149313]
4 WADebugErrorHandler >> open: @2 line 2 [GsMethod 203176961]
5 WADebugErrorHandler >> debugAndResume: @1 line 2 [GsMethod 203177217]
6 WADebugErrorHandler >> handleDefault: @1 line 2 [GsMethod 203177729]
7 WAErrorHandler >> handleError: @1 line 2 [GsMethod 177366529]
8 WAErrorHandler >> handleException: @3 line 3 [GsMethod 177366017]
9 ComplexBlock in WAExceptionHandler >> handleExceptionsDuring: @4 line 5 [GsMethod 177803521]
10 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
11 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
12 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod 9005057]
13 ComplexVCBlock in WAExceptionHandler >> handleExceptionsDuring: @7 line 8 [GsMethod 177803521]
14 ExceptionHandler >> caughtExceptionWithAction: @5 line 4 [GsMethod 10065153]
15 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13 [GsMethod 10064641]
16 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod 2304001]
17 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod 2304001]
18 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14 [GsMethod 10064641]
19 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12 [GsMethod 10062081]
20 Exception >> _signal:number:args: @2 line 7 [GsMethod 2327041]
21 System class >> signal:args:signalDictionary: @5 line 13 [GsMethod 3241473]
22 Object >> _error:args: @7 line 10 [GsMethod 1926401]
23 Collection >> _errorNotFound: @2 line 5 [GsMethod 1544705]
24 RcIdentityBag >> remove: @4 line 8 [GsMethod 12485377]

> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Sunday, February 5, 2012 7:43:34 PM
> | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> |
> |
> | On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > I see that you have since solved your issues here, but I do want to
> | > clarify a few points.
> | >
> | > First off, in the stack below I can't tell which Seaside error
> | > handler you are using. Since you are running your Seaside instance
> | > on AWS, you need to be using an error handler that produces
> | > continuations for your errors. To determine the error handler,
> | > print the following expression:
> | >
> | > WAAdmin applicationExceptionHandlingDefaults at: #exceptionHandler
> | > Running in AWS I would recommend that you use the
> | > WAGemStoneProductionErrorHandler (see [1] for options and
> | > details), since you don't want arbitrary users to be able to open
> | > inspectors on your server. When errors occur, the user is provided
> | > with feedback (that you can control) and a continuation is snapped
> | > off that you can debug from your development image[2].
> |
> | Dale,
> | You know, it's funny, I set the error handler to the production
> | one, like you said,
> |
> | WAGemStoneProductionErrorHandler is returned from WAAdmin
> | applicationExceptionHandlingDefaults at: #exceptionHandler, but,
> | yet,
> | when the system throws a walkback, the nginx gateway goes down, and I
> | do not get a continuation snapped off. Do I have to
> | do something else to enable that behavior?
> |
> | Lawrence
> |
> |
> |
> | >
> | > I didn't see an error handler on the stack so I am curious which
> | > error handler you are using.
> | >
> | > The undefined Swazoo variable is actually a bug[3] in the script.
> | > The most recent scripts (with this bugfix and other cleanups) can
> | > be found here[4].
> | >
> | > Dale
> | >
> | > [1] http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
> | > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
> | > [3] http://code.google.com/p/glassdb/issues/detail?id=158
> | > [4] http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Monday, January 16, 2012 12:21:36 PM
> | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> | > |
> | > | James,
> | > | Well, I think I traced the crash to the fact that I has
> | > | mistakenly
> | > | reintroduced some code that was trying to call out to
> | > | Cloudfork.
> | > | I removed that code and everything seems to be running better
> | > | now,
> | > | but it is a little too early to tell, for sure.
> | > |
> | > | Looking through the log files, and in particular, a Swazoo
> | > | server
> | > | log file, I guess this
> | > | walkback brought down the Gem. Is this of any help?
> | > |
> | > | Thanks for the tips with regards to writing a little shell
> | > | script
> | > | to restart my Ges.
> | > | I'll do that. With all the moving parts, I'm amazed that I have
> | > | gotten as much up
> | > | and running as I have. ;-)
> | > |
> | > | Regards,
> | > |
> | > | Larry
> | > |
> | > |
> | > |
> | > |
> | > | The object with object ID 81065893475386368 does not exist.
> | > | Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1
> | > | Context :
> | > | 361105409
> | > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
> | > | 81065893475386368
> | > |
> | > | Now executing the following command saved from "iferr 1":
> | > | where
> | > | ==> 1 GsProcess class >>
> | > | installPartialContinuation:atLevel:value: @2
> | > | line 1 [GsMethod 4487425]
> | > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
> | > | 212791041]
> | > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2 line 2
> | > | [GsMethod 218326273]
> | > | 4 ComplexBlock in WAComponent >> show:onAnswer:delegation: @7
> | > | line 7
> | > | [GsMethod 194749185]
> | > | 5 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments:
> | > | @12
> | > | line 8 [GsMethod 116163585]
> | > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
> | > | [GsMethod
> | > | 194735873]
> | > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod 194731009]
> | > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
> | > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
> | > | [GsMethod
> | > | 278171137]
> | > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn: @53
> | > | line 47
> | > | [GsMethod 259119617]
> | > | 11 ComplexBlock in ExecutableBlock >> valueWithPossibleArguments:
> | > | @6
> | > | line 4 [GsMethod 116163585]
> | > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
> | > | [GsMethod
> | > | 176951297]
> | > | 13 WACallback >> evaluateWithFieldValues: @5 line 2 [GsMethod
> | > | 177495553]
> | > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line 10
> | > | [GsMethod 177951489]
> | > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
> | > | 177951489]
> | > | 17 ComplexBlock in WAActionPhaseContinuation >> runCallbacks @7
> | > | line
> | > | 4 [GsMethod 202613505]
> | > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 21 WARenderLoopContinuation >> withNotificationHandlerDo: @3 line
> | > | 2
> | > | [GsMethod 202608385]
> | > | 22 ComplexVCBlock in WAActionPhaseContinuation >> runCallbacks @8
> | > | line 3 [GsMethod 202613505]
> | > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod 2304001]
> | > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
> | > | [GsMethod
> | > | 202613505]
> | > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
> | > | [GsMethod
> | > | 202614017]
> | > | 27 ComplexBlock in WASessionContinuation >> basicValue @3 line 2
> | > | [GsMethod 202625537]
> | > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7 line 3
> | > | [GsMethod 202627073]
> | > | 32 WASessionContinuation >> basicValue @4 line 2 [GsMethod
> | > | 202625537]
> | > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
> | > | 202623745]
> | > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
> | > | 202205441]
> | > | 35 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | 176192513]
> | > | 36 ComplexBlock in WADeprecatedToolFilter >> handleFiltered: @3
> | > | line
> | > | 2 [GsMethod 203213313]
> | > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
> | > | [GsMethod
> | > | 203213313]
> | > | 41 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | 176192513]
> | > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered: @4 line
> | > | 3
> | > | [GsMethod 203208449]
> | > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 45 WATimingToolFilter >> handleFiltered: @8 line 4 [GsMethod
> | > | 203208449]
> | > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | [GsMethod
> | > | 178568961]
> | > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 50 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | > | 177805825]
> | > | 51 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | [GsMethod 176176129]
> | > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | 176176129]
> | > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | > | 56 WASession >> handle: @10 line 11 [GsMethod 202210561]
> | > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod 176153857]
> | > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
> | > | 176155137]
> | > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
> | > | 176146945]
> | > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
> | > | 202644225]
> | > | 61 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | 176192513]
> | > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered: @3 line 3
> | > | [GsMethod 178300417]
> | > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line 3
> | > | [GsMethod 177803521]
> | > | 67 WAExceptionHandler class >> handleExceptionsDuring:context: @2
> | > | line 2 [GsMethod 177810177]
> | > | 68 WAExceptionFilter >> handleFiltered: @4 line 3 [GsMethod
> | > | 178300417]
> | > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | [GsMethod
> | > | 178568961]
> | > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 73 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | > | 177805825]
> | > | 74 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | [GsMethod 176176129]
> | > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | 176176129]
> | > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | > | 79 WADispatcher >> handleFiltered:named: @7 line 5 [GsMethod
> | > | 179090945]
> | > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
> | > | 179087617]
> | > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | [GsMethod
> | > | 178568961]
> | > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 85 WADynamicVariable class >> use:during: @4 line 4 [GsMethod
> | > | 177805825]
> | > | 86 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | [GsMethod 176176129]
> | > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | 176176129]
> | > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod 178568961]
> | > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4 line 4
> | > | [GsMethod 176816641]
> | > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 95 WAServerAdaptor >> handleRequest: @6 line 5 [GsMethod
> | > | 176816641]
> | > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod 176817921]
> | > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
> | > | [GsMethod
> | > | 176817153]
> | > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod 176817153]
> | > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line 6
> | > | [GsMethod 209224705]
> | > | 102 ComplexBlock in GRGemStonePlatform >>
> | > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
> | > | [GsMethod
> | > | 175179265]
> | > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 104 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 106 ComplexVCBlock in GRGemStonePlatform >>
> | > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
> | > | [GsMethod
> | > | 175179265]
> | > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod 2304001]
> | > | 109 TransientRecursionLock >> critical: @15 line 8 [GsMethod
> | > | 21159937]
> | > | 110 GRGemStonePlatform >>
> | > | seasideProcessRequestWithRetry:resultBlock:
> | > | @39 line 5 [GsMethod 175179265]
> | > | 111 ComplexBlock in GRGemStonePlatform >>
> | > | seasideProcessRequest:adaptor:resultBlock: @7 line 9 [GsMethod
> | > | 175179521]
> | > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 113 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 115 GRGemStonePlatform >>
> | > | seasideProcessRequest:adaptor:resultBlock:
> | > | @32 line 17 [GsMethod 175179521]
> | > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
> | > | 209224705]
> | > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod 203002625]
> | > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
> | > | 203002113]
> | > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | 185922561]
> | > | 120 ComplexBlock in URIResolution >> visitChildrenOf:advancing:
> | > | @10
> | > | line 7 [GsMethod 185924097]
> | > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | 122 URIResolution >> visitChildrenOf:advancing: @15 line 5
> | > | [GsMethod 185924097]
> | > | 123 URIResolution >> resolveTransparentComposite: @2 line 2
> | > | [GsMethod 185924609]
> | > | 124 URIResolution >> resolveServerRoot: @1 line 2 [GsMethod
> | > | 185920257]
> | > | 125 ServerRootComposite >> helpResolve: @1 line 2 [GsMethod
> | > | 186024449]
> | > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | 185922561]
> | > | 127 URIResolution class >> resolveRequest:startingAt: @3 line 2
> | > | [GsMethod 185802241]
> | > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod 186053889]
> | > | 129 ComplexBlock in HTTPConnection >> produceResponseFor: @9 line
> | > | 5
> | > | [GsMethod 185650433]
> | > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 131 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 133 HTTPConnection >> produceResponseFor: @23 line 6 [GsMethod
> | > | 185650433]
> | > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
> | > | [GsMethod
> | > | 185651201]
> | > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
> | > | [GsMethod
> | > | 185651457]
> | > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 137 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line 9
> | > | [GsMethod 185651457]
> | > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
> | > | [GsMethod 116163329]
> | > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8
> | > | [GsMethod 116163329]
> | > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line 13
> | > | [GsMethod 185651457]
> | > | 145 HTTPConnection >> interact @26 line 18 [GsMethod 185651457]
> | > | 146 HTTPServer >> acceptConnection @14 line 13 [GsMethod
> | > | 186054145]
> | > | 147 ComplexBlock in HTTPServer >> start @13 line 6 [GsMethod
> | > | 186054913]
> | > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5 [GsMethod
> | > | 19138561]
> | > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6 [GsMethod
> | > | 186054913]
> | > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod 4501249]
> | > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
> | > | [GsProcess 361105409]
> | > | topaz 1> GemStone Smalltalk Compiler Errors:
> | > | GemToGemAnnouncement uninstallStaticHandler.
> | > | System beginTransaction.
> | > | (ObjectLogEntry
> | > | fatal: '8080: topaz exit'
> | > | object:
> | > | 'port: ', Swazoo printString, ' ',
> | > | * ^1
> | > | *******
> | > | 'pid: ', (System gemVersionReport at: 'processId')
> | > | printString) addToLog.
> | > | System commitTransaction.
> | > |
> | > | 1: [1031] undefined symbol
> | > |
> | > | Now executing the following command saved from "iferr 1":
> | > | where
> | > | Stack is not active
> | > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
> | > | Sun Jan 15 18:16:58 UTC 2012
> | > |
> | > | hostcalldebugger invoked in process 1590, at 01/15/2012 06:16:58
> | > | PM.598 UTC
> | > | notifying stone of fatal error
> | > |
> | > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
> | > |
> | > |
> | > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
> | > |
> | > | > Larry,
> | > | >
> | > | > GemStone has a lot of moving parts and it can be confusing to
> | > | > tell
> | > | > which piece is involved. In your case the stone log reports
> | > | > that a
> | > | > gem (with PID 1590) crashed. When the gem was started, was
> | > | > there a
> | > | > script that redirected output to a file? If so, do you have
> | > | > that
> | > | > file available?
> | > | >
> | > | > A typical explanation for this sort of problem is running out
> | > | > of
> | > | > temporary object cache in a gem. Doing so will cause the gem to
> | > | > crash and not be able to report anything to the object log (as
> | > | > it
> | > | > would do for a non-fatal error). Depending on what the user
> | > | > clicked on, your code may have taken a different path, or tried
> | > | > to
> | > | > load different objects.
> | > | >
> | > | > Auto-restarting a gem is typically done with a shell script
> | > | > (e.g.,
> | > | > bash). You can have a loop that checks for the existence of a
> | > | > file
> | > | > and if it is present (or absent, depending on your preference),
> | > | > then start the gem. When the gem crashes, control will return
> | > | > to
> | > | > the script and the loop will continue. If you want to stop the
> | > | > loop you can manually remove (or create) the flag file (or just
> | > | > manually kill the process running the shell script).
> | > | >
> | > | > -James
> | > | >
> | > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
> | > | >
> | > | >> Hello,
> | > | >> So, my GLASS server has been running for days on Amazon's
> | > | >> service.
> | > | >> I logged in many
> | > | >> times a day, and worked with it, no problems.
> | > | >>
> | > | >> I gave the server information to someone else to try, and the
> | > | >> server crashed with the
> | > | >> following error: (from the seaside.log)
> | > | >>
> | > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
> | > | >> processId
> | > | >> 1384 is now the Symbol Creation Gem.
> | > | >> Session 3 with processId 1383 is now the Admin Gem.
> | > | >>
> | > | >> Session 4 with processId 1382 is now the Page Reclaim Gem
> | > | >> for
> | > | >> extents 0 through 0.
> | > | >>
> | > | >> --- 01/15/2012 06:16:58 PM UTC ---
> | > | >> Fatal Internal Error Notification from Gem, user =
> | > | >> DataCurator
> | > | >> Session = 6
> | > | >> Gem hostName = localhost , Gem processId = 1590,
> | > | >> current CommitRecord = 2376
> | > | >>
> | > | >> =======================================
> | > | >>
> | > | >> Any idea on how I can debug something like this? I have no
> | > | >> idea
> | > | >> what happened.
> | > | >> There are no walkbacks in the Debug option on the Gemtools
> | > | >> launcher. All I know is
> | > | >> that the user was clicking around with FIrefox and it crashed.
> | > | >>
> | > | >> Furthermore, is there an easy way for me to restart my Gems
> | > | >> once
> | > | >> they go down?
> | > | >> I start them with this:
> | > | >>
> | > | >> WAGemStoneRunSeasideGems default
> | > | >> name: 'Swazoo';
> | > | >> adaptorClass: WAGsSwazooAdaptor;
> | > | >> ports: #(8080).
> | > | >> WAGemStoneRunSeasideGems restartGems.
> | > | >>
> | > | >> After the crash, I restarted the Gems and the server process
> | > | >> was
> | > | >> fine.
> | > | >>
> | > | >> Regards,
> | > | >>
> | > | >> Larry
> | > | >
> | > |
> | > |
> |
> |

Dale Henrichs

Re: Fatal Internal Notification from Gem

Yes.

for whatever reason you are using the WADebugErrorHandler in that application which generates a hardBreak and if connected to a GemTools image would bring up a Gemtools debugger, but in a stand-alone Seaside image, the hardBreak causes the vm to exit and of course you lose your connection to nginx ...

I think that if you register your application again (i.e., after setting WAGemStoneProductionErrorHandler as your default handler) then you should be in business.

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, February 6, 2012 3:59:14 PM
| Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
|
|
| On Feb 6, 2012, at 12:09 PM, Dale Henrichs wrote:
|
| > Lawrence,
| >
| > Are you getting an error message in your log file?
| >
| > Perhaps you are getting some secondary errors during error handling
| > that is defeating the normal error handling process?
| >
|
| Does this shed any light on the issue: This is what happens after my
| error...
|
| topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
| -----------------------------------------------------
| GemStone: Error Nonfatal
| A hard break was received.
| Error Category: 231169 [GemStone] Number: 6004 Arg Count: 1 Context :
| 455741697
| Arg 1: [268870145 sz:33 cls: 74753 String] interrupted for Seaside
| debugging
|
| Now executing the following command saved from "iferr 1":
| where
| ==> 1 System class >> signal:args:signalDictionary: @8 line 15
| [GsMethod 3241473]
| 2 GRGemStonePlatform >> generateHardBreak @5 line 7 [GsMethod
| 269769473]
| 3 GRGemStonePlatform >> openDebuggerOn: @1 line 3 [GsMethod
| 119149313]
| 4 WADebugErrorHandler >> open: @2 line 2 [GsMethod 203176961]
| 5 WADebugErrorHandler >> debugAndResume: @1 line 2 [GsMethod
| 203177217]
| 6 WADebugErrorHandler >> handleDefault: @1 line 2 [GsMethod
| 203177729]
| 7 WAErrorHandler >> handleError: @1 line 2 [GsMethod 177366529]
| 8 WAErrorHandler >> handleException: @3 line 3 [GsMethod 177366017]
| 9 ComplexBlock in WAExceptionHandler >> handleExceptionsDuring: @4
| line 5 [GsMethod 177803521]
| 10 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
| 11 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
| 12 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
| 9005057]
| 13 ComplexVCBlock in WAExceptionHandler >> handleExceptionsDuring: @7
| line 8 [GsMethod 177803521]
| 14 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
| [GsMethod 10065153]
| 15 ComplexBlock in ExceptionHandler >>
| caughtEx:number:cat:args:handler: @12 line 13 [GsMethod 10064641]
| 16 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
| 2304001]
| 17 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
| 2304001]
| 18 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14
| [GsMethod 10064641]
| 19 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
| [GsMethod 10062081]
| 20 Exception >> _signal:number:args: @2 line 7 [GsMethod 2327041]
| 21 System class >> signal:args:signalDictionary: @5 line 13
| [GsMethod 3241473]
| 22 Object >> _error:args: @7 line 10 [GsMethod 1926401]
| 23 Collection >> _errorNotFound: @2 line 5 [GsMethod 1544705]
| 24 RcIdentityBag >> remove: @4 line 8 [GsMethod 12485377]
|
|
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Sunday, February 5, 2012 7:43:34 PM
| > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
| > |
| > |
| > | On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
| > |
| > | > Lawrence,
| > | >
| > | > I see that you have since solved your issues here, but I do
| > | > want to
| > | > clarify a few points.
| > | >
| > | > First off, in the stack below I can't tell which Seaside error
| > | > handler you are using. Since you are running your Seaside
| > | > instance
| > | > on AWS, you need to be using an error handler that produces
| > | > continuations for your errors. To determine the error handler,
| > | > print the following expression:
| > | >
| > | > WAAdmin applicationExceptionHandlingDefaults at:
| > | > #exceptionHandler
| > | > Running in AWS I would recommend that you use the
| > | > WAGemStoneProductionErrorHandler (see [1] for options and
| > | > details), since you don't want arbitrary users to be able to
| > | > open
| > | > inspectors on your server. When errors occur, the user is
| > | > provided
| > | > with feedback (that you can control) and a continuation is
| > | > snapped
| > | > off that you can debug from your development image[2].
| > |
| > | Dale,
| > | You know, it's funny, I set the error handler to the production
| > | one, like you said,
| > |
| > | WAGemStoneProductionErrorHandler is returned from WAAdmin
| > | applicationExceptionHandlingDefaults at: #exceptionHandler, but,
| > | yet,
| > | when the system throws a walkback, the nginx gateway goes down,
| > | and I
| > | do not get a continuation snapped off. Do I have to
| > | do something else to enable that behavior?
| > |
| > | Lawrence
| > |
| > |
| > |
| > | >
| > | > I didn't see an error handler on the stack so I am curious
| > | > which
| > | > error handler you are using.
| > | >
| > | > The undefined Swazoo variable is actually a bug[3] in the
| > | > script.
| > | > The most recent scripts (with this bugfix and other cleanups)
| > | > can
| > | > be found here[4].
| > | >
| > | > Dale
| > | >
| > | > [1]
| > | > http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
| > | > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
| > | > [3] http://code.google.com/p/glassdb/issues/detail?id=158
| > | > [4]
| > | > http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
| > | >
| > | > ----- Original Message -----
| > | > | From: "Lawrence Kellogg" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion"
| > | > | <[hidden email]>
| > | > | Sent: Monday, January 16, 2012 12:21:36 PM
| > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from
| > | > | Gem
| > | > |
| > | > | James,
| > | > | Well, I think I traced the crash to the fact that I has
| > | > | mistakenly
| > | > | reintroduced some code that was trying to call out to
| > | > | Cloudfork.
| > | > | I removed that code and everything seems to be running better
| > | > | now,
| > | > | but it is a little too early to tell, for sure.
| > | > |
| > | > | Looking through the log files, and in particular, a Swazoo
| > | > | server
| > | > | log file, I guess this
| > | > | walkback brought down the Gem. Is this of any help?
| > | > |
| > | > | Thanks for the tips with regards to writing a little shell
| > | > | script
| > | > | to restart my Ges.
| > | > | I'll do that. With all the moving parts, I'm amazed that I
| > | > | have
| > | > | gotten as much up
| > | > | and running as I have. ;-)
| > | > |
| > | > | Regards,
| > | > |
| > | > | Larry
| > | > |
| > | > |
| > | > |
| > | > |
| > | > | The object with object ID 81065893475386368 does not exist.
| > | > | Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1
| > | > | Context :
| > | > | 361105409
| > | > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
| > | > | 81065893475386368
| > | > |
| > | > | Now executing the following command saved from "iferr 1":
| > | > | where
| > | > | ==> 1 GsProcess class >>
| > | > | installPartialContinuation:atLevel:value: @2
| > | > | line 1 [GsMethod 4487425]
| > | > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
| > | > | 212791041]
| > | > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2
| > | > | line 2
| > | > | [GsMethod 218326273]
| > | > | 4 ComplexBlock in WAComponent >> show:onAnswer:delegation: @7
| > | > | line 7
| > | > | [GsMethod 194749185]
| > | > | 5 ComplexBlock in ExecutableBlock >>
| > | > | valueWithPossibleArguments:
| > | > | @12
| > | > | line 8 [GsMethod 116163585]
| > | > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
| > | > | [GsMethod
| > | > | 194735873]
| > | > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod
| > | > | 194731009]
| > | > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
| > | > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
| > | > | [GsMethod
| > | > | 278171137]
| > | > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn: @53
| > | > | line 47
| > | > | [GsMethod 259119617]
| > | > | 11 ComplexBlock in ExecutableBlock >>
| > | > | valueWithPossibleArguments:
| > | > | @6
| > | > | line 4 [GsMethod 116163585]
| > | > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
| > | > | [GsMethod
| > | > | 176951297]
| > | > | 13 WACallback >> evaluateWithFieldValues: @5 line 2
| > | > | [GsMethod
| > | > | 177495553]
| > | > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line 10
| > | > | [GsMethod 177951489]
| > | > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
| > | > | 177951489]
| > | > | 17 ComplexBlock in WAActionPhaseContinuation >> runCallbacks
| > | > | @7
| > | > | line
| > | > | 4 [GsMethod 202613505]
| > | > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 21 WARenderLoopContinuation >> withNotificationHandlerDo: @3
| > | > | line
| > | > | 2
| > | > | [GsMethod 202608385]
| > | > | 22 ComplexVCBlock in WAActionPhaseContinuation >>
| > | > | runCallbacks @8
| > | > | line 3 [GsMethod 202613505]
| > | > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod 2304001]
| > | > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
| > | > | [GsMethod
| > | > | 202613505]
| > | > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
| > | > | [GsMethod
| > | > | 202614017]
| > | > | 27 ComplexBlock in WASessionContinuation >> basicValue @3
| > | > | line 2
| > | > | [GsMethod 202625537]
| > | > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7
| > | > | line 3
| > | > | [GsMethod 202627073]
| > | > | 32 WASessionContinuation >> basicValue @4 line 2 [GsMethod
| > | > | 202625537]
| > | > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
| > | > | 202623745]
| > | > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
| > | > | 202205441]
| > | > | 35 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | > | 176192513]
| > | > | 36 ComplexBlock in WADeprecatedToolFilter >> handleFiltered:
| > | > | @3
| > | > | line
| > | > | 2 [GsMethod 203213313]
| > | > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
| > | > | [GsMethod
| > | > | 203213313]
| > | > | 41 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | > | 176192513]
| > | > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered: @4
| > | > | line
| > | > | 3
| > | > | [GsMethod 203208449]
| > | > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 45 WATimingToolFilter >> handleFiltered: @8 line 4
| > | > | [GsMethod
| > | > | 203208449]
| > | > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | [GsMethod
| > | > | 178568961]
| > | > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 50 WADynamicVariable class >> use:during: @4 line 4
| > | > | [GsMethod
| > | > | 177805825]
| > | > | 51 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | > | [GsMethod 176176129]
| > | > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | 176176129]
| > | > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | 178568961]
| > | > | 56 WASession >> handle: @10 line 11 [GsMethod 202210561]
| > | > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod
| > | > | 176153857]
| > | > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
| > | > | 176155137]
| > | > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
| > | > | 176146945]
| > | > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
| > | > | 202644225]
| > | > | 61 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
| > | > | 176192513]
| > | > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered: @3
| > | > | line 3
| > | > | [GsMethod 178300417]
| > | > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line 3
| > | > | [GsMethod 177803521]
| > | > | 67 WAExceptionHandler class >>
| > | > | handleExceptionsDuring:context: @2
| > | > | line 2 [GsMethod 177810177]
| > | > | 68 WAExceptionFilter >> handleFiltered: @4 line 3 [GsMethod
| > | > | 178300417]
| > | > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | [GsMethod
| > | > | 178568961]
| > | > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 73 WADynamicVariable class >> use:during: @4 line 4
| > | > | [GsMethod
| > | > | 177805825]
| > | > | 74 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | > | [GsMethod 176176129]
| > | > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | 176176129]
| > | > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | 178568961]
| > | > | 79 WADispatcher >> handleFiltered:named: @7 line 5
| > | > | [GsMethod
| > | > | 179090945]
| > | > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
| > | > | 179087617]
| > | > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | [GsMethod
| > | > | 178568961]
| > | > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 85 WADynamicVariable class >> use:during: @4 line 4
| > | > | [GsMethod
| > | > | 177805825]
| > | > | 86 ComplexBlock in WARequestContext >> push:during: @4 line 5
| > | > | [GsMethod 176176129]
| > | > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | 176176129]
| > | > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | 178568961]
| > | > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4 line
| > | > | 4
| > | > | [GsMethod 176816641]
| > | > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 95 WAServerAdaptor >> handleRequest: @6 line 5 [GsMethod
| > | > | 176816641]
| > | > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod
| > | > | 176817921]
| > | > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
| > | > | [GsMethod
| > | > | 176817153]
| > | > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod
| > | > | 176817153]
| > | > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line 6
| > | > | [GsMethod 209224705]
| > | > | 102 ComplexBlock in GRGemStonePlatform >>
| > | > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
| > | > | [GsMethod
| > | > | 175179265]
| > | > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 104 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 106 ComplexVCBlock in GRGemStonePlatform >>
| > | > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
| > | > | [GsMethod
| > | > | 175179265]
| > | > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod 2304001]
| > | > | 109 TransientRecursionLock >> critical: @15 line 8
| > | > | [GsMethod
| > | > | 21159937]
| > | > | 110 GRGemStonePlatform >>
| > | > | seasideProcessRequestWithRetry:resultBlock:
| > | > | @39 line 5 [GsMethod 175179265]
| > | > | 111 ComplexBlock in GRGemStonePlatform >>
| > | > | seasideProcessRequest:adaptor:resultBlock: @7 line 9
| > | > | [GsMethod
| > | > | 175179521]
| > | > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 113 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 115 GRGemStonePlatform >>
| > | > | seasideProcessRequest:adaptor:resultBlock:
| > | > | @32 line 17 [GsMethod 175179521]
| > | > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
| > | > | 209224705]
| > | > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod
| > | > | 203002625]
| > | > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
| > | > | 203002113]
| > | > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | > | 185922561]
| > | > | 120 ComplexBlock in URIResolution >>
| > | > | visitChildrenOf:advancing:
| > | > | @10
| > | > | line 7 [GsMethod 185924097]
| > | > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | > | 122 URIResolution >> visitChildrenOf:advancing: @15 line 5
| > | > | [GsMethod 185924097]
| > | > | 123 URIResolution >> resolveTransparentComposite: @2 line 2
| > | > | [GsMethod 185924609]
| > | > | 124 URIResolution >> resolveServerRoot: @1 line 2 [GsMethod
| > | > | 185920257]
| > | > | 125 ServerRootComposite >> helpResolve: @1 line 2 [GsMethod
| > | > | 186024449]
| > | > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | > | 185922561]
| > | > | 127 URIResolution class >> resolveRequest:startingAt: @3 line
| > | > | 2
| > | > | [GsMethod 185802241]
| > | > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod 186053889]
| > | > | 129 ComplexBlock in HTTPConnection >> produceResponseFor: @9
| > | > | line
| > | > | 5
| > | > | [GsMethod 185650433]
| > | > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 131 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 133 HTTPConnection >> produceResponseFor: @23 line 6
| > | > | [GsMethod
| > | > | 185650433]
| > | > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
| > | > | [GsMethod
| > | > | 185651201]
| > | > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
| > | > | [GsMethod
| > | > | 185651457]
| > | > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | 10065409]
| > | > | 137 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | 10062081]
| > | > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | [GsMethod
| > | > | 9005057]
| > | > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line 9
| > | > | [GsMethod 185651457]
| > | > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
| > | > | [GsMethod 116163329]
| > | > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | [GsMethod
| > | > | 2304001]
| > | > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line
| > | > | 8
| > | > | [GsMethod 116163329]
| > | > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line 13
| > | > | [GsMethod 185651457]
| > | > | 145 HTTPConnection >> interact @26 line 18 [GsMethod
| > | > | 185651457]
| > | > | 146 HTTPServer >> acceptConnection @14 line 13 [GsMethod
| > | > | 186054145]
| > | > | 147 ComplexBlock in HTTPServer >> start @13 line 6
| > | > | [GsMethod
| > | > | 186054913]
| > | > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5
| > | > | [GsMethod
| > | > | 19138561]
| > | > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6
| > | > | [GsMethod
| > | > | 186054913]
| > | > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod 4501249]
| > | > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
| > | > | [GsProcess 361105409]
| > | > | topaz 1> GemStone Smalltalk Compiler Errors:
| > | > | GemToGemAnnouncement uninstallStaticHandler.
| > | > | System beginTransaction.
| > | > | (ObjectLogEntry
| > | > | fatal: '8080: topaz exit'
| > | > | object:
| > | > | 'port: ', Swazoo printString, ' ',
| > | > | * ^1
| > | > | *******
| > | > | 'pid: ', (System gemVersionReport at: 'processId')
| > | > | printString) addToLog.
| > | > | System commitTransaction.
| > | > |
| > | > | 1: [1031] undefined symbol
| > | > |
| > | > | Now executing the following command saved from "iferr 1":
| > | > | where
| > | > | Stack is not active
| > | > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
| > | > | Sun Jan 15 18:16:58 UTC 2012
| > | > |
| > | > | hostcalldebugger invoked in process 1590, at 01/15/2012
| > | > | 06:16:58
| > | > | PM.598 UTC
| > | > | notifying stone of fatal error
| > | > |
| > | > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
| > | > |
| > | > |
| > | > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
| > | > |
| > | > | > Larry,
| > | > | >
| > | > | > GemStone has a lot of moving parts and it can be confusing
| > | > | > to
| > | > | > tell
| > | > | > which piece is involved. In your case the stone log reports
| > | > | > that a
| > | > | > gem (with PID 1590) crashed. When the gem was started, was
| > | > | > there a
| > | > | > script that redirected output to a file? If so, do you have
| > | > | > that
| > | > | > file available?
| > | > | >
| > | > | > A typical explanation for this sort of problem is running
| > | > | > out
| > | > | > of
| > | > | > temporary object cache in a gem. Doing so will cause the
| > | > | > gem to
| > | > | > crash and not be able to report anything to the object log
| > | > | > (as
| > | > | > it
| > | > | > would do for a non-fatal error). Depending on what the user
| > | > | > clicked on, your code may have taken a different path, or
| > | > | > tried
| > | > | > to
| > | > | > load different objects.
| > | > | >
| > | > | > Auto-restarting a gem is typically done with a shell script
| > | > | > (e.g.,
| > | > | > bash). You can have a loop that checks for the existence of
| > | > | > a
| > | > | > file
| > | > | > and if it is present (or absent, depending on your
| > | > | > preference),
| > | > | > then start the gem. When the gem crashes, control will
| > | > | > return
| > | > | > to
| > | > | > the script and the loop will continue. If you want to stop
| > | > | > the
| > | > | > loop you can manually remove (or create) the flag file (or
| > | > | > just
| > | > | > manually kill the process running the shell script).
| > | > | >
| > | > | > -James
| > | > | >
| > | > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
| > | > | >
| > | > | >> Hello,
| > | > | >> So, my GLASS server has been running for days on Amazon's
| > | > | >> service.
| > | > | >> I logged in many
| > | > | >> times a day, and worked with it, no problems.
| > | > | >>
| > | > | >> I gave the server information to someone else to try, and
| > | > | >> the
| > | > | >> server crashed with the
| > | > | >> following error: (from the seaside.log)
| > | > | >>
| > | > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
| > | > | >> processId
| > | > | >> 1384 is now the Symbol Creation Gem.
| > | > | >> Session 3 with processId 1383 is now the Admin Gem.
| > | > | >>
| > | > | >> Session 4 with processId 1382 is now the Page Reclaim
| > | > | >> Gem
| > | > | >> for
| > | > | >> extents 0 through 0.
| > | > | >>
| > | > | >> --- 01/15/2012 06:16:58 PM UTC ---
| > | > | >> Fatal Internal Error Notification from Gem, user =
| > | > | >> DataCurator
| > | > | >> Session = 6
| > | > | >> Gem hostName = localhost , Gem processId = 1590,
| > | > | >> current CommitRecord = 2376
| > | > | >>
| > | > | >> =======================================
| > | > | >>
| > | > | >> Any idea on how I can debug something like this? I have no
| > | > | >> idea
| > | > | >> what happened.
| > | > | >> There are no walkbacks in the Debug option on the Gemtools
| > | > | >> launcher. All I know is
| > | > | >> that the user was clicking around with FIrefox and it
| > | > | >> crashed.
| > | > | >>
| > | > | >> Furthermore, is there an easy way for me to restart my
| > | > | >> Gems
| > | > | >> once
| > | > | >> they go down?
| > | > | >> I start them with this:
| > | > | >>
| > | > | >> WAGemStoneRunSeasideGems default
| > | > | >> name: 'Swazoo';
| > | > | >> adaptorClass: WAGsSwazooAdaptor;
| > | > | >> ports: #(8080).
| > | > | >> WAGemStoneRunSeasideGems restartGems.
| > | > | >>
| > | > | >> After the crash, I restarted the Gems and the server
| > | > | >> process
| > | > | >> was
| > | > | >> fine.
| > | > | >>
| > | > | >> Regards,
| > | > | >>
| > | > | >> Larry
| > | > | >
| > | > |
| > | > |
| > |
| > |
|
|

Larry Kellogg

Re: Fatal Internal Notification from Gem

On Feb 6, 2012, at 7:07 PM, Dale Henrichs wrote:

> Yes.
>
> for whatever reason you are using the WADebugErrorHandler in that application which generates a hardBreak and if connected to a GemTools image would bring up a Gemtools debugger, but in a stand-alone Seaside image, the hardBreak causes the vm to exit and of course you lose your connection to nginx ...
>
> I think that if you register your application again (i.e., after setting WAGemStoneProductionErrorHandler as your default handler) then you should be in business.
>

Hmmm, I reset the error handler to production an re-ran the initialize method on my top level
task, threw in a halt in it but it still crashed and brought down the gateway. I don't know why.
Do I need to re-run the initialize method on all entry points?

Larry

> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Monday, February 6, 2012 3:59:14 PM
> | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> |
> |
> | On Feb 6, 2012, at 12:09 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > Are you getting an error message in your log file?
> | >
> | > Perhaps you are getting some secondary errors during error handling
> | > that is defeating the normal error handling process?
> | >
> |
> | Does this shed any light on the issue: This is what happens after my
> | error...
> |
> | topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> | -----------------------------------------------------
> | GemStone: Error Nonfatal
> | A hard break was received.
> | Error Category: 231169 [GemStone] Number: 6004 Arg Count: 1 Context :
> | 455741697
> | Arg 1: [268870145 sz:33 cls: 74753 String] interrupted for Seaside
> | debugging
> |
> | Now executing the following command saved from "iferr 1":
> | where
> | ==> 1 System class >> signal:args:signalDictionary: @8 line 15
> | [GsMethod 3241473]
> | 2 GRGemStonePlatform >> generateHardBreak @5 line 7 [GsMethod
> | 269769473]
> | 3 GRGemStonePlatform >> openDebuggerOn: @1 line 3 [GsMethod
> | 119149313]
> | 4 WADebugErrorHandler >> open: @2 line 2 [GsMethod 203176961]
> | 5 WADebugErrorHandler >> debugAndResume: @1 line 2 [GsMethod
> | 203177217]
> | 6 WADebugErrorHandler >> handleDefault: @1 line 2 [GsMethod
> | 203177729]
> | 7 WAErrorHandler >> handleError: @1 line 2 [GsMethod 177366529]
> | 8 WAErrorHandler >> handleException: @3 line 3 [GsMethod 177366017]
> | 9 ComplexBlock in WAExceptionHandler >> handleExceptionsDuring: @4
> | line 5 [GsMethod 177803521]
> | 10 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod 10065409]
> | 11 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod 10062081]
> | 12 ComplexBlock in ExecutableBlock >> on:do: @2 line 8 [GsMethod
> | 9005057]
> | 13 ComplexVCBlock in WAExceptionHandler >> handleExceptionsDuring: @7
> | line 8 [GsMethod 177803521]
> | 14 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
> | [GsMethod 10065153]
> | 15 ComplexBlock in ExceptionHandler >>
> | caughtEx:number:cat:args:handler: @12 line 13 [GsMethod 10064641]
> | 16 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod
> | 2304001]
> | 17 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod
> | 2304001]
> | 18 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14
> | [GsMethod 10064641]
> | 19 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
> | [GsMethod 10062081]
> | 20 Exception >> _signal:number:args: @2 line 7 [GsMethod 2327041]
> | 21 System class >> signal:args:signalDictionary: @5 line 13
> | [GsMethod 3241473]
> | 22 Object >> _error:args: @7 line 10 [GsMethod 1926401]
> | 23 Collection >> _errorNotFound: @2 line 5 [GsMethod 1544705]
> | 24 RcIdentityBag >> remove: @4 line 8 [GsMethod 12485377]
> |
> |
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Sunday, February 5, 2012 7:43:34 PM
> | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> | > |
> | > |
> | > | On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
> | > |
> | > | > Lawrence,
> | > | >
> | > | > I see that you have since solved your issues here, but I do
> | > | > want to
> | > | > clarify a few points.
> | > | >
> | > | > First off, in the stack below I can't tell which Seaside error
> | > | > handler you are using. Since you are running your Seaside
> | > | > instance
> | > | > on AWS, you need to be using an error handler that produces
> | > | > continuations for your errors. To determine the error handler,
> | > | > print the following expression:
> | > | >
> | > | > WAAdmin applicationExceptionHandlingDefaults at:
> | > | > #exceptionHandler
> | > | > Running in AWS I would recommend that you use the
> | > | > WAGemStoneProductionErrorHandler (see [1] for options and
> | > | > details), since you don't want arbitrary users to be able to
> | > | > open
> | > | > inspectors on your server. When errors occur, the user is
> | > | > provided
> | > | > with feedback (that you can control) and a continuation is
> | > | > snapped
> | > | > off that you can debug from your development image[2].
> | > |
> | > | Dale,
> | > | You know, it's funny, I set the error handler to the production
> | > | one, like you said,
> | > |
> | > | WAGemStoneProductionErrorHandler is returned from WAAdmin
> | > | applicationExceptionHandlingDefaults at: #exceptionHandler, but,
> | > | yet,
> | > | when the system throws a walkback, the nginx gateway goes down,
> | > | and I
> | > | do not get a continuation snapped off. Do I have to
> | > | do something else to enable that behavior?
> | > |
> | > | Lawrence
> | > |
> | > |
> | > |
> | > | >
> | > | > I didn't see an error handler on the stack so I am curious
> | > | > which
> | > | > error handler you are using.
> | > | >
> | > | > The undefined Swazoo variable is actually a bug[3] in the
> | > | > script.
> | > | > The most recent scripts (with this bugfix and other cleanups)
> | > | > can
> | > | > be found here[4].
> | > | >
> | > | > Dale
> | > | >
> | > | > [1]
> | > | > http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
> | > | > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
> | > | > [3] http://code.google.com/p/glassdb/issues/detail?id=158
> | > | > [4]
> | > | > http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | To: "GemStone Seaside beta discussion"
> | > | > | <[hidden email]>
> | > | > | Sent: Monday, January 16, 2012 12:21:36 PM
> | > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from
> | > | > | Gem
> | > | > |
> | > | > | James,
> | > | > | Well, I think I traced the crash to the fact that I has
> | > | > | mistakenly
> | > | > | reintroduced some code that was trying to call out to
> | > | > | Cloudfork.
> | > | > | I removed that code and everything seems to be running better
> | > | > | now,
> | > | > | but it is a little too early to tell, for sure.
> | > | > |
> | > | > | Looking through the log files, and in particular, a Swazoo
> | > | > | server
> | > | > | log file, I guess this
> | > | > | walkback brought down the Gem. Is this of any help?
> | > | > |
> | > | > | Thanks for the tips with regards to writing a little shell
> | > | > | script
> | > | > | to restart my Ges.
> | > | > | I'll do that. With all the moving parts, I'm amazed that I
> | > | > | have
> | > | > | gotten as much up
> | > | > | and running as I have. ;-)
> | > | > |
> | > | > | Regards,
> | > | > |
> | > | > | Larry
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | The object with object ID 81065893475386368 does not exist.
> | > | > | Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1
> | > | > | Context :
> | > | > | 361105409
> | > | > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
> | > | > | 81065893475386368
> | > | > |
> | > | > | Now executing the following command saved from "iferr 1":
> | > | > | where
> | > | > | ==> 1 GsProcess class >>
> | > | > | installPartialContinuation:atLevel:value: @2
> | > | > | line 1 [GsMethod 4487425]
> | > | > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
> | > | > | 212791041]
> | > | > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2
> | > | > | line 2
> | > | > | [GsMethod 218326273]
> | > | > | 4 ComplexBlock in WAComponent >> show:onAnswer:delegation: @7
> | > | > | line 7
> | > | > | [GsMethod 194749185]
> | > | > | 5 ComplexBlock in ExecutableBlock >>
> | > | > | valueWithPossibleArguments:
> | > | > | @12
> | > | > | line 8 [GsMethod 116163585]
> | > | > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
> | > | > | [GsMethod
> | > | > | 194735873]
> | > | > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod
> | > | > | 194731009]
> | > | > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
> | > | > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
> | > | > | [GsMethod
> | > | > | 278171137]
> | > | > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn: @53
> | > | > | line 47
> | > | > | [GsMethod 259119617]
> | > | > | 11 ComplexBlock in ExecutableBlock >>
> | > | > | valueWithPossibleArguments:
> | > | > | @6
> | > | > | line 4 [GsMethod 116163585]
> | > | > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
> | > | > | [GsMethod
> | > | > | 176951297]
> | > | > | 13 WACallback >> evaluateWithFieldValues: @5 line 2
> | > | > | [GsMethod
> | > | > | 177495553]
> | > | > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line 10
> | > | > | [GsMethod 177951489]
> | > | > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
> | > | > | 177951489]
> | > | > | 17 ComplexBlock in WAActionPhaseContinuation >> runCallbacks
> | > | > | @7
> | > | > | line
> | > | > | 4 [GsMethod 202613505]
> | > | > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 21 WARenderLoopContinuation >> withNotificationHandlerDo: @3
> | > | > | line
> | > | > | 2
> | > | > | [GsMethod 202608385]
> | > | > | 22 ComplexVCBlock in WAActionPhaseContinuation >>
> | > | > | runCallbacks @8
> | > | > | line 3 [GsMethod 202613505]
> | > | > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod 2304001]
> | > | > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
> | > | > | [GsMethod
> | > | > | 202613505]
> | > | > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
> | > | > | [GsMethod
> | > | > | 202614017]
> | > | > | 27 ComplexBlock in WASessionContinuation >> basicValue @3
> | > | > | line 2
> | > | > | [GsMethod 202625537]
> | > | > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7
> | > | > | line 3
> | > | > | [GsMethod 202627073]
> | > | > | 32 WASessionContinuation >> basicValue @4 line 2 [GsMethod
> | > | > | 202625537]
> | > | > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
> | > | > | 202623745]
> | > | > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
> | > | > | 202205441]
> | > | > | 35 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | > | 176192513]
> | > | > | 36 ComplexBlock in WADeprecatedToolFilter >> handleFiltered:
> | > | > | @3
> | > | > | line
> | > | > | 2 [GsMethod 203213313]
> | > | > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
> | > | > | [GsMethod
> | > | > | 203213313]
> | > | > | 41 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | > | 176192513]
> | > | > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered: @4
> | > | > | line
> | > | > | 3
> | > | > | [GsMethod 203208449]
> | > | > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 45 WATimingToolFilter >> handleFiltered: @8 line 4
> | > | > | [GsMethod
> | > | > | 203208449]
> | > | > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | [GsMethod
> | > | > | 178568961]
> | > | > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 50 WADynamicVariable class >> use:during: @4 line 4
> | > | > | [GsMethod
> | > | > | 177805825]
> | > | > | 51 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | > | [GsMethod 176176129]
> | > | > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | 176176129]
> | > | > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | 178568961]
> | > | > | 56 WASession >> handle: @10 line 11 [GsMethod 202210561]
> | > | > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod
> | > | > | 176153857]
> | > | > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
> | > | > | 176155137]
> | > | > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
> | > | > | 176146945]
> | > | > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
> | > | > | 202644225]
> | > | > | 61 WARequestFilter >> handleFiltered: @2 line 4 [GsMethod
> | > | > | 176192513]
> | > | > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered: @3
> | > | > | line 3
> | > | > | [GsMethod 178300417]
> | > | > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line 3
> | > | > | [GsMethod 177803521]
> | > | > | 67 WAExceptionHandler class >>
> | > | > | handleExceptionsDuring:context: @2
> | > | > | line 2 [GsMethod 177810177]
> | > | > | 68 WAExceptionFilter >> handleFiltered: @4 line 3 [GsMethod
> | > | > | 178300417]
> | > | > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | [GsMethod
> | > | > | 178568961]
> | > | > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 73 WADynamicVariable class >> use:during: @4 line 4
> | > | > | [GsMethod
> | > | > | 177805825]
> | > | > | 74 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | > | [GsMethod 176176129]
> | > | > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | 176176129]
> | > | > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | 178568961]
> | > | > | 79 WADispatcher >> handleFiltered:named: @7 line 5
> | > | > | [GsMethod
> | > | > | 179090945]
> | > | > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
> | > | > | 179087617]
> | > | > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | [GsMethod
> | > | > | 178568961]
> | > | > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 85 WADynamicVariable class >> use:during: @4 line 4
> | > | > | [GsMethod
> | > | > | 177805825]
> | > | > | 86 ComplexBlock in WARequestContext >> push:during: @4 line 5
> | > | > | [GsMethod 176176129]
> | > | > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | 176176129]
> | > | > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | 178568961]
> | > | > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4 line
> | > | > | 4
> | > | > | [GsMethod 176816641]
> | > | > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 95 WAServerAdaptor >> handleRequest: @6 line 5 [GsMethod
> | > | > | 176816641]
> | > | > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod
> | > | > | 176817921]
> | > | > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
> | > | > | [GsMethod
> | > | > | 176817153]
> | > | > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod
> | > | > | 176817153]
> | > | > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line 6
> | > | > | [GsMethod 209224705]
> | > | > | 102 ComplexBlock in GRGemStonePlatform >>
> | > | > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
> | > | > | [GsMethod
> | > | > | 175179265]
> | > | > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 104 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 106 ComplexVCBlock in GRGemStonePlatform >>
> | > | > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
> | > | > | [GsMethod
> | > | > | 175179265]
> | > | > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod 2304001]
> | > | > | 109 TransientRecursionLock >> critical: @15 line 8
> | > | > | [GsMethod
> | > | > | 21159937]
> | > | > | 110 GRGemStonePlatform >>
> | > | > | seasideProcessRequestWithRetry:resultBlock:
> | > | > | @39 line 5 [GsMethod 175179265]
> | > | > | 111 ComplexBlock in GRGemStonePlatform >>
> | > | > | seasideProcessRequest:adaptor:resultBlock: @7 line 9
> | > | > | [GsMethod
> | > | > | 175179521]
> | > | > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 113 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 115 GRGemStonePlatform >>
> | > | > | seasideProcessRequest:adaptor:resultBlock:
> | > | > | @32 line 17 [GsMethod 175179521]
> | > | > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
> | > | > | 209224705]
> | > | > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod
> | > | > | 203002625]
> | > | > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
> | > | > | 203002113]
> | > | > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | > | 185922561]
> | > | > | 120 ComplexBlock in URIResolution >>
> | > | > | visitChildrenOf:advancing:
> | > | > | @10
> | > | > | line 7 [GsMethod 185924097]
> | > | > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | > | 122 URIResolution >> visitChildrenOf:advancing: @15 line 5
> | > | > | [GsMethod 185924097]
> | > | > | 123 URIResolution >> resolveTransparentComposite: @2 line 2
> | > | > | [GsMethod 185924609]
> | > | > | 124 URIResolution >> resolveServerRoot: @1 line 2 [GsMethod
> | > | > | 185920257]
> | > | > | 125 ServerRootComposite >> helpResolve: @1 line 2 [GsMethod
> | > | > | 186024449]
> | > | > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | > | 185922561]
> | > | > | 127 URIResolution class >> resolveRequest:startingAt: @3 line
> | > | > | 2
> | > | > | [GsMethod 185802241]
> | > | > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod 186053889]
> | > | > | 129 ComplexBlock in HTTPConnection >> produceResponseFor: @9
> | > | > | line
> | > | > | 5
> | > | > | [GsMethod 185650433]
> | > | > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 131 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 133 HTTPConnection >> produceResponseFor: @23 line 6
> | > | > | [GsMethod
> | > | > | 185650433]
> | > | > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
> | > | > | [GsMethod
> | > | > | 185651201]
> | > | > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
> | > | > | [GsMethod
> | > | > | 185651457]
> | > | > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | 10065409]
> | > | > | 137 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | 10062081]
> | > | > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | [GsMethod
> | > | > | 9005057]
> | > | > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line 9
> | > | > | [GsMethod 185651457]
> | > | > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
> | > | > | [GsMethod 116163329]
> | > | > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | [GsMethod
> | > | > | 2304001]
> | > | > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line
> | > | > | 8
> | > | > | [GsMethod 116163329]
> | > | > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line 13
> | > | > | [GsMethod 185651457]
> | > | > | 145 HTTPConnection >> interact @26 line 18 [GsMethod
> | > | > | 185651457]
> | > | > | 146 HTTPServer >> acceptConnection @14 line 13 [GsMethod
> | > | > | 186054145]
> | > | > | 147 ComplexBlock in HTTPServer >> start @13 line 6
> | > | > | [GsMethod
> | > | > | 186054913]
> | > | > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5
> | > | > | [GsMethod
> | > | > | 19138561]
> | > | > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6
> | > | > | [GsMethod
> | > | > | 186054913]
> | > | > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod 4501249]
> | > | > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
> | > | > | [GsProcess 361105409]
> | > | > | topaz 1> GemStone Smalltalk Compiler Errors:
> | > | > | GemToGemAnnouncement uninstallStaticHandler.
> | > | > | System beginTransaction.
> | > | > | (ObjectLogEntry
> | > | > | fatal: '8080: topaz exit'
> | > | > | object:
> | > | > | 'port: ', Swazoo printString, ' ',
> | > | > | * ^1
> | > | > | *******
> | > | > | 'pid: ', (System gemVersionReport at: 'processId')
> | > | > | printString) addToLog.
> | > | > | System commitTransaction.
> | > | > |
> | > | > | 1: [1031] undefined symbol
> | > | > |
> | > | > | Now executing the following command saved from "iferr 1":
> | > | > | where
> | > | > | Stack is not active
> | > | > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
> | > | > | Sun Jan 15 18:16:58 UTC 2012
> | > | > |
> | > | > | hostcalldebugger invoked in process 1590, at 01/15/2012
> | > | > | 06:16:58
> | > | > | PM.598 UTC
> | > | > | notifying stone of fatal error
> | > | > |
> | > | > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
> | > | > |
> | > | > |
> | > | > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
> | > | > |
> | > | > | > Larry,
> | > | > | >
> | > | > | > GemStone has a lot of moving parts and it can be confusing
> | > | > | > to
> | > | > | > tell
> | > | > | > which piece is involved. In your case the stone log reports
> | > | > | > that a
> | > | > | > gem (with PID 1590) crashed. When the gem was started, was
> | > | > | > there a
> | > | > | > script that redirected output to a file? If so, do you have
> | > | > | > that
> | > | > | > file available?
> | > | > | >
> | > | > | > A typical explanation for this sort of problem is running
> | > | > | > out
> | > | > | > of
> | > | > | > temporary object cache in a gem. Doing so will cause the
> | > | > | > gem to
> | > | > | > crash and not be able to report anything to the object log
> | > | > | > (as
> | > | > | > it
> | > | > | > would do for a non-fatal error). Depending on what the user
> | > | > | > clicked on, your code may have taken a different path, or
> | > | > | > tried
> | > | > | > to
> | > | > | > load different objects.
> | > | > | >
> | > | > | > Auto-restarting a gem is typically done with a shell script
> | > | > | > (e.g.,
> | > | > | > bash). You can have a loop that checks for the existence of
> | > | > | > a
> | > | > | > file
> | > | > | > and if it is present (or absent, depending on your
> | > | > | > preference),
> | > | > | > then start the gem. When the gem crashes, control will
> | > | > | > return
> | > | > | > to
> | > | > | > the script and the loop will continue. If you want to stop
> | > | > | > the
> | > | > | > loop you can manually remove (or create) the flag file (or
> | > | > | > just
> | > | > | > manually kill the process running the shell script).
> | > | > | >
> | > | > | > -James
> | > | > | >
> | > | > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
> | > | > | >
> | > | > | >> Hello,
> | > | > | >> So, my GLASS server has been running for days on Amazon's
> | > | > | >> service.
> | > | > | >> I logged in many
> | > | > | >> times a day, and worked with it, no problems.
> | > | > | >>
> | > | > | >> I gave the server information to someone else to try, and
> | > | > | >> the
> | > | > | >> server crashed with the
> | > | > | >> following error: (from the seaside.log)
> | > | > | >>
> | > | > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
> | > | > | >> processId
> | > | > | >> 1384 is now the Symbol Creation Gem.
> | > | > | >> Session 3 with processId 1383 is now the Admin Gem.
> | > | > | >>
> | > | > | >> Session 4 with processId 1382 is now the Page Reclaim
> | > | > | >> Gem
> | > | > | >> for
> | > | > | >> extents 0 through 0.
> | > | > | >>
> | > | > | >> --- 01/15/2012 06:16:58 PM UTC ---
> | > | > | >> Fatal Internal Error Notification from Gem, user =
> | > | > | >> DataCurator
> | > | > | >> Session = 6
> | > | > | >> Gem hostName = localhost , Gem processId = 1590,
> | > | > | >> current CommitRecord = 2376
> | > | > | >>
> | > | > | >> =======================================
> | > | > | >>
> | > | > | >> Any idea on how I can debug something like this? I have no
> | > | > | >> idea
> | > | > | >> what happened.
> | > | > | >> There are no walkbacks in the Debug option on the Gemtools
> | > | > | >> launcher. All I know is
> | > | > | >> that the user was clicking around with FIrefox and it
> | > | > | >> crashed.
> | > | > | >>
> | > | > | >> Furthermore, is there an easy way for me to restart my
> | > | > | >> Gems
> | > | > | >> once
> | > | > | >> they go down?
> | > | > | >> I start them with this:
> | > | > | >>
> | > | > | >> WAGemStoneRunSeasideGems default
> | > | > | >> name: 'Swazoo';
> | > | > | >> adaptorClass: WAGsSwazooAdaptor;
> | > | > | >> ports: #(8080).
> | > | > | >> WAGemStoneRunSeasideGems restartGems.
> | > | > | >>
> | > | > | >> After the crash, I restarted the Gems and the server
> | > | > | >> process
> | > | > | >> was
> | > | > | >> fine.
> | > | > | >>
> | > | > | >> Regards,
> | > | > | >>
> | > | > | >> Larry
> | > | > | >
> | > | > |
> | > | > |
> | > |
> | > |
> |
> |

Dale Henrichs

Re: Fatal Internal Notification from Gem

You need to reregister your Seaside component(s) so that they use the correct default error handler ... double check that when you register your applications that you haven't hard-wired the error handlers to something...

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Monday, February 6, 2012 4:23:06 PM
| Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
|
|
| On Feb 6, 2012, at 7:07 PM, Dale Henrichs wrote:
|
| > Yes.
| >
| > for whatever reason you are using the WADebugErrorHandler in that
| > application which generates a hardBreak and if connected to a
| > GemTools image would bring up a Gemtools debugger, but in a
| > stand-alone Seaside image, the hardBreak causes the vm to exit and
| > of course you lose your connection to nginx ...
| >
| > I think that if you register your application again (i.e., after
| > setting WAGemStoneProductionErrorHandler as your default handler)
| > then you should be in business.
| >
|
|
| Hmmm, I reset the error handler to production an re-ran the
| initialize method on my top level
| task, threw in a halt in it but it still crashed and brought down the
| gateway. I don't know why.
| Do I need to re-run the initialize method on all entry points?
|
| Larry
|
|
|
|
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Monday, February 6, 2012 3:59:14 PM
| > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
| > |
| > |
| > | On Feb 6, 2012, at 12:09 PM, Dale Henrichs wrote:
| > |
| > | > Lawrence,
| > | >
| > | > Are you getting an error message in your log file?
| > | >
| > | > Perhaps you are getting some secondary errors during error
| > | > handling
| > | > that is defeating the normal error handling process?
| > | >
| > |
| > | Does this shed any light on the issue: This is what happens after
| > | my
| > | error...
| > |
| > | topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
| > | -----------------------------------------------------
| > | GemStone: Error Nonfatal
| > | A hard break was received.
| > | Error Category: 231169 [GemStone] Number: 6004 Arg Count: 1
| > | Context :
| > | 455741697
| > | Arg 1: [268870145 sz:33 cls: 74753 String] interrupted for
| > | Seaside
| > | debugging
| > |
| > | Now executing the following command saved from "iferr 1":
| > | where
| > | ==> 1 System class >> signal:args:signalDictionary: @8 line 15
| > | [GsMethod 3241473]
| > | 2 GRGemStonePlatform >> generateHardBreak @5 line 7 [GsMethod
| > | 269769473]
| > | 3 GRGemStonePlatform >> openDebuggerOn: @1 line 3 [GsMethod
| > | 119149313]
| > | 4 WADebugErrorHandler >> open: @2 line 2 [GsMethod 203176961]
| > | 5 WADebugErrorHandler >> debugAndResume: @1 line 2 [GsMethod
| > | 203177217]
| > | 6 WADebugErrorHandler >> handleDefault: @1 line 2 [GsMethod
| > | 203177729]
| > | 7 WAErrorHandler >> handleError: @1 line 2 [GsMethod 177366529]
| > | 8 WAErrorHandler >> handleException: @3 line 3 [GsMethod
| > | 177366017]
| > | 9 ComplexBlock in WAExceptionHandler >> handleExceptionsDuring:
| > | @4
| > | line 5 [GsMethod 177803521]
| > | 10 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | 10065409]
| > | 11 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | 10062081]
| > | 12 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | [GsMethod
| > | 9005057]
| > | 13 ComplexVCBlock in WAExceptionHandler >>
| > | handleExceptionsDuring: @7
| > | line 8 [GsMethod 177803521]
| > | 14 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
| > | [GsMethod 10065153]
| > | 15 ComplexBlock in ExceptionHandler >>
| > | caughtEx:number:cat:args:handler: @12 line 13 [GsMethod
| > | 10064641]
| > | 16 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | [GsMethod
| > | 2304001]
| > | 17 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | [GsMethod
| > | 2304001]
| > | 18 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line
| > | 14
| > | [GsMethod 10064641]
| > | 19 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
| > | [GsMethod 10062081]
| > | 20 Exception >> _signal:number:args: @2 line 7 [GsMethod
| > | 2327041]
| > | 21 System class >> signal:args:signalDictionary: @5 line 13
| > | [GsMethod 3241473]
| > | 22 Object >> _error:args: @7 line 10 [GsMethod 1926401]
| > | 23 Collection >> _errorNotFound: @2 line 5 [GsMethod 1544705]
| > | 24 RcIdentityBag >> remove: @4 line 8 [GsMethod 12485377]
| > |
| > |
| > |
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Lawrence Kellogg" <[hidden email]>
| > | > | To: "GemStone Seaside beta discussion"
| > | > | <[hidden email]>
| > | > | Sent: Sunday, February 5, 2012 7:43:34 PM
| > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from
| > | > | Gem
| > | > |
| > | > |
| > | > | On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
| > | > |
| > | > | > Lawrence,
| > | > | >
| > | > | > I see that you have since solved your issues here, but I do
| > | > | > want to
| > | > | > clarify a few points.
| > | > | >
| > | > | > First off, in the stack below I can't tell which Seaside
| > | > | > error
| > | > | > handler you are using. Since you are running your Seaside
| > | > | > instance
| > | > | > on AWS, you need to be using an error handler that produces
| > | > | > continuations for your errors. To determine the error
| > | > | > handler,
| > | > | > print the following expression:
| > | > | >
| > | > | > WAAdmin applicationExceptionHandlingDefaults at:
| > | > | > #exceptionHandler
| > | > | > Running in AWS I would recommend that you use the
| > | > | > WAGemStoneProductionErrorHandler (see [1] for options and
| > | > | > details), since you don't want arbitrary users to be able
| > | > | > to
| > | > | > open
| > | > | > inspectors on your server. When errors occur, the user is
| > | > | > provided
| > | > | > with feedback (that you can control) and a continuation is
| > | > | > snapped
| > | > | > off that you can debug from your development image[2].
| > | > |
| > | > | Dale,
| > | > | You know, it's funny, I set the error handler to the
| > | > | production
| > | > | one, like you said,
| > | > |
| > | > | WAGemStoneProductionErrorHandler is returned from WAAdmin
| > | > | applicationExceptionHandlingDefaults at: #exceptionHandler,
| > | > | but,
| > | > | yet,
| > | > | when the system throws a walkback, the nginx gateway goes
| > | > | down,
| > | > | and I
| > | > | do not get a continuation snapped off. Do I have to
| > | > | do something else to enable that behavior?
| > | > |
| > | > | Lawrence
| > | > |
| > | > |
| > | > |
| > | > | >
| > | > | > I didn't see an error handler on the stack so I am curious
| > | > | > which
| > | > | > error handler you are using.
| > | > | >
| > | > | > The undefined Swazoo variable is actually a bug[3] in the
| > | > | > script.
| > | > | > The most recent scripts (with this bugfix and other
| > | > | > cleanups)
| > | > | > can
| > | > | > be found here[4].
| > | > | >
| > | > | > Dale
| > | > | >
| > | > | > [1]
| > | > | > http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
| > | > | > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
| > | > | > [3] http://code.google.com/p/glassdb/issues/detail?id=158
| > | > | > [4]
| > | > | > http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
| > | > | >
| > | > | > ----- Original Message -----
| > | > | > | From: "Lawrence Kellogg" <[hidden email]>
| > | > | > | To: "GemStone Seaside beta discussion"
| > | > | > | <[hidden email]>
| > | > | > | Sent: Monday, January 16, 2012 12:21:36 PM
| > | > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification
| > | > | > | from
| > | > | > | Gem
| > | > | > |
| > | > | > | James,
| > | > | > | Well, I think I traced the crash to the fact that I has
| > | > | > | mistakenly
| > | > | > | reintroduced some code that was trying to call out to
| > | > | > | Cloudfork.
| > | > | > | I removed that code and everything seems to be running
| > | > | > | better
| > | > | > | now,
| > | > | > | but it is a little too early to tell, for sure.
| > | > | > |
| > | > | > | Looking through the log files, and in particular, a
| > | > | > | Swazoo
| > | > | > | server
| > | > | > | log file, I guess this
| > | > | > | walkback brought down the Gem. Is this of any help?
| > | > | > |
| > | > | > | Thanks for the tips with regards to writing a little
| > | > | > | shell
| > | > | > | script
| > | > | > | to restart my Ges.
| > | > | > | I'll do that. With all the moving parts, I'm amazed that
| > | > | > | I
| > | > | > | have
| > | > | > | gotten as much up
| > | > | > | and running as I have. ;-)
| > | > | > |
| > | > | > | Regards,
| > | > | > |
| > | > | > | Larry
| > | > | > |
| > | > | > |
| > | > | > |
| > | > | > |
| > | > | > | The object with object ID 81065893475386368 does not
| > | > | > | exist.
| > | > | > | Error Category: 231169 [GemStone] Number: 2101 Arg Count:
| > | > | > | 1
| > | > | > | Context :
| > | > | > | 361105409
| > | > | > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
| > | > | > | 81065893475386368
| > | > | > |
| > | > | > | Now executing the following command saved from "iferr 1":
| > | > | > | where
| > | > | > | ==> 1 GsProcess class >>
| > | > | > | installPartialContinuation:atLevel:value: @2
| > | > | > | line 1 [GsMethod 4487425]
| > | > | > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
| > | > | > | 212791041]
| > | > | > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2
| > | > | > | line 2
| > | > | > | [GsMethod 218326273]
| > | > | > | 4 ComplexBlock in WAComponent >>
| > | > | > | show:onAnswer:delegation: @7
| > | > | > | line 7
| > | > | > | [GsMethod 194749185]
| > | > | > | 5 ComplexBlock in ExecutableBlock >>
| > | > | > | valueWithPossibleArguments:
| > | > | > | @12
| > | > | > | line 8 [GsMethod 116163585]
| > | > | > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
| > | > | > | [GsMethod
| > | > | > | 194735873]
| > | > | > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod
| > | > | > | 194731009]
| > | > | > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
| > | > | > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
| > | > | > | [GsMethod
| > | > | > | 278171137]
| > | > | > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn:
| > | > | > | @53
| > | > | > | line 47
| > | > | > | [GsMethod 259119617]
| > | > | > | 11 ComplexBlock in ExecutableBlock >>
| > | > | > | valueWithPossibleArguments:
| > | > | > | @6
| > | > | > | line 4 [GsMethod 116163585]
| > | > | > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
| > | > | > | [GsMethod
| > | > | > | 176951297]
| > | > | > | 13 WACallback >> evaluateWithFieldValues: @5 line 2
| > | > | > | [GsMethod
| > | > | > | 177495553]
| > | > | > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line
| > | > | > | 10
| > | > | > | [GsMethod 177951489]
| > | > | > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | > | > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
| > | > | > | 177951489]
| > | > | > | 17 ComplexBlock in WAActionPhaseContinuation >>
| > | > | > | runCallbacks
| > | > | > | @7
| > | > | > | line
| > | > | > | 4 [GsMethod 202613505]
| > | > | > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 21 WARenderLoopContinuation >> withNotificationHandlerDo:
| > | > | > | @3
| > | > | > | line
| > | > | > | 2
| > | > | > | [GsMethod 202608385]
| > | > | > | 22 ComplexVCBlock in WAActionPhaseContinuation >>
| > | > | > | runCallbacks @8
| > | > | > | line 3 [GsMethod 202613505]
| > | > | > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line
| > | > | > | 11
| > | > | > | [GsMethod 2304001]
| > | > | > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
| > | > | > | [GsMethod
| > | > | > | 202613505]
| > | > | > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
| > | > | > | [GsMethod
| > | > | > | 202614017]
| > | > | > | 27 ComplexBlock in WASessionContinuation >> basicValue @3
| > | > | > | line 2
| > | > | > | [GsMethod 202625537]
| > | > | > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7
| > | > | > | line 3
| > | > | > | [GsMethod 202627073]
| > | > | > | 32 WASessionContinuation >> basicValue @4 line 2
| > | > | > | [GsMethod
| > | > | > | 202625537]
| > | > | > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
| > | > | > | 202623745]
| > | > | > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
| > | > | > | 202205441]
| > | > | > | 35 WARequestFilter >> handleFiltered: @2 line 4
| > | > | > | [GsMethod
| > | > | > | 176192513]
| > | > | > | 36 ComplexBlock in WADeprecatedToolFilter >>
| > | > | > | handleFiltered:
| > | > | > | @3
| > | > | > | line
| > | > | > | 2 [GsMethod 203213313]
| > | > | > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
| > | > | > | [GsMethod
| > | > | > | 203213313]
| > | > | > | 41 WARequestFilter >> handleFiltered: @2 line 4
| > | > | > | [GsMethod
| > | > | > | 176192513]
| > | > | > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered:
| > | > | > | @4
| > | > | > | line
| > | > | > | 3
| > | > | > | [GsMethod 203208449]
| > | > | > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 45 WATimingToolFilter >> handleFiltered: @8 line 4
| > | > | > | [GsMethod
| > | > | > | 203208449]
| > | > | > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 178568961]
| > | > | > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 50 WADynamicVariable class >> use:during: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 177805825]
| > | > | > | 51 ComplexBlock in WARequestContext >> push:during: @4
| > | > | > | line 5
| > | > | > | [GsMethod 176176129]
| > | > | > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | > | 176176129]
| > | > | > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | > | 178568961]
| > | > | > | 56 WASession >> handle: @10 line 11 [GsMethod
| > | > | > | 202210561]
| > | > | > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod
| > | > | > | 176153857]
| > | > | > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
| > | > | > | 176155137]
| > | > | > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
| > | > | > | 176146945]
| > | > | > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
| > | > | > | 202644225]
| > | > | > | 61 WARequestFilter >> handleFiltered: @2 line 4
| > | > | > | [GsMethod
| > | > | > | 176192513]
| > | > | > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered:
| > | > | > | @3
| > | > | > | line 3
| > | > | > | [GsMethod 178300417]
| > | > | > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line
| > | > | > | 3
| > | > | > | [GsMethod 177803521]
| > | > | > | 67 WAExceptionHandler class >>
| > | > | > | handleExceptionsDuring:context: @2
| > | > | > | line 2 [GsMethod 177810177]
| > | > | > | 68 WAExceptionFilter >> handleFiltered: @4 line 3
| > | > | > | [GsMethod
| > | > | > | 178300417]
| > | > | > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 178568961]
| > | > | > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 73 WADynamicVariable class >> use:during: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 177805825]
| > | > | > | 74 ComplexBlock in WARequestContext >> push:during: @4
| > | > | > | line 5
| > | > | > | [GsMethod 176176129]
| > | > | > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | > | 176176129]
| > | > | > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | > | 178568961]
| > | > | > | 79 WADispatcher >> handleFiltered:named: @7 line 5
| > | > | > | [GsMethod
| > | > | > | 179090945]
| > | > | > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
| > | > | > | 179087617]
| > | > | > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 178568961]
| > | > | > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 85 WADynamicVariable class >> use:during: @4 line 4
| > | > | > | [GsMethod
| > | > | > | 177805825]
| > | > | > | 86 ComplexBlock in WARequestContext >> push:during: @4
| > | > | > | line 5
| > | > | > | [GsMethod 176176129]
| > | > | > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
| > | > | > | 176176129]
| > | > | > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod
| > | > | > | 178568961]
| > | > | > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4
| > | > | > | line
| > | > | > | 4
| > | > | > | [GsMethod 176816641]
| > | > | > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
| > | > | > | 10062081]
| > | > | > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 95 WAServerAdaptor >> handleRequest: @6 line 5
| > | > | > | [GsMethod
| > | > | > | 176816641]
| > | > | > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod
| > | > | > | 176817921]
| > | > | > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
| > | > | > | [GsMethod
| > | > | > | 176817153]
| > | > | > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod
| > | > | > | 176817153]
| > | > | > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line
| > | > | > | 6
| > | > | > | [GsMethod 209224705]
| > | > | > | 102 ComplexBlock in GRGemStonePlatform >>
| > | > | > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
| > | > | > | [GsMethod
| > | > | > | 175179265]
| > | > | > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 104 ExceptionHandler >> try:on:do: @15 line 18
| > | > | > | [GsMethod
| > | > | > | 10062081]
| > | > | > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 106 ComplexVCBlock in GRGemStonePlatform >>
| > | > | > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
| > | > | > | [GsMethod
| > | > | > | 175179265]
| > | > | > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line
| > | > | > | 11
| > | > | > | [GsMethod 2304001]
| > | > | > | 109 TransientRecursionLock >> critical: @15 line 8
| > | > | > | [GsMethod
| > | > | > | 21159937]
| > | > | > | 110 GRGemStonePlatform >>
| > | > | > | seasideProcessRequestWithRetry:resultBlock:
| > | > | > | @39 line 5 [GsMethod 175179265]
| > | > | > | 111 ComplexBlock in GRGemStonePlatform >>
| > | > | > | seasideProcessRequest:adaptor:resultBlock: @7 line 9
| > | > | > | [GsMethod
| > | > | > | 175179521]
| > | > | > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 113 ExceptionHandler >> try:on:do: @15 line 18
| > | > | > | [GsMethod
| > | > | > | 10062081]
| > | > | > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 115 GRGemStonePlatform >>
| > | > | > | seasideProcessRequest:adaptor:resultBlock:
| > | > | > | @32 line 17 [GsMethod 175179521]
| > | > | > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
| > | > | > | 209224705]
| > | > | > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod
| > | > | > | 203002625]
| > | > | > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
| > | > | > | 203002113]
| > | > | > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | > | > | 185922561]
| > | > | > | 120 ComplexBlock in URIResolution >>
| > | > | > | visitChildrenOf:advancing:
| > | > | > | @10
| > | > | > | line 7 [GsMethod 185924097]
| > | > | > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
| > | > | > | 122 URIResolution >> visitChildrenOf:advancing: @15 line
| > | > | > | 5
| > | > | > | [GsMethod 185924097]
| > | > | > | 123 URIResolution >> resolveTransparentComposite: @2 line
| > | > | > | 2
| > | > | > | [GsMethod 185924609]
| > | > | > | 124 URIResolution >> resolveServerRoot: @1 line 2
| > | > | > | [GsMethod
| > | > | > | 185920257]
| > | > | > | 125 ServerRootComposite >> helpResolve: @1 line 2
| > | > | > | [GsMethod
| > | > | > | 186024449]
| > | > | > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
| > | > | > | 185922561]
| > | > | > | 127 URIResolution class >> resolveRequest:startingAt: @3
| > | > | > | line
| > | > | > | 2
| > | > | > | [GsMethod 185802241]
| > | > | > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod
| > | > | > | 186053889]
| > | > | > | 129 ComplexBlock in HTTPConnection >> produceResponseFor:
| > | > | > | @9
| > | > | > | line
| > | > | > | 5
| > | > | > | [GsMethod 185650433]
| > | > | > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 131 ExceptionHandler >> try:on:do: @15 line 18
| > | > | > | [GsMethod
| > | > | > | 10062081]
| > | > | > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 133 HTTPConnection >> produceResponseFor: @23 line 6
| > | > | > | [GsMethod
| > | > | > | 185650433]
| > | > | > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
| > | > | > | [GsMethod
| > | > | > | 185651201]
| > | > | > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
| > | > | > | [GsMethod
| > | > | > | 185651457]
| > | > | > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
| > | > | > | 10065409]
| > | > | > | 137 ExceptionHandler >> try:on:do: @15 line 18
| > | > | > | [GsMethod
| > | > | > | 10062081]
| > | > | > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | > | > | [GsMethod
| > | > | > | 9005057]
| > | > | > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line
| > | > | > | 9
| > | > | > | [GsMethod 185651457]
| > | > | > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4
| > | > | > | line 6
| > | > | > | [GsMethod 116163329]
| > | > | > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | > | > | [GsMethod
| > | > | > | 2304001]
| > | > | > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8
| > | > | > | line
| > | > | > | 8
| > | > | > | [GsMethod 116163329]
| > | > | > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line
| > | > | > | 13
| > | > | > | [GsMethod 185651457]
| > | > | > | 145 HTTPConnection >> interact @26 line 18 [GsMethod
| > | > | > | 185651457]
| > | > | > | 146 HTTPServer >> acceptConnection @14 line 13
| > | > | > | [GsMethod
| > | > | > | 186054145]
| > | > | > | 147 ComplexBlock in HTTPServer >> start @13 line 6
| > | > | > | [GsMethod
| > | > | > | 186054913]
| > | > | > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5
| > | > | > | [GsMethod
| > | > | > | 19138561]
| > | > | > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6
| > | > | > | [GsMethod
| > | > | > | 186054913]
| > | > | > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod
| > | > | > | 4501249]
| > | > | > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
| > | > | > | [GsProcess 361105409]
| > | > | > | topaz 1> GemStone Smalltalk Compiler Errors:
| > | > | > | GemToGemAnnouncement uninstallStaticHandler.
| > | > | > | System beginTransaction.
| > | > | > | (ObjectLogEntry
| > | > | > | fatal: '8080: topaz exit'
| > | > | > | object:
| > | > | > | 'port: ', Swazoo printString, ' ',
| > | > | > | * ^1
| > | > | > | *******
| > | > | > | 'pid: ', (System gemVersionReport at: 'processId')
| > | > | > | printString) addToLog.
| > | > | > | System commitTransaction.
| > | > | > |
| > | > | > | 1: [1031] undefined symbol
| > | > | > |
| > | > | > | Now executing the following command saved from "iferr 1":
| > | > | > | where
| > | > | > | Stack is not active
| > | > | > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
| > | > | > | Sun Jan 15 18:16:58 UTC 2012
| > | > | > |
| > | > | > | hostcalldebugger invoked in process 1590, at 01/15/2012
| > | > | > | 06:16:58
| > | > | > | PM.598 UTC
| > | > | > | notifying stone of fatal error
| > | > | > |
| > | > | > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
| > | > | > |
| > | > | > |
| > | > | > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
| > | > | > |
| > | > | > | > Larry,
| > | > | > | >
| > | > | > | > GemStone has a lot of moving parts and it can be
| > | > | > | > confusing
| > | > | > | > to
| > | > | > | > tell
| > | > | > | > which piece is involved. In your case the stone log
| > | > | > | > reports
| > | > | > | > that a
| > | > | > | > gem (with PID 1590) crashed. When the gem was started,
| > | > | > | > was
| > | > | > | > there a
| > | > | > | > script that redirected output to a file? If so, do you
| > | > | > | > have
| > | > | > | > that
| > | > | > | > file available?
| > | > | > | >
| > | > | > | > A typical explanation for this sort of problem is
| > | > | > | > running
| > | > | > | > out
| > | > | > | > of
| > | > | > | > temporary object cache in a gem. Doing so will cause
| > | > | > | > the
| > | > | > | > gem to
| > | > | > | > crash and not be able to report anything to the object
| > | > | > | > log
| > | > | > | > (as
| > | > | > | > it
| > | > | > | > would do for a non-fatal error). Depending on what the
| > | > | > | > user
| > | > | > | > clicked on, your code may have taken a different path,
| > | > | > | > or
| > | > | > | > tried
| > | > | > | > to
| > | > | > | > load different objects.
| > | > | > | >
| > | > | > | > Auto-restarting a gem is typically done with a shell
| > | > | > | > script
| > | > | > | > (e.g.,
| > | > | > | > bash). You can have a loop that checks for the
| > | > | > | > existence of
| > | > | > | > a
| > | > | > | > file
| > | > | > | > and if it is present (or absent, depending on your
| > | > | > | > preference),
| > | > | > | > then start the gem. When the gem crashes, control will
| > | > | > | > return
| > | > | > | > to
| > | > | > | > the script and the loop will continue. If you want to
| > | > | > | > stop
| > | > | > | > the
| > | > | > | > loop you can manually remove (or create) the flag file
| > | > | > | > (or
| > | > | > | > just
| > | > | > | > manually kill the process running the shell script).
| > | > | > | >
| > | > | > | > -James
| > | > | > | >
| > | > | > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
| > | > | > | >
| > | > | > | >> Hello,
| > | > | > | >> So, my GLASS server has been running for days on
| > | > | > | >> Amazon's
| > | > | > | >> service.
| > | > | > | >> I logged in many
| > | > | > | >> times a day, and worked with it, no problems.
| > | > | > | >>
| > | > | > | >> I gave the server information to someone else to try,
| > | > | > | >> and
| > | > | > | >> the
| > | > | > | >> server crashed with the
| > | > | > | >> following error: (from the seaside.log)
| > | > | > | >>
| > | > | > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
| > | > | > | >> processId
| > | > | > | >> 1384 is now the Symbol Creation Gem.
| > | > | > | >> Session 3 with processId 1383 is now the Admin Gem.
| > | > | > | >>
| > | > | > | >> Session 4 with processId 1382 is now the Page
| > | > | > | >> Reclaim
| > | > | > | >> Gem
| > | > | > | >> for
| > | > | > | >> extents 0 through 0.
| > | > | > | >>
| > | > | > | >> --- 01/15/2012 06:16:58 PM UTC ---
| > | > | > | >> Fatal Internal Error Notification from Gem, user =
| > | > | > | >> DataCurator
| > | > | > | >> Session = 6
| > | > | > | >> Gem hostName = localhost , Gem processId = 1590,
| > | > | > | >> current CommitRecord = 2376
| > | > | > | >>
| > | > | > | >> =======================================
| > | > | > | >>
| > | > | > | >> Any idea on how I can debug something like this? I
| > | > | > | >> have no
| > | > | > | >> idea
| > | > | > | >> what happened.
| > | > | > | >> There are no walkbacks in the Debug option on the
| > | > | > | >> Gemtools
| > | > | > | >> launcher. All I know is
| > | > | > | >> that the user was clicking around with FIrefox and it
| > | > | > | >> crashed.
| > | > | > | >>
| > | > | > | >> Furthermore, is there an easy way for me to restart my
| > | > | > | >> Gems
| > | > | > | >> once
| > | > | > | >> they go down?
| > | > | > | >> I start them with this:
| > | > | > | >>
| > | > | > | >> WAGemStoneRunSeasideGems default
| > | > | > | >> name: 'Swazoo';
| > | > | > | >> adaptorClass: WAGsSwazooAdaptor;
| > | > | > | >> ports: #(8080).
| > | > | > | >> WAGemStoneRunSeasideGems restartGems.
| > | > | > | >>
| > | > | > | >> After the crash, I restarted the Gems and the server
| > | > | > | >> process
| > | > | > | >> was
| > | > | > | >> fine.
| > | > | > | >>
| > | > | > | >> Regards,
| > | > | > | >>
| > | > | > | >> Larry
| > | > | > | >
| > | > | > |
| > | > | > |
| > | > |
| > | > |
| > |
| > |
|
|

Larry Kellogg

Re: Fatal Internal Notification from Gem

On Feb 6, 2012, at 8:23 PM, Dale Henrichs wrote:

> You need to reregister your Seaside component(s) so that they use the correct default error handler ... double check that when you register your applications that you haven't hard-wired the error handlers to something...
>

You nailed it, I had been copying over an init method with the other debug handler! Thanks!!!!

Pretty nifty error handling. I guess I'll customize that page...

Larry

> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Monday, February 6, 2012 4:23:06 PM
> | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> |
> |
> | On Feb 6, 2012, at 7:07 PM, Dale Henrichs wrote:
> |
> | > Yes.
> | >
> | > for whatever reason you are using the WADebugErrorHandler in that
> | > application which generates a hardBreak and if connected to a
> | > GemTools image would bring up a Gemtools debugger, but in a
> | > stand-alone Seaside image, the hardBreak causes the vm to exit and
> | > of course you lose your connection to nginx ...
> | >
> | > I think that if you register your application again (i.e., after
> | > setting WAGemStoneProductionErrorHandler as your default handler)
> | > then you should be in business.
> | >
> |
> |
> | Hmmm, I reset the error handler to production an re-ran the
> | initialize method on my top level
> | task, threw in a halt in it but it still crashed and brought down the
> | gateway. I don't know why.
> | Do I need to re-run the initialize method on all entry points?
> |
> | Larry
> |
> |
> |
> |
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Monday, February 6, 2012 3:59:14 PM
> | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from Gem
> | > |
> | > |
> | > | On Feb 6, 2012, at 12:09 PM, Dale Henrichs wrote:
> | > |
> | > | > Lawrence,
> | > | >
> | > | > Are you getting an error message in your log file?
> | > | >
> | > | > Perhaps you are getting some secondary errors during error
> | > | > handling
> | > | > that is defeating the normal error handling process?
> | > | >
> | > |
> | > | Does this shed any light on the issue: This is what happens after
> | > | my
> | > | error...
> | > |
> | > | topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> | > | -----------------------------------------------------
> | > | GemStone: Error Nonfatal
> | > | A hard break was received.
> | > | Error Category: 231169 [GemStone] Number: 6004 Arg Count: 1
> | > | Context :
> | > | 455741697
> | > | Arg 1: [268870145 sz:33 cls: 74753 String] interrupted for
> | > | Seaside
> | > | debugging
> | > |
> | > | Now executing the following command saved from "iferr 1":
> | > | where
> | > | ==> 1 System class >> signal:args:signalDictionary: @8 line 15
> | > | [GsMethod 3241473]
> | > | 2 GRGemStonePlatform >> generateHardBreak @5 line 7 [GsMethod
> | > | 269769473]
> | > | 3 GRGemStonePlatform >> openDebuggerOn: @1 line 3 [GsMethod
> | > | 119149313]
> | > | 4 WADebugErrorHandler >> open: @2 line 2 [GsMethod 203176961]
> | > | 5 WADebugErrorHandler >> debugAndResume: @1 line 2 [GsMethod
> | > | 203177217]
> | > | 6 WADebugErrorHandler >> handleDefault: @1 line 2 [GsMethod
> | > | 203177729]
> | > | 7 WAErrorHandler >> handleError: @1 line 2 [GsMethod 177366529]
> | > | 8 WAErrorHandler >> handleException: @3 line 3 [GsMethod
> | > | 177366017]
> | > | 9 ComplexBlock in WAExceptionHandler >> handleExceptionsDuring:
> | > | @4
> | > | line 5 [GsMethod 177803521]
> | > | 10 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | 10065409]
> | > | 11 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | 10062081]
> | > | 12 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | [GsMethod
> | > | 9005057]
> | > | 13 ComplexVCBlock in WAExceptionHandler >>
> | > | handleExceptionsDuring: @7
> | > | line 8 [GsMethod 177803521]
> | > | 14 ExceptionHandler >> caughtExceptionWithAction: @5 line 4
> | > | [GsMethod 10065153]
> | > | 15 ComplexBlock in ExceptionHandler >>
> | > | caughtEx:number:cat:args:handler: @12 line 13 [GsMethod
> | > | 10064641]
> | > | 16 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 17 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | [GsMethod
> | > | 2304001]
> | > | 18 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line
> | > | 14
> | > | [GsMethod 10064641]
> | > | 19 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
> | > | [GsMethod 10062081]
> | > | 20 Exception >> _signal:number:args: @2 line 7 [GsMethod
> | > | 2327041]
> | > | 21 System class >> signal:args:signalDictionary: @5 line 13
> | > | [GsMethod 3241473]
> | > | 22 Object >> _error:args: @7 line 10 [GsMethod 1926401]
> | > | 23 Collection >> _errorNotFound: @2 line 5 [GsMethod 1544705]
> | > | 24 RcIdentityBag >> remove: @4 line 8 [GsMethod 12485377]
> | > |
> | > |
> | > |
> | > | > Dale
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | To: "GemStone Seaside beta discussion"
> | > | > | <[hidden email]>
> | > | > | Sent: Sunday, February 5, 2012 7:43:34 PM
> | > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification from
> | > | > | Gem
> | > | > |
> | > | > |
> | > | > | On Jan 17, 2012, at 1:09 PM, Dale Henrichs wrote:
> | > | > |
> | > | > | > Lawrence,
> | > | > | >
> | > | > | > I see that you have since solved your issues here, but I do
> | > | > | > want to
> | > | > | > clarify a few points.
> | > | > | >
> | > | > | > First off, in the stack below I can't tell which Seaside
> | > | > | > error
> | > | > | > handler you are using. Since you are running your Seaside
> | > | > | > instance
> | > | > | > on AWS, you need to be using an error handler that produces
> | > | > | > continuations for your errors. To determine the error
> | > | > | > handler,
> | > | > | > print the following expression:
> | > | > | >
> | > | > | > WAAdmin applicationExceptionHandlingDefaults at:
> | > | > | > #exceptionHandler
> | > | > | > Running in AWS I would recommend that you use the
> | > | > | > WAGemStoneProductionErrorHandler (see [1] for options and
> | > | > | > details), since you don't want arbitrary users to be able
> | > | > | > to
> | > | > | > open
> | > | > | > inspectors on your server. When errors occur, the user is
> | > | > | > provided
> | > | > | > with feedback (that you can control) and a continuation is
> | > | > | > snapped
> | > | > | > off that you can debug from your development image[2].
> | > | > |
> | > | > | Dale,
> | > | > | You know, it's funny, I set the error handler to the
> | > | > | production
> | > | > | one, like you said,
> | > | > |
> | > | > | WAGemStoneProductionErrorHandler is returned from WAAdmin
> | > | > | applicationExceptionHandlingDefaults at: #exceptionHandler,
> | > | > | but,
> | > | > | yet,
> | > | > | when the system throws a walkback, the nginx gateway goes
> | > | > | down,
> | > | > | and I
> | > | > | do not get a continuation snapped off. Do I have to
> | > | > | do something else to enable that behavior?
> | > | > |
> | > | > | Lawrence
> | > | > |
> | > | > |
> | > | > |
> | > | > | >
> | > | > | > I didn't see an error handler on the stack so I am curious
> | > | > | > which
> | > | > | > error handler you are using.
> | > | > | >
> | > | > | > The undefined Swazoo variable is actually a bug[3] in the
> | > | > | > script.
> | > | > | > The most recent scripts (with this bugfix and other
> | > | > | > cleanups)
> | > | > | > can
> | > | > | > be found here[4].
> | > | > | >
> | > | > | > Dale
> | > | > | >
> | > | > | > [1]
> | > | > | > http://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers
> | > | > | > [2] http://code.google.com/p/glassdb/wiki/GemToolsDebug
> | > | > | > [3] http://code.google.com/p/glassdb/issues/detail?id=158
> | > | > | > [4]
> | > | > | > http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor
> | > | > | >
> | > | > | > ----- Original Message -----
> | > | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | > | To: "GemStone Seaside beta discussion"
> | > | > | > | <[hidden email]>
> | > | > | > | Sent: Monday, January 16, 2012 12:21:36 PM
> | > | > | > | Subject: Re: [GS/SS Beta] Fatal Internal Notification
> | > | > | > | from
> | > | > | > | Gem
> | > | > | > |
> | > | > | > | James,
> | > | > | > | Well, I think I traced the crash to the fact that I has
> | > | > | > | mistakenly
> | > | > | > | reintroduced some code that was trying to call out to
> | > | > | > | Cloudfork.
> | > | > | > | I removed that code and everything seems to be running
> | > | > | > | better
> | > | > | > | now,
> | > | > | > | but it is a little too early to tell, for sure.
> | > | > | > |
> | > | > | > | Looking through the log files, and in particular, a
> | > | > | > | Swazoo
> | > | > | > | server
> | > | > | > | log file, I guess this
> | > | > | > | walkback brought down the Gem. Is this of any help?
> | > | > | > |
> | > | > | > | Thanks for the tips with regards to writing a little
> | > | > | > | shell
> | > | > | > | script
> | > | > | > | to restart my Ges.
> | > | > | > | I'll do that. With all the moving parts, I'm amazed that
> | > | > | > | I
> | > | > | > | have
> | > | > | > | gotten as much up
> | > | > | > | and running as I have. ;-)
> | > | > | > |
> | > | > | > | Regards,
> | > | > | > |
> | > | > | > | Larry
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | The object with object ID 81065893475386368 does not
> | > | > | > | exist.
> | > | > | > | Error Category: 231169 [GemStone] Number: 2101 Arg Count:
> | > | > | > | 1
> | > | > | > | Context :
> | > | > | > | 361105409
> | > | > | > | Arg 1: [648527147803090946 sz:0 cls: 74241 SmallInteger]
> | > | > | > | 81065893475386368
> | > | > | > |
> | > | > | > | Now executing the following command saved from "iferr 1":
> | > | > | > | where
> | > | > | > | ==> 1 GsProcess class >>
> | > | > | > | installPartialContinuation:atLevel:value: @2
> | > | > | > | line 1 [GsMethod 4487425]
> | > | > | > | 2 WAPartialContinuation >> value: @13 line 11 [GsMethod
> | > | > | > | 212791041]
> | > | > | > | 3 WAPartialContinuation >> valueWithPossibleArguments: @2
> | > | > | > | line 2
> | > | > | > | [GsMethod 218326273]
> | > | > | > | 4 ComplexBlock in WAComponent >>
> | > | > | > | show:onAnswer:delegation: @7
> | > | > | > | line 7
> | > | > | > | [GsMethod 194749185]
> | > | > | > | 5 ComplexBlock in ExecutableBlock >>
> | > | > | > | valueWithPossibleArguments:
> | > | > | > | @12
> | > | > | > | line 8 [GsMethod 116163585]
> | > | > | > | 6 WAAnswerHandler >> handleAnswer:continueWith: @3 line 2
> | > | > | > | [GsMethod
> | > | > | > | 194735873]
> | > | > | > | 7 WADecoration >> handleAnswer: @6 line 3 [GsMethod
> | > | > | > | 194731009]
> | > | > | > | 8 WAComponent >> answer: @2 line 5 [GsMethod 194751745]
> | > | > | > | 9 MyComponent >> sendAnswerToCurrentComponent @2 line 2
> | > | > | > | [GsMethod
> | > | > | > | 278171137]
> | > | > | > | 10 ComplexBlock in MyComponent >> renderNavigationMenuOn:
> | > | > | > | @53
> | > | > | > | line 47
> | > | > | > | [GsMethod 259119617]
> | > | > | > | 11 ComplexBlock in ExecutableBlock >>
> | > | > | > | valueWithPossibleArguments:
> | > | > | > | @6
> | > | > | > | line 4 [GsMethod 116163585]
> | > | > | > | 12 WAActionCallback >> evaluateWithArgument: @3 line 2
> | > | > | > | [GsMethod
> | > | > | > | 176951297]
> | > | > | > | 13 WACallback >> evaluateWithFieldValues: @5 line 2
> | > | > | > | [GsMethod
> | > | > | > | 177495553]
> | > | > | > | 14 ComplexBlock in WACallbackRegistry >> handle: @16 line
> | > | > | > | 10
> | > | > | > | [GsMethod 177951489]
> | > | > | > | 15 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | > | > | 16 WACallbackRegistry >> handle: @17 line 9 [GsMethod
> | > | > | > | 177951489]
> | > | > | > | 17 ComplexBlock in WAActionPhaseContinuation >>
> | > | > | > | runCallbacks
> | > | > | > | @7
> | > | > | > | line
> | > | > | > | 4 [GsMethod 202613505]
> | > | > | > | 18 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 19 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 20 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 21 WARenderLoopContinuation >> withNotificationHandlerDo:
> | > | > | > | @3
> | > | > | > | line
> | > | > | > | 2
> | > | > | > | [GsMethod 202608385]
> | > | > | > | 22 ComplexVCBlock in WAActionPhaseContinuation >>
> | > | > | > | runCallbacks @8
> | > | > | > | line 3 [GsMethod 202613505]
> | > | > | > | 23 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 24 ComplexVCBlock in ExecutableBlock >> ensure: @6 line
> | > | > | > | 11
> | > | > | > | [GsMethod 2304001]
> | > | > | > | 25 WAActionPhaseContinuation >> runCallbacks @18 line 6
> | > | > | > | [GsMethod
> | > | > | > | 202613505]
> | > | > | > | 26 WAActionPhaseContinuation >> handleRequest @1 line 2
> | > | > | > | [GsMethod
> | > | > | > | 202614017]
> | > | > | > | 27 ComplexBlock in WASessionContinuation >> basicValue @3
> | > | > | > | line 2
> | > | > | > | [GsMethod 202625537]
> | > | > | > | 28 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 29 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 30 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 31 WASessionContinuation >> withUnregisteredHandlerDo: @7
> | > | > | > | line 3
> | > | > | > | [GsMethod 202627073]
> | > | > | > | 32 WASessionContinuation >> basicValue @4 line 2
> | > | > | > | [GsMethod
> | > | > | > | 202625537]
> | > | > | > | 33 WASessionContinuation >> value @3 line 5 [GsMethod
> | > | > | > | 202623745]
> | > | > | > | 34 WASession >> handleFiltered: @14 line 10 [GsMethod
> | > | > | > | 202205441]
> | > | > | > | 35 WARequestFilter >> handleFiltered: @2 line 4
> | > | > | > | [GsMethod
> | > | > | > | 176192513]
> | > | > | > | 36 ComplexBlock in WADeprecatedToolFilter >>
> | > | > | > | handleFiltered:
> | > | > | > | @3
> | > | > | > | line
> | > | > | > | 2 [GsMethod 203213313]
> | > | > | > | 37 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 38 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 39 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 40 WADeprecatedToolFilter >> handleFiltered: @6 line 3
> | > | > | > | [GsMethod
> | > | > | > | 203213313]
> | > | > | > | 41 WARequestFilter >> handleFiltered: @2 line 4
> | > | > | > | [GsMethod
> | > | > | > | 176192513]
> | > | > | > | 42 ComplexBlock in WATimingToolFilter >> handleFiltered:
> | > | > | > | @4
> | > | > | > | line
> | > | > | > | 3
> | > | > | > | [GsMethod 203208449]
> | > | > | > | 43 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 44 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 45 WATimingToolFilter >> handleFiltered: @8 line 4
> | > | > | > | [GsMethod
> | > | > | > | 203208449]
> | > | > | > | 46 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 47 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 48 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 49 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 50 WADynamicVariable class >> use:during: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 177805825]
> | > | > | > | 51 ComplexBlock in WARequestContext >> push:during: @4
> | > | > | > | line 5
> | > | > | > | [GsMethod 176176129]
> | > | > | > | 52 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 53 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 54 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | > | 176176129]
> | > | > | > | 55 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 56 WASession >> handle: @10 line 11 [GsMethod
> | > | > | > | 202210561]
> | > | > | > | 57 WARegistry >> dispatch:to: @1 line 5 [GsMethod
> | > | > | > | 176153857]
> | > | > | > | 58 WARegistry >> handleKeyed:with: @2 line 5 [GsMethod
> | > | > | > | 176155137]
> | > | > | > | 59 WARegistry >> handleFiltered: @33 line 19 [GsMethod
> | > | > | > | 176146945]
> | > | > | > | 60 WAApplication >> handleFiltered: @9 line 8 [GsMethod
> | > | > | > | 202644225]
> | > | > | > | 61 WARequestFilter >> handleFiltered: @2 line 4
> | > | > | > | [GsMethod
> | > | > | > | 176192513]
> | > | > | > | 62 ComplexBlock in WAExceptionFilter >> handleFiltered:
> | > | > | > | @3
> | > | > | > | line 3
> | > | > | > | [GsMethod 178300417]
> | > | > | > | 63 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 64 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 65 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 66 WAExceptionHandler >> handleExceptionsDuring: @8 line
> | > | > | > | 3
> | > | > | > | [GsMethod 177803521]
> | > | > | > | 67 WAExceptionHandler class >>
> | > | > | > | handleExceptionsDuring:context: @2
> | > | > | > | line 2 [GsMethod 177810177]
> | > | > | > | 68 WAExceptionFilter >> handleFiltered: @4 line 3
> | > | > | > | [GsMethod
> | > | > | > | 178300417]
> | > | > | > | 69 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 70 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 71 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 72 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 73 WADynamicVariable class >> use:during: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 177805825]
> | > | > | > | 74 ComplexBlock in WARequestContext >> push:during: @4
> | > | > | > | line 5
> | > | > | > | [GsMethod 176176129]
> | > | > | > | 75 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 76 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 77 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | > | 176176129]
> | > | > | > | 78 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 79 WADispatcher >> handleFiltered:named: @7 line 5
> | > | > | > | [GsMethod
> | > | > | > | 179090945]
> | > | > | > | 80 WADispatcher >> handleFiltered: @7 line 6 [GsMethod
> | > | > | > | 179087617]
> | > | > | > | 81 ComplexBlock in WARequestHandler >> handle: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 82 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 83 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 84 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 85 WADynamicVariable class >> use:during: @4 line 4
> | > | > | > | [GsMethod
> | > | > | > | 177805825]
> | > | > | > | 86 ComplexBlock in WARequestContext >> push:during: @4
> | > | > | > | line 5
> | > | > | > | [GsMethod 176176129]
> | > | > | > | 87 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 88 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 89 WARequestContext >> push:during: @7 line 6 [GsMethod
> | > | > | > | 176176129]
> | > | > | > | 90 WARequestHandler >> handle: @5 line 4 [GsMethod
> | > | > | > | 178568961]
> | > | > | > | 91 ComplexBlock in WAServerAdaptor >> handleRequest: @4
> | > | > | > | line
> | > | > | > | 4
> | > | > | > | [GsMethod 176816641]
> | > | > | > | 92 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 93 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 94 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 95 WAServerAdaptor >> handleRequest: @6 line 5
> | > | > | > | [GsMethod
> | > | > | > | 176816641]
> | > | > | > | 96 WAServerAdaptor >> handle: @1 line 4 [GsMethod
> | > | > | > | 176817921]
> | > | > | > | 97 ComplexBlock in WAServerAdaptor >> process: @5 line 6
> | > | > | > | [GsMethod
> | > | > | > | 176817153]
> | > | > | > | 98 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 99 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 100 WAServerAdaptor >> process: @9 line 7 [GsMethod
> | > | > | > | 176817153]
> | > | > | > | 101 ComplexBlock in WAGsSwazooAdaptor >> process: @3 line
> | > | > | > | 6
> | > | > | > | [GsMethod 209224705]
> | > | > | > | 102 ComplexBlock in GRGemStonePlatform >>
> | > | > | > | seasideProcessRequestWithRetry:resultBlock: @12 line 11
> | > | > | > | [GsMethod
> | > | > | > | 175179265]
> | > | > | > | 103 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 104 ExceptionHandler >> try:on:do: @15 line 18
> | > | > | > | [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 105 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 106 ComplexVCBlock in GRGemStonePlatform >>
> | > | > | > | seasideProcessRequestWithRetry:resultBlock: @18 line 12
> | > | > | > | [GsMethod
> | > | > | > | 175179265]
> | > | > | > | 107 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 108 ComplexVCBlock in ExecutableBlock >> ensure: @6 line
> | > | > | > | 11
> | > | > | > | [GsMethod 2304001]
> | > | > | > | 109 TransientRecursionLock >> critical: @15 line 8
> | > | > | > | [GsMethod
> | > | > | > | 21159937]
> | > | > | > | 110 GRGemStonePlatform >>
> | > | > | > | seasideProcessRequestWithRetry:resultBlock:
> | > | > | > | @39 line 5 [GsMethod 175179265]
> | > | > | > | 111 ComplexBlock in GRGemStonePlatform >>
> | > | > | > | seasideProcessRequest:adaptor:resultBlock: @7 line 9
> | > | > | > | [GsMethod
> | > | > | > | 175179521]
> | > | > | > | 112 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 113 ExceptionHandler >> try:on:do: @15 line 18
> | > | > | > | [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 114 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 115 GRGemStonePlatform >>
> | > | > | > | seasideProcessRequest:adaptor:resultBlock:
> | > | > | > | @32 line 17 [GsMethod 175179521]
> | > | > | > | 116 WAGsSwazooAdaptor >> process: @4 line 4 [GsMethod
> | > | > | > | 209224705]
> | > | > | > | 117 WAPluggableSite >> answerTo: @2 line 2 [GsMethod
> | > | > | > | 203002625]
> | > | > | > | 118 WAPluggableSite >> helpResolve: @7 line 3 [GsMethod
> | > | > | > | 203002113]
> | > | > | > | 119 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | > | > | 185922561]
> | > | > | > | 120 ComplexBlock in URIResolution >>
> | > | > | > | visitChildrenOf:advancing:
> | > | > | > | @10
> | > | > | > | line 7 [GsMethod 185924097]
> | > | > | > | 121 Collection >> do: @5 line 10 [GsMethod 1547777]
> | > | > | > | 122 URIResolution >> visitChildrenOf:advancing: @15 line
> | > | > | > | 5
> | > | > | > | [GsMethod 185924097]
> | > | > | > | 123 URIResolution >> resolveTransparentComposite: @2 line
> | > | > | > | 2
> | > | > | > | [GsMethod 185924609]
> | > | > | > | 124 URIResolution >> resolveServerRoot: @1 line 2
> | > | > | > | [GsMethod
> | > | > | > | 185920257]
> | > | > | > | 125 ServerRootComposite >> helpResolve: @1 line 2
> | > | > | > | [GsMethod
> | > | > | > | 186024449]
> | > | > | > | 126 URIResolution >> visitResource: @1 line 2 [GsMethod
> | > | > | > | 185922561]
> | > | > | > | 127 URIResolution class >> resolveRequest:startingAt: @3
> | > | > | > | line
> | > | > | > | 2
> | > | > | > | [GsMethod 185802241]
> | > | > | > | 128 HTTPServer >> answerTo: @3 line 3 [GsMethod
> | > | > | > | 186053889]
> | > | > | > | 129 ComplexBlock in HTTPConnection >> produceResponseFor:
> | > | > | > | @9
> | > | > | > | line
> | > | > | > | 5
> | > | > | > | [GsMethod 185650433]
> | > | > | > | 130 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 131 ExceptionHandler >> try:on:do: @15 line 18
> | > | > | > | [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 132 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 133 HTTPConnection >> produceResponseFor: @23 line 6
> | > | > | > | [GsMethod
> | > | > | > | 185650433]
> | > | > | > | 134 HTTPConnection >> getAndDispatchMessages @9 line 9
> | > | > | > | [GsMethod
> | > | > | > | 185651201]
> | > | > | > | 135 ComplexBlock in HTTPConnection >> interact @7 line 6
> | > | > | > | [GsMethod
> | > | > | > | 185651457]
> | > | > | > | 136 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod
> | > | > | > | 10065409]
> | > | > | > | 137 ExceptionHandler >> try:on:do: @15 line 18
> | > | > | > | [GsMethod
> | > | > | > | 10062081]
> | > | > | > | 138 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | > | > | [GsMethod
> | > | > | > | 9005057]
> | > | > | > | 139 ComplexVCBlock in HTTPConnection >> interact @12 line
> | > | > | > | 9
> | > | > | > | [GsMethod 185651457]
> | > | > | > | 140 ComplexBlock in ExecutableBlock >> ifCurtailed: @4
> | > | > | > | line 6
> | > | > | > | [GsMethod 116163329]
> | > | > | > | 141 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 142 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | > | > | [GsMethod
> | > | > | > | 2304001]
> | > | > | > | 143 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8
> | > | > | > | line
> | > | > | > | 8
> | > | > | > | [GsMethod 116163329]
> | > | > | > | 144 ComplexVCBlock in HTTPConnection >> interact @19 line
> | > | > | > | 13
> | > | > | > | [GsMethod 185651457]
> | > | > | > | 145 HTTPConnection >> interact @26 line 18 [GsMethod
> | > | > | > | 185651457]
> | > | > | > | 146 HTTPServer >> acceptConnection @14 line 13
> | > | > | > | [GsMethod
> | > | > | > | 186054145]
> | > | > | > | 147 ComplexBlock in HTTPServer >> start @13 line 6
> | > | > | > | [GsMethod
> | > | > | > | 186054913]
> | > | > | > | 148 ComplexBlock in BlockClosure >> repeat @3 line 5
> | > | > | > | [GsMethod
> | > | > | > | 19138561]
> | > | > | > | 149 ComplexVCBlock in HTTPServer >> start @14 line 6
> | > | > | > | [GsMethod
> | > | > | > | 186054913]
> | > | > | > | 150 GsProcess >> _startPart2 @15 line 17 [GsMethod
> | > | > | > | 4501249]
> | > | > | > | 151 GsProcess >> _start @1 line 9 [GsMethod 4501761]
> | > | > | > | [GsProcess 361105409]
> | > | > | > | topaz 1> GemStone Smalltalk Compiler Errors:
> | > | > | > | GemToGemAnnouncement uninstallStaticHandler.
> | > | > | > | System beginTransaction.
> | > | > | > | (ObjectLogEntry
> | > | > | > | fatal: '8080: topaz exit'
> | > | > | > | object:
> | > | > | > | 'port: ', Swazoo printString, ' ',
> | > | > | > | * ^1
> | > | > | > | *******
> | > | > | > | 'pid: ', (System gemVersionReport at: 'processId')
> | > | > | > | printString) addToLog.
> | > | > | > | System commitTransaction.
> | > | > | > |
> | > | > | > | 1: [1031] undefined symbol
> | > | > | > |
> | > | > | > | Now executing the following command saved from "iferr 1":
> | > | > | > | where
> | > | > | > | Stack is not active
> | > | > | > | topaz 1> Sun Jan 15 18:16:58 UTC 2012
> | > | > | > | Sun Jan 15 18:16:58 UTC 2012
> | > | > | > |
> | > | > | > | hostcalldebugger invoked in process 1590, at 01/15/2012
> | > | > | > | 06:16:58
> | > | > | > | PM.598 UTC
> | > | > | > | notifying stone of fatal error
> | > | > | > |
> | > | > | > | [Info]: Logging out at 01/15/2012 06:16:58 PM UTC
> | > | > | > |
> | > | > | > |
> | > | > | > | On Jan 16, 2012, at 2:42 PM, James Foster wrote:
> | > | > | > |
> | > | > | > | > Larry,
> | > | > | > | >
> | > | > | > | > GemStone has a lot of moving parts and it can be
> | > | > | > | > confusing
> | > | > | > | > to
> | > | > | > | > tell
> | > | > | > | > which piece is involved. In your case the stone log
> | > | > | > | > reports
> | > | > | > | > that a
> | > | > | > | > gem (with PID 1590) crashed. When the gem was started,
> | > | > | > | > was
> | > | > | > | > there a
> | > | > | > | > script that redirected output to a file? If so, do you
> | > | > | > | > have
> | > | > | > | > that
> | > | > | > | > file available?
> | > | > | > | >
> | > | > | > | > A typical explanation for this sort of problem is
> | > | > | > | > running
> | > | > | > | > out
> | > | > | > | > of
> | > | > | > | > temporary object cache in a gem. Doing so will cause
> | > | > | > | > the
> | > | > | > | > gem to
> | > | > | > | > crash and not be able to report anything to the object
> | > | > | > | > log
> | > | > | > | > (as
> | > | > | > | > it
> | > | > | > | > would do for a non-fatal error). Depending on what the
> | > | > | > | > user
> | > | > | > | > clicked on, your code may have taken a different path,
> | > | > | > | > or
> | > | > | > | > tried
> | > | > | > | > to
> | > | > | > | > load different objects.
> | > | > | > | >
> | > | > | > | > Auto-restarting a gem is typically done with a shell
> | > | > | > | > script
> | > | > | > | > (e.g.,
> | > | > | > | > bash). You can have a loop that checks for the
> | > | > | > | > existence of
> | > | > | > | > a
> | > | > | > | > file
> | > | > | > | > and if it is present (or absent, depending on your
> | > | > | > | > preference),
> | > | > | > | > then start the gem. When the gem crashes, control will
> | > | > | > | > return
> | > | > | > | > to
> | > | > | > | > the script and the loop will continue. If you want to
> | > | > | > | > stop
> | > | > | > | > the
> | > | > | > | > loop you can manually remove (or create) the flag file
> | > | > | > | > (or
> | > | > | > | > just
> | > | > | > | > manually kill the process running the shell script).
> | > | > | > | >
> | > | > | > | > -James
> | > | > | > | >
> | > | > | > | > On Jan 15, 2012, at 11:40 AM, Lawrence Kellogg wrote:
> | > | > | > | >
> | > | > | > | >> Hello,
> | > | > | > | >> So, my GLASS server has been running for days on
> | > | > | > | >> Amazon's
> | > | > | > | >> service.
> | > | > | > | >> I logged in many
> | > | > | > | >> times a day, and worked with it, no problems.
> | > | > | > | >>
> | > | > | > | >> I gave the server information to someone else to try,
> | > | > | > | >> and
> | > | > | > | >> the
> | > | > | > | >> server crashed with the
> | > | > | > | >> following error: (from the seaside.log)
> | > | > | > | >>
> | > | > | > | >> --- 01/13/2012 03:39:21 AM.771 UTC : Session 2 with
> | > | > | > | >> processId
> | > | > | > | >> 1384 is now the Symbol Creation Gem.
> | > | > | > | >> Session 3 with processId 1383 is now the Admin Gem.
> | > | > | > | >>
> | > | > | > | >> Session 4 with processId 1382 is now the Page
> | > | > | > | >> Reclaim
> | > | > | > | >> Gem
> | > | > | > | >> for
> | > | > | > | >> extents 0 through 0.
> | > | > | > | >>
> | > | > | > | >> --- 01/15/2012 06:16:58 PM UTC ---
> | > | > | > | >> Fatal Internal Error Notification from Gem, user =
> | > | > | > | >> DataCurator
> | > | > | > | >> Session = 6
> | > | > | > | >> Gem hostName = localhost , Gem processId = 1590,
> | > | > | > | >> current CommitRecord = 2376
> | > | > | > | >>
> | > | > | > | >> =======================================
> | > | > | > | >>
> | > | > | > | >> Any idea on how I can debug something like this? I
> | > | > | > | >> have no
> | > | > | > | >> idea
> | > | > | > | >> what happened.
> | > | > | > | >> There are no walkbacks in the Debug option on the
> | > | > | > | >> Gemtools
> | > | > | > | >> launcher. All I know is
> | > | > | > | >> that the user was clicking around with FIrefox and it
> | > | > | > | >> crashed.
> | > | > | > | >>
> | > | > | > | >> Furthermore, is there an easy way for me to restart my
> | > | > | > | >> Gems
> | > | > | > | >> once
> | > | > | > | >> they go down?
> | > | > | > | >> I start them with this:
> | > | > | > | >>
> | > | > | > | >> WAGemStoneRunSeasideGems default
> | > | > | > | >> name: 'Swazoo';
> | > | > | > | >> adaptorClass: WAGsSwazooAdaptor;
> | > | > | > | >> ports: #(8080).
> | > | > | > | >> WAGemStoneRunSeasideGems restartGems.
> | > | > | > | >>
> | > | > | > | >> After the crash, I restarted the Gems and the server
> | > | > | > | >> process
> | > | > | > | >> was
> | > | > | > | >> fine.
> | > | > | > | >>
> | > | > | > | >> Regards,
> | > | > | > | >>
> | > | > | > | >> Larry
> | > | > | > | >
> | > | > | > |
> | > | > | > |
> | > | > |
> | > | > |
> | > |
> | > |
> |
> |

Larry Kellogg

Help! Deleted files entry and all my formatting disappeared

Hello,
In preparation for deployment, I was deleted unused entry points from the config application,
and I deleted the files entry, causing all of my CSS formatting to disappear. I added it back
but my application hasn't gone back to the way it was.

What do I have to do to make that happen????

Larry

Larry Kellogg

Re: Help! Deleted files entry and all my formatting disappeared

Wow, what did I do? All of the Seaside graphics formatting is gone for me,
and the CSS I had used in a FileLibrary is no longer being read.
So, I just slammed my CSS into a style method on a top level component and
I got my CSS back.

How do I get the pretty Seaside graphics back for the config application?

My CSS is not final anyway, so it is not really a big deal. I guess I deleted too
many things from the Dispatcher, though, to get myself in this state...

Larry

On Feb 6, 2012, at 11:27 PM, Lawrence Kellogg wrote:

> Hello,
> In preparation for deployment, I was deleted unused entry points from the config application,
> and I deleted the files entry, causing all of my CSS formatting to disappear. I added it back
> but my application hasn't gone back to the way it was.
>
> What do I have to do to make that happen????
>
>
> Larry
>
>

Nick

Re: Help! Deleted files entry and all my formatting disappeared

Have a look at: WAEnvironment>>registerDefaultRequestHandlers

It contains the code which registers the file handler.

Though I use Nginx to serve files from the file system using a directive such as:

 server {
        listen       80;
        server_name  _;
	root /var/www;

       # first check the file system then try the image.
       location / {
          try_files $uri @seaside;
       }

On 7 February 2012 05:05, Lawrence Kellogg <[hidden email]> wrote:

Wow, what did I do? All of the Seaside graphics formatting is gone for me,
and the CSS I had used in a FileLibrary is no longer being read.
So, I just slammed my CSS into a style method on a top level component and
I got my CSS back.

How do I get the pretty Seaside graphics back for the config application?

My CSS is not final anyway, so it is not really a big deal. I guess I deleted too
many things from the Dispatcher, though, to get myself in this state...

Larry

On Feb 6, 2012, at 11:27 PM, Lawrence Kellogg wrote:

> Hello,
> In preparation for deployment, I was deleted unused entry points from the config application,
> and I deleted the files entry, causing all of my CSS formatting to disappear. I added it back
> but my application hasn't gone back to the way it was.
>
> What do I have to do to make that happen????
>
>
> Larry
>
>

Larry Kellogg

Re: Help! Deleted files entry and all my formatting disappeared

On Feb 7, 2012, at 4:17 AM, Nick Ager wrote:

Have a look at: WAEnvironment>>registerDefaultRequestHandlers
It contains the code which registers the file handler.

Thanks, Nick, This turned out to be a good thing as I want to get away from

the use of the FileLibrary and put everything in a directory for nginx to serve.

I have a directive like you have in my nginx.conf file.

Do I still need to set a resource base URL, or can I ignore that because

of this nginx option?

Larry

Though I use Nginx to serve files from the file system using a directive such as:

On 7 February 2012 05:05, Lawrence Kellogg <[hidden email]> wrote:

Wow, what did I do? All of the Seaside graphics formatting is gone for me,
and the CSS I had used in a FileLibrary is no longer being read.
So, I just slammed my CSS into a style method on a top level component and
I got my CSS back.

How do I get the pretty Seaside graphics back for the config application?

My CSS is not final anyway, so it is not really a big deal. I guess I deleted too
many things from the Dispatcher, though, to get myself in this state...

Larry

On Feb 6, 2012, at 11:27 PM, Lawrence Kellogg wrote:

> Hello,
> In preparation for deployment, I was deleted unused entry points from the config application,
> and I deleted the files entry, causing all of my CSS formatting to disappear. I added it back
> but my application hasn't gone back to the way it was.
>
> What do I have to do to make that happen????
>
>
> Larry
>
>

Nick

Re: Help! Deleted files entry and all my formatting disappeared

Hi Larry,

Do I still need to set a resource base URL, or can I ignore that because

of this nginx option?

personally I ignore #resourceUrl: and just use Nginx - but I must admit I didn't understand it's utility before I started using Nginx so I've never experimented with it. Perhaps others have had success with other configurations?

Nick

Johan Brichau-2

Re: Running SeasideGems, confusion

In reply to this post by Dale Henrichs

I experience the same behavior on the login screen, but I understand that as normal behavior: the session times out and a request for a timed-out session just starts a new one. The result is that the login page opens again.

Isn't that the default Seaside behavior and doesn't SS3 implement an #initialRequest: method to improve that behavior for SS3 browsing?

Johan

On 06 Feb 2012, at 18:07, Dale Henrichs wrote:

> Okay, I think I understand now ... I have seen the same behavior on SS3 ... when the session times out, the current page is refreshed instead of taking you all the way back to the default page ... I noticed this in SS3 and thought "that is a nice feature, because being taken back to the home page when timing out on a project page is quite annoying"...Perhaps it is a bug instead of a feature ...
>
> I haven't tracked that down to tell whether it is a feature or a bug ...
>
> Has anyone else noticed this behavior?
>
> Dale
>
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Sunday, February 5, 2012 7:51:44 PM
> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
> |
> | >
> | > |
> | > | I have noticed kind of a funny thing with regards to sessions.
> | > | After logging out, and going back to my login task, sometimes a
> | > | valid login attempt will just clear the fields and do nothing.
> | > | Hitting the new session button fixes this issue. Maybe I'm not
> | > | resetting something properly.
> | >
> | > I think I need a more explicit example of the problem to understand
> | > what might be happening.
> | >
> |
> | Dale,
> | Well, I think it is the session time out. Like I mentioned, I have
> | a login task for my
> | app. If I log in, and work, log out, I can log back in immediately
> | without the screen having
> | to be refreshed and generating a new session. But, if I am outside
> | the time out period, 20 minutes,
> | currently, then I have to hit the page a second time to log in.
> |
> | Do you think it is working as designed?
> |
> | Lawrence
> |
> |

Larry Kellogg

Re: Running SeasideGems, confusion

On Feb 7, 2012, at 2:19 PM, Johan Brichau wrote:

> I experience the same behavior on the login screen, but I understand that as normal behavior: the session times out and a request for a timed-out session just starts a new one. The result is that the login page opens again.
>
> Isn't that the default Seaside behavior and doesn't SS3 implement an #initialRequest: method to improve that behavior for SS3 browsing?
>

You know, now I am seeing sort of the opposite behavior, where a session stays up and active in my browser for hours.
Hmmm, did I delete something by accident?

This:

(WADispatcher default handlerAt: 'LoginTask') cache expiryPolicy configuration at: #cacheTimeout

returns 600 so I don't understand why the session is not being terminated. It's convenient to always have the
app active but not a good idea, I would think.

What is going on?

Larry

> Johan
>
> On 06 Feb 2012, at 18:07, Dale Henrichs wrote:
>
>> Okay, I think I understand now ... I have seen the same behavior on SS3 ... when the session times out, the current page is refreshed instead of taking you all the way back to the default page ... I noticed this in SS3 and thought "that is a nice feature, because being taken back to the home page when timing out on a project page is quite annoying"...Perhaps it is a bug instead of a feature ...
>>
>> I haven't tracked that down to tell whether it is a feature or a bug ...
>>
>> Has anyone else noticed this behavior?
>>
>> Dale
>>
>>
>> ----- Original Message -----
>> | From: "Lawrence Kellogg" <[hidden email]>
>> | To: "GemStone Seaside beta discussion" <[hidden email]>
>> | Sent: Sunday, February 5, 2012 7:51:44 PM
>> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
>> |
>> | >
>> | > |
>> | > | I have noticed kind of a funny thing with regards to sessions.
>> | > | After logging out, and going back to my login task, sometimes a
>> | > | valid login attempt will just clear the fields and do nothing.
>> | > | Hitting the new session button fixes this issue. Maybe I'm not
>> | > | resetting something properly.
>> | >
>> | > I think I need a more explicit example of the problem to understand
>> | > what might be happening.
>> | >
>> |
>> | Dale,
>> | Well, I think it is the session time out. Like I mentioned, I have
>> | a login task for my
>> | app. If I log in, and work, log out, I can log back in immediately
>> | without the screen having
>> | to be refreshed and generating a new session. But, if I am outside
>> | the time out period, 20 minutes,
>> | currently, then I have to hit the page a second time to log in.
>> |
>> | Do you think it is working as designed?
>> |
>> | Lawrence
>> |
>> |
>

Johan Brichau-2

Re: Running SeasideGems, confusion

Hi Lawrence,

On 08 Feb 2012, at 03:59, Lawrence Kellogg wrote:

> You know, now I am seeing sort of the opposite behavior, where a session stays up and active in my browser for hours.
> Hmmm, did I delete something by accident?

Seaside in Gemstone works a bit different for session expiry than Seaside in Pharo/Squeak.

In Gemstone, a separate gem process must explicitly expire Seaside sessions from the session cache. In the standard GLASS setup, this task is performed by the maintenance gem. So, you should check if your maintenance gem is running. The maintenance gem is started by the scripts delivered with GLASS. So running the following expression should start all seaside gems and the maintenance gems:

WAGemStoneRunSeasideGems restartGems.

You can also trigger session expiration manually. Look at the 'Seaside30' workspace when connected to the stone with a Gemtools session. There is the following expression that reaps the session cache:

WABasicDevelopment reapSeasideCache.

I must admit I do not remember why this difference exists with Pharo/Squeak versions.

Hope that helps!
Johan

123456