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

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

>  Well, my server has been up and running for days through nginx, with no problems.
> Tonight, it went down, for some reason, and I can't bring it back up. All I get is
> 502 Bad Gateway. If I bring up Swazoo, I can reach the server through 8080
> without any issues.
>
>  I found the following error, not sure if this is the problem.
>
>  Any thoughts?
>
>  Thanks,
>
>  Larry
>
> P.S. I updated my startSeaside30_Adaptor to this one but it doesn't seem to make any difference.
>
> http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor_2x
>
>
> Error log:
>
>
>
> USER IDS: REAL=seasideuser (500) EFFECTIVE=seasideuser (500)              |
> |_____________________________________________________________________________|
> topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 844/844
> [Info]: User ID: DataCurator
> [Info]: Repository: seaside
> [Info]: Session ID: 8
> [Info]: GCI Client Host: <Linked>
> [Info]: Page server PID: -1
> [Info]: Login Time: 01/23/2012 02:50:55 AM.595 UTC
> [01/23/2012 02:50:55 AM.631 UTC] gci login: currSession 1 rpc gem processId -1
> successful login
> topaz 1> topaz 1> [364925185 sz:3 cls: 114945 GsFile] a GsFile
>  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
>  pathName        [364925697 sz:67 cls: 74753 String] /opt/gemstone/product/seaside/data/WAFastCGIAdaptor_server-9001.pid
>  mode            [8827393 sz:1 cls: 74753 String] w
>
> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''wantsConnectionClose''> when sent to <nil> with arguments contained in <anArray( )>.'
> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-22T18:51:01.44046998023987-08:00
> MessageNotUnderstood 2010: No method was found for the selector <#'wantsConnectionClose'> when sent to <nil> with arguments contained in <anArray( )>.
> 1 GRGemStonePlatform >> logError:title:shouldCommit: @2 line 4  [GsMethod OOP 175180033]
> 2 GRGemStonePlatform >> logError:title: @2 line 3  [GsMethod OOP 175180289]
> 3 HTTPConnection >> internalError: @6 line 4  [GsMethod OOP 307703297]
> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 307706881]
> 5 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod OOP 10065153]
> 6 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP 10064641]
> 7 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
> 8 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
> 9 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14  [GsMethod OOP 10064641]
> 10 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12  [GsMethod OOP 10062081]
> 11 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP 2327041]
> 12 System class >> signal:args:signalDictionary: @5 line 13  [GsMethod OOP 3241473]
> 13 Object >> doesNotUnderstand: @6 line 14  [GsMethod OOP 1926913]
> 14 Object >> _doesNotUnderstand: @1 line 6  [GsMethod OOP 1926657]
> 15 HTTPConnection >> getAndDispatchMessages @12 line 10  [GsMethod OOP 319257089]
>
>
>
>
>
>
>
> 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].
>>
>> 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
>> | >
>> |
>> |
>

> Hi,
>
> Not sure I understand what is running on what port. If I read your log
> below correctly, you're starting an FCGI server on 9001. Not sure why
> Swazoo is complaining, I didn't think that Swazoo had much to do with
> a FCGI server.
>
>> From the nginx error, it appears as if you are doing a reverse proxy
> to a port that is not listening. Or are you running FCGI?
>
> Perhaps something like "sudo fuser -n tcp 8080" will tell you exactly
> what process is listening and you can trace from there.
>
> HTH
> Otto
>
> On Mon, Jan 23, 2012 at 5:42 AM, Lawrence Kellogg <[hidden email]> wrote:
>>  Well, my server has been up and running for days through nginx, with no problems.
>> Tonight, it went down, for some reason, and I can't bring it back up. All I get is
>> 502 Bad Gateway. If I bring up Swazoo, I can reach the server through 8080
>> without any issues.
>>
>>  I found the following error, not sure if this is the problem.
>>
>>  Any thoughts?
>>
>>  Thanks,
>>
>>  Larry
>>
>> P.S. I updated my startSeaside30_Adaptor to this one but it doesn't seem to make any difference.
>>
>> http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor_2x
>>
>>
>> Error log:
>>
>>
>>
>> USER IDS: REAL=seasideuser (500) EFFECTIVE=seasideuser (500)              |
>> |_____________________________________________________________________________|
>> topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 844/844
>> [Info]: User ID: DataCurator
>> [Info]: Repository: seaside
>> [Info]: Session ID: 8
>> [Info]: GCI Client Host: <Linked>
>> [Info]: Page server PID: -1
>> [Info]: Login Time: 01/23/2012 02:50:55 AM.595 UTC
>> [01/23/2012 02:50:55 AM.631 UTC] gci login: currSession 1 rpc gem processId -1
>> successful login
>> topaz 1> topaz 1> [364925185 sz:3 cls: 114945 GsFile] a GsFile
>>  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
>>  pathName        [364925697 sz:67 cls: 74753 String] /opt/gemstone/product/seaside/data/WAFastCGIAdaptor_server-9001.pid
>>  mode            [8827393 sz:1 cls: 74753 String] w
>>
>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''wantsConnectionClose''> when sent to <nil> with arguments contained in <anArray( )>.'
>> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
>> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-22T18:51:01.44046998023987-08:00
>> MessageNotUnderstood 2010: No method was found for the selector <#'wantsConnectionClose'> when sent to <nil> with arguments contained in <anArray( )>.
>> 1 GRGemStonePlatform >> logError:title:shouldCommit: @2 line 4  [GsMethod OOP 175180033]
>> 2 GRGemStonePlatform >> logError:title: @2 line 3  [GsMethod OOP 175180289]
>> 3 HTTPConnection >> internalError: @6 line 4  [GsMethod OOP 307703297]
>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 307706881]
>> 5 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod OOP 10065153]
>> 6 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP 10064641]
>> 7 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
>> 8 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
>> 9 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14  [GsMethod OOP 10064641]
>> 10 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12  [GsMethod OOP 10062081]
>> 11 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP 2327041]
>> 12 System class >> signal:args:signalDictionary: @5 line 13  [GsMethod OOP 3241473]
>> 13 Object >> doesNotUnderstand: @6 line 14  [GsMethod OOP 1926913]
>> 14 Object >> _doesNotUnderstand: @1 line 6  [GsMethod OOP 1926657]
>> 15 HTTPConnection >> getAndDispatchMessages @12 line 10  [GsMethod OOP 319257089]
>>
>>
>>
>>
>>
>>
>>
>> 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].
>>>
>>> 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
>>> | >
>>> |
>>> |
>>

>  Well, my server has been up and running for days through nginx, with no problems.
> Tonight, it went down, for some reason, and I can't bring it back up. All I get is
> 502 Bad Gateway. If I bring up Swazoo, I can reach the server through 8080
> without any issues.
>
>  I found the following error, not sure if this is the problem.
>
>  Any thoughts?
>
>  Thanks,
>
>  Larry
>
> P.S. I updated my startSeaside30_Adaptor to this one but it doesn't seem to make any difference.
>
> http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor_2x
>
>
> Error log:
>
>
>
> USER IDS: REAL=seasideuser (500) EFFECTIVE=seasideuser (500)              |
> |_____________________________________________________________________________|
> topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK client/gem GCI levels = 844/844
> [Info]: User ID: DataCurator
> [Info]: Repository: seaside
> [Info]: Session ID: 8
> [Info]: GCI Client Host: <Linked>
> [Info]: Page server PID: -1
> [Info]: Login Time: 01/23/2012 02:50:55 AM.595 UTC
> [01/23/2012 02:50:55 AM.631 UTC] gci login: currSession 1 rpc gem processId -1
> successful login
> topaz 1> topaz 1> [364925185 sz:3 cls: 114945 GsFile] a GsFile
>  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
>  pathName        [364925697 sz:67 cls: 74753 String] /opt/gemstone/product/seaside/data/WAFastCGIAdaptor_server-9001.pid
>  mode            [8827393 sz:1 cls: 74753 String] w
>
> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''wantsConnectionClose''> when sent to <nil> with arguments contained in <anArray( )>.'
> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-22T18:51:01.44046998023987-08:00
> MessageNotUnderstood 2010: No method was found for the selector <#'wantsConnectionClose'> when sent to <nil> with arguments contained in <anArray( )>.
> 1 GRGemStonePlatform >> logError:title:shouldCommit: @2 line 4  [GsMethod OOP 175180033]
> 2 GRGemStonePlatform >> logError:title: @2 line 3  [GsMethod OOP 175180289]
> 3 HTTPConnection >> internalError: @6 line 4  [GsMethod OOP 307703297]
> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 307706881]
> 5 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod OOP 10065153]
> 6 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP 10064641]
> 7 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
> 8 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
> 9 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14  [GsMethod OOP 10064641]
> 10 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12  [GsMethod OOP 10062081]
> 11 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP 2327041]
> 12 System class >> signal:args:signalDictionary: @5 line 13  [GsMethod OOP 3241473]
> 13 Object >> doesNotUnderstand: @6 line 14  [GsMethod OOP 1926913]
> 14 Object >> _doesNotUnderstand: @1 line 6  [GsMethod OOP 1926657]
> 15 HTTPConnection >> getAndDispatchMessages @12 line 10  [GsMethod OOP 319257089]
>
>
>
>
>
>
>
> 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].
>>
>> 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
>> | >
>> |
>> |
>

> When I want to run both FastCGI and Swazoo from the same server, I define WAGemStoneRunSeasideGems to use the FastCGI adaptor and then copy and modify the startSeaside30_Adaptor script to unconditionally start swazoo by replacing the lines:
>
>  GsFile gciLogServer: '$1 Server started on port ', $2 printString.
>  WAGemStoneRunSeasideGems startGemServerOn: $2.
>
> with the lines:
>
>  GsFile gciLogServer: '$1 Server started on port ', $2 printString.
>  GRPlatform current seasideLogServerStart: '$1' port: $2.
>  WAGsSwazooAdaptor startOn: $2.

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Sunday, January 22, 2012 7:42:05 PM
> | Subject: [GS/SS Beta] nginx error - 502 Bad Gateway
> |
> | Well, my server has been up and running for days through nginx, with
> | no problems.
> | Tonight, it went down, for some reason, and I can't bring it back up.
> | All I get is
> | 502 Bad Gateway. If I bring up Swazoo, I can reach the server through
> | 8080
> | without any issues.
> |
> |   I found the following error, not sure if this is the problem.
> |
> |   Any thoughts?
> |
> |   Thanks,
> |
> |   Larry
> |
> | P.S. I updated my startSeaside30_Adaptor to this one but it doesn't
> | seem to make any difference.
> |
> | http://code.google.com/p/glassdb/wiki/StartSeaside30_Adaptor_2x
> |
> |
> | Error log:
> |
> |
> |
> | USER IDS: REAL=seasideuser (500) EFFECTIVE=seasideuser (500)
> |              |
> | |_____________________________________________________________________________|
> | topaz> topaz> topaz> topaz> topaz> topaz> topaz> [Info]: LNK
> | client/gem GCI levels = 844/844
> | [Info]: User ID: DataCurator
> | [Info]: Repository: seaside
> | [Info]: Session ID: 8
> | [Info]: GCI Client Host: <Linked>
> | [Info]: Page server PID: -1
> | [Info]: Login Time: 01/23/2012 02:50:55 AM.595 UTC
> | [01/23/2012 02:50:55 AM.631 UTC] gci login: currSession 1 rpc gem
> | processId -1
> | successful login
> | topaz 1> topaz 1> [364925185 sz:3 cls: 114945 GsFile] a GsFile
> |   isClient        [2 sz:0 cls: 74241 SmallInteger] 0
> |   pathName        [364925697 sz:67 cls: 74753 String]
> |   /opt/gemstone/product/seaside/data/WAFastCGIAdaptor_server-9001.pid
> |   mode            [8827393 sz:1 cls: 74753 String] w
> |
> | topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> | --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No
> | method was found for the selector <#''wantsConnectionClose''> when
> | sent to <nil> with arguments contained in <anArray( )>.'
> | ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
> | ----------- Swazoo2 Internal Error ERROR Encountered:
> | 2012-01-22T18:51:01.44046998023987-08:00
> | MessageNotUnderstood 2010: No method was found for the selector
> | <#'wantsConnectionClose'> when sent to <nil> with arguments
> | contained in <anArray( )>.
> | 1 GRGemStonePlatform >> logError:title:shouldCommit: @2 line 4
> |  [GsMethod OOP 175180033]
> | 2 GRGemStonePlatform >> logError:title: @2 line 3  [GsMethod OOP
> | 175180289]
> | 3 HTTPConnection >> internalError: @6 line 4  [GsMethod OOP
> | 307703297]
> | 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod
> | OOP 307706881]
> | 5 ExceptionHandler >> caughtExceptionWithAction: @5 line 4  [GsMethod
> | OOP 10065153]
> | 6 ComplexBlock in ExceptionHandler >>
> | caughtEx:number:cat:args:handler: @12 line 13  [GsMethod OOP
> | 10064641]
> | 7 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod
> | OOP 2304001]
> | 8 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod
> | OOP 2304001]
> | 9 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14
> |  [GsMethod OOP 10064641]
> | 10 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12
> |  [GsMethod OOP 10062081]
> | 11 Exception >> _signal:number:args: @2 line 7  [GsMethod OOP
> | 2327041]
> | 12 System class >> signal:args:signalDictionary: @5 line 13
> |  [GsMethod OOP 3241473]
> | 13 Object >> doesNotUnderstand: @6 line 14  [GsMethod OOP 1926913]
> | 14 Object >> _doesNotUnderstand: @1 line 6  [GsMethod OOP 1926657]
> | 15 HTTPConnection >> getAndDispatchMessages @12 line 10  [GsMethod
> | OOP 319257089]
> |
> |
> |
> |
> |
> |
> |
> | 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].
> | >
> | > 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
> | > | >
> | > |
> | > |
> |
> |

>
> On Jan 23, 2012, at 12:23 PM, Dale Henrichs wrote:
>
>> Lawrence,
>>
>> The stack that you are getting is from Swazoo (HTTPConnection is a Swazoo class), but the script thinks you should be running the
>> WAFastCGIAdaptor, which is very strange ... So Off the top of my head, I'd guess that the error you are getting is what happens when swazoo tries to read a FastCGI stream...
>>
>> You should check to see the value of `WAGemStoneRunSeasideGems default`, because something may have gotten confused when you tried to run both Swazoo and FastCGI Seaside servers at the same time ...
>>
>
> Dale,
>  The default is WAGemStoneRunSeasideGems port: 8080.

> Lawrence,
>
> The 'Bad Gateway' message is probably coming from the fact that you are still not running a fastcgi server on the correct port and possibly running a swazoo server on the port that is supposed to be fastcgi.
>
> To get to the bottom of this we probably need to make sure that there are no other gems running seaside adaptors:
>
>  ps -efw | grep topaz
>
> should list all of the topaz sessions.
>
> For completeness you should logout of any GemTools images that are running and then login again for a fresh GemTools instance.
>
> Next you should delete all of the seaside server logs (or mv to a backup directory if you want to keep the logs):
>
>  rm /opt/gemstone/log/*_server-*.log
>
> Now start up your fastcgi server(s) and hit the site with a request. If you are still getting the error kill each of the seaside servers and send mail with the complete server logs (*_server-*.log) attached and we will go from there.
>

> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Monday, January 23, 2012 11:06:27 AM
> | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> |
> |
> |
> |
> | On Jan 23, 2012, at 1:14 PM, Dale Henrichs wrote:
> |
> |
> |
> | Lawrence,
> |
> | The reason that the FastCGI server is not working is that you have
> | set the default server to be WAGsSwazooAdaptor. The standard script
> | uses `WAGemStoneRunSeasideGems default`, which is set to
> | WAGsSwazooAdaptor and that means that your gem that is listening on
> | the FastCGI ports (9001-9003) are using the Swazoo adaptor and not
> | the FastCGI adaptor as they should. Evaluate the following to reset
> | the default adaptor to be FastCGI:
> |
> | WAGemStoneRunSeasideGems default
> | name: 'FastCGI';
> | adaptorClass: WAFastCGIAdaptor;
> | ports: #(9001 9002 9003).
> |
> | Then create a new script using the changes I suggested in my last
> | email to create a swazoo script ...
> |
> | The point of WAGemStoneRunSeasideGems is to allow one to use a single
> | script to run a variety of adaptors. If you intend to run more than
> | one adaptor, then you need to customize your scripts.
> |
> |
> |
> |
> |
> |
> | I'm confused. Why does it matter what the default is when the
> | processes are listening on different ports?
> |
> |
> | Before, I was starting WAFastCGIAdaptor on 9001 from this command
> | line:
> |
> |
> |
> | runSeasideGems30 start WAFastCGIAdaptor 9001
> |
> |
> | and then starting Swazoo from within a workspace in the image with
> | this:
> |
> |
> |
> | WAGemStoneRunSeasideGems default
> | name: 'Swazoo';
> | adaptorClass: WAGsSwazooAdaptor;
> | ports: #(8080).
> | WAGemStoneRunSeasideGems restartGems.
> |
> |
> |
> |
> | I had it working. I guess I don't remember how i got it to work. ;-)
> |
> |
> | Anyway, shutting everything down and then just bringing up
> | WAFastCGIAdaptor on 9001,
> | after resetting the default, as you suggested, still yields a Bad
> | Gateway message.
> |
> |
> | I'm missing something...
> |
> |
> |
> |
> |
> |
> | Larry
> |
> |
> |
> |
> |
> |
> |
> | Dale
> |
> | ----- Original Message -----
> | | From: "Lawrence Kellogg" < [hidden email] >
> | | To: "GemStone Seaside beta discussion" < [hidden email]
> | | >
> | | Sent: Monday, January 23, 2012 9:55:47 AM
> | | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | |
> | |
> | | On Jan 23, 2012, at 12:50 PM, Lawrence Kellogg wrote:
> | |
> | | >
> | | > On Jan 23, 2012, at 12:23 PM, Dale Henrichs wrote:
> | | >
> | | >> Lawrence,
> | | >>
> | | >> The stack that you are getting is from Swazoo (HTTPConnection is
> | | >> a
> | | >> Swazoo class), but the script thinks you should be running the
> | | >> WAFastCGIAdaptor, which is very strange ... So Off the top of my
> | | >> head, I'd guess that the error you are getting is what happens
> | | >> when swazoo tries to read a FastCGI stream...
> | | >>
> | | >> You should check to see the value of `WAGemStoneRunSeasideGems
> | | >> default`, because something may have gotten confused when you
> | | >> tried to run both Swazoo and FastCGI Seaside servers at the same
> | | >> time ...
> | | >>
> | | >
> | | > Dale,
> | | > The default is WAGemStoneRunSeasideGems port: 8080.
> | |
> | | Sorry, I meant WAGsSwazooAdaptor on port: 8080
> | |
> | | Larry
> | |
> |
> |

> Lawrence,
>
> Excellent! ... My pleasure...
>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Tuesday, January 24, 2012 1:05:18 PM
> | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> |
> |
> | On Jan 23, 2012, at 2:36 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > The 'Bad Gateway' message is probably coming from the fact that you
> | > are still not running a fastcgi server on the correct port and
> | > possibly running a swazoo server on the port that is supposed to
> | > be fastcgi.
> | >
> | > To get to the bottom of this we probably need to make sure that
> | > there are no other gems running seaside adaptors:
> | >
> | >  ps -efw | grep topaz
> | >
> | > should list all of the topaz sessions.
> | >
> | > For completeness you should logout of any GemTools images that are
> | > running and then login again for a fresh GemTools instance.
> | >
> | > Next you should delete all of the seaside server logs (or mv to a
> | > backup directory if you want to keep the logs):
> | >
> | >  rm /opt/gemstone/log/*_server-*.log
> | >
> | > Now start up your fastcgi server(s) and hit the site with a
> | > request. If you are still getting the error kill each of the
> | > seaside servers and send mail with the complete server logs
> | > (*_server-*.log) attached and we will go from there.
> | >
> |
> |   Thanks, Dale, I got it working again by making sure everything was
> |   shutdown and starting over.
> | As soon as I get my one user off of Swazoo, I won't have to deal with
> | it anymore, I'll just use the
> | FastCGI connection through nginx.
> |
> |   Thanks for your help and for your patience. Much appreciated.
> |
> |   Regards,
> |
> |   Larry
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Monday, January 23, 2012 11:06:27 AM
> | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > |
> | > |
> | > |
> | > |
> | > | On Jan 23, 2012, at 1:14 PM, Dale Henrichs wrote:
> | > |
> | > |
> | > |
> | > | Lawrence,
> | > |
> | > | The reason that the FastCGI server is not working is that you
> | > | have
> | > | set the default server to be WAGsSwazooAdaptor. The standard
> | > | script
> | > | uses `WAGemStoneRunSeasideGems default`, which is set to
> | > | WAGsSwazooAdaptor and that means that your gem that is listening
> | > | on
> | > | the FastCGI ports (9001-9003) are using the Swazoo adaptor and
> | > | not
> | > | the FastCGI adaptor as they should. Evaluate the following to
> | > | reset
> | > | the default adaptor to be FastCGI:
> | > |
> | > | WAGemStoneRunSeasideGems default
> | > | name: 'FastCGI';
> | > | adaptorClass: WAFastCGIAdaptor;
> | > | ports: #(9001 9002 9003).
> | > |
> | > | Then create a new script using the changes I suggested in my last
> | > | email to create a swazoo script ...
> | > |
> | > | The point of WAGemStoneRunSeasideGems is to allow one to use a
> | > | single
> | > | script to run a variety of adaptors. If you intend to run more
> | > | than
> | > | one adaptor, then you need to customize your scripts.
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> | > | I'm confused. Why does it matter what the default is when the
> | > | processes are listening on different ports?
> | > |
> | > |
> | > | Before, I was starting WAFastCGIAdaptor on 9001 from this command
> | > | line:
> | > |
> | > |
> | > |
> | > | runSeasideGems30 start WAFastCGIAdaptor 9001
> | > |
> | > |
> | > | and then starting Swazoo from within a workspace in the image
> | > | with
> | > | this:
> | > |
> | > |
> | > |
> | > | WAGemStoneRunSeasideGems default
> | > | name: 'Swazoo';
> | > | adaptorClass: WAGsSwazooAdaptor;
> | > | ports: #(8080).
> | > | WAGemStoneRunSeasideGems restartGems.
> | > |
> | > |
> | > |
> | > |
> | > | I had it working. I guess I don't remember how i got it to work.
> | > | ;-)
> | > |
> | > |
> | > | Anyway, shutting everything down and then just bringing up
> | > | WAFastCGIAdaptor on 9001,
> | > | after resetting the default, as you suggested, still yields a Bad
> | > | Gateway message.
> | > |
> | > |
> | > | I'm missing something...
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> | > | Larry
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> | > | Dale
> | > |
> | > | ----- Original Message -----
> | > | | From: "Lawrence Kellogg" < [hidden email] >
> | > | | To: "GemStone Seaside beta discussion" <
> | > | | [hidden email]
> | > | | >
> | > | | Sent: Monday, January 23, 2012 9:55:47 AM
> | > | | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | |
> | > | |
> | > | | On Jan 23, 2012, at 12:50 PM, Lawrence Kellogg wrote:
> | > | |
> | > | | >
> | > | | > On Jan 23, 2012, at 12:23 PM, Dale Henrichs wrote:
> | > | | >
> | > | | >> Lawrence,
> | > | | >>
> | > | | >> The stack that you are getting is from Swazoo
> | > | | >> (HTTPConnection is
> | > | | >> a
> | > | | >> Swazoo class), but the script thinks you should be running
> | > | | >> the
> | > | | >> WAFastCGIAdaptor, which is very strange ... So Off the top
> | > | | >> of my
> | > | | >> head, I'd guess that the error you are getting is what
> | > | | >> happens
> | > | | >> when swazoo tries to read a FastCGI stream...
> | > | | >>
> | > | | >> You should check to see the value of
> | > | | >> `WAGemStoneRunSeasideGems
> | > | | >> default`, because something may have gotten confused when
> | > | | >> you
> | > | | >> tried to run both Swazoo and FastCGI Seaside servers at the
> | > | | >> same
> | > | | >> time ...
> | > | | >>
> | > | | >
> | > | | > Dale,
> | > | | > The default is WAGemStoneRunSeasideGems port: 8080.
> | > | |
> | > | | Sorry, I meant WAGsSwazooAdaptor on port: 8080
> | > | |
> | > | | Larry
> | > | |
> | > |
> | > |
> |
> |

> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Saturday, January 28, 2012 2:52:54 PM
> | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway with a new twist
> |
> | Sigh, back to a Bad Gateway errors.
> |
> | The heartbreaking part of this problem is that all of the connections
> | were working for about 3-4 calls before the Bad Gateway message
> | popped up again.
> |
> | My Amazon service is still up and running according to the
> | diagnostics
> | and I can log into the box.
> |
> |   I get a connection refused error in my nginx.log
> |
> | 2012/01/28 22:35:54 [error] 14525#0: *5 connect() failed (111:
> | Connection refused) while connecting to upstream,
> |
> | and there are no *_server-*.log error messages in the Gemstone
> | directory.
> |
> | I have tried bringing down everything and restarting, to no avail.
> |
> |   Any ideas on this error?
> |
> |   Larry
> |
> |
> |
> |
> | On Jan 24, 2012, at 4:33 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > Excellent! ... My pleasure...
> | >
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Tuesday, January 24, 2012 1:05:18 PM
> | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > |
> | > |
> | > | On Jan 23, 2012, at 2:36 PM, Dale Henrichs wrote:
> | > |
> | > | > Lawrence,
> | > | >
> | > | > The 'Bad Gateway' message is probably coming from the fact that
> | > | > you
> | > | > are still not running a fastcgi server on the correct port and
> | > | > possibly running a swazoo server on the port that is supposed
> | > | > to
> | > | > be fastcgi.
> | > | >
> | > | > To get to the bottom of this we probably need to make sure that
> | > | > there are no other gems running seaside adaptors:
> | > | >
> | > | >  ps -efw | grep topaz
> | > | >
> | > | > should list all of the topaz sessions.
> | > | >
> | > | > For completeness you should logout of any GemTools images that
> | > | > are
> | > | > running and then login again for a fresh GemTools instance.
> | > | >
> | > | > Next you should delete all of the seaside server logs (or mv to
> | > | > a
> | > | > backup directory if you want to keep the logs):
> | > | >
> | > | >  rm /opt/gemstone/log/*_server-*.log
> | > | >
> | > | > Now start up your fastcgi server(s) and hit the site with a
> | > | > request. If you are still getting the error kill each of the
> | > | > seaside servers and send mail with the complete server logs
> | > | > (*_server-*.log) attached and we will go from there.
> | > | >
> | > |
> | > |   Thanks, Dale, I got it working again by making sure everything
> | > |   was
> | > |   shutdown and starting over.
> | > | As soon as I get my one user off of Swazoo, I won't have to deal
> | > | with
> | > | it anymore, I'll just use the
> | > | FastCGI connection through nginx.
> | > |
> | > |   Thanks for your help and for your patience. Much appreciated.
> | > |
> | > |   Regards,
> | > |
> | > |   Larry
> | > |
> | > | > Dale
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | To: "GemStone Seaside beta discussion"
> | > | > | <[hidden email]>
> | > | > | Sent: Monday, January 23, 2012 11:06:27 AM
> | > | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | On Jan 23, 2012, at 1:14 PM, Dale Henrichs wrote:
> | > | > |
> | > | > |
> | > | > |
> | > | > | Lawrence,
> | > | > |
> | > | > | The reason that the FastCGI server is not working is that you
> | > | > | have
> | > | > | set the default server to be WAGsSwazooAdaptor. The standard
> | > | > | script
> | > | > | uses `WAGemStoneRunSeasideGems default`, which is set to
> | > | > | WAGsSwazooAdaptor and that means that your gem that is
> | > | > | listening
> | > | > | on
> | > | > | the FastCGI ports (9001-9003) are using the Swazoo adaptor
> | > | > | and
> | > | > | not
> | > | > | the FastCGI adaptor as they should. Evaluate the following to
> | > | > | reset
> | > | > | the default adaptor to be FastCGI:
> | > | > |
> | > | > | WAGemStoneRunSeasideGems default
> | > | > | name: 'FastCGI';
> | > | > | adaptorClass: WAFastCGIAdaptor;
> | > | > | ports: #(9001 9002 9003).
> | > | > |
> | > | > | Then create a new script using the changes I suggested in my
> | > | > | last
> | > | > | email to create a swazoo script ...
> | > | > |
> | > | > | The point of WAGemStoneRunSeasideGems is to allow one to use
> | > | > | a
> | > | > | single
> | > | > | script to run a variety of adaptors. If you intend to run
> | > | > | more
> | > | > | than
> | > | > | one adaptor, then you need to customize your scripts.
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | I'm confused. Why does it matter what the default is when the
> | > | > | processes are listening on different ports?
> | > | > |
> | > | > |
> | > | > | Before, I was starting WAFastCGIAdaptor on 9001 from this
> | > | > | command
> | > | > | line:
> | > | > |
> | > | > |
> | > | > |
> | > | > | runSeasideGems30 start WAFastCGIAdaptor 9001
> | > | > |
> | > | > |
> | > | > | and then starting Swazoo from within a workspace in the image
> | > | > | with
> | > | > | this:
> | > | > |
> | > | > |
> | > | > |
> | > | > | WAGemStoneRunSeasideGems default
> | > | > | name: 'Swazoo';
> | > | > | adaptorClass: WAGsSwazooAdaptor;
> | > | > | ports: #(8080).
> | > | > | WAGemStoneRunSeasideGems restartGems.
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | I had it working. I guess I don't remember how i got it to
> | > | > | work.
> | > | > | ;-)
> | > | > |
> | > | > |
> | > | > | Anyway, shutting everything down and then just bringing up
> | > | > | WAFastCGIAdaptor on 9001,
> | > | > | after resetting the default, as you suggested, still yields a
> | > | > | Bad
> | > | > | Gateway message.
> | > | > |
> | > | > |
> | > | > | I'm missing something...
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | Larry
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > |
> | > | > | Dale
> | > | > |
> | > | > | ----- Original Message -----
> | > | > | | From: "Lawrence Kellogg" < [hidden email] >
> | > | > | | To: "GemStone Seaside beta discussion" <
> | > | > | | [hidden email]
> | > | > | | >
> | > | > | | Sent: Monday, January 23, 2012 9:55:47 AM
> | > | > | | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | > | |
> | > | > | |
> | > | > | | On Jan 23, 2012, at 12:50 PM, Lawrence Kellogg wrote:
> | > | > | |
> | > | > | | >
> | > | > | | > On Jan 23, 2012, at 12:23 PM, Dale Henrichs wrote:
> | > | > | | >
> | > | > | | >> Lawrence,
> | > | > | | >>
> | > | > | | >> The stack that you are getting is from Swazoo
> | > | > | | >> (HTTPConnection is
> | > | > | | >> a
> | > | > | | >> Swazoo class), but the script thinks you should be
> | > | > | | >> running
> | > | > | | >> the
> | > | > | | >> WAFastCGIAdaptor, which is very strange ... So Off the
> | > | > | | >> top
> | > | > | | >> of my
> | > | > | | >> head, I'd guess that the error you are getting is what
> | > | > | | >> happens
> | > | > | | >> when swazoo tries to read a FastCGI stream...
> | > | > | | >>
> | > | > | | >> You should check to see the value of
> | > | > | | >> `WAGemStoneRunSeasideGems
> | > | > | | >> default`, because something may have gotten confused
> | > | > | | >> when
> | > | > | | >> you
> | > | > | | >> tried to run both Swazoo and FastCGI Seaside servers at
> | > | > | | >> the
> | > | > | | >> same
> | > | > | | >> time ...
> | > | > | | >>
> | > | > | | >
> | > | > | | > Dale,
> | > | > | | > The default is WAGemStoneRunSeasideGems port: 8080.
> | > | > | |
> | > | > | | Sorry, I meant WAGsSwazooAdaptor on port: 8080
> | > | > | |
> | > | > | | Larry
> | > | > | |
> | > | > |
> | > | > |
> | > |
> | > |
> |
> |

>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Saturday, January 28, 2012 3:39:08 PM
> | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway with a new twist
> |
> | Dale.
> |
> | On Jan 28, 2012, at 6:30 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > Did you make sure that all of the gem and topaz processes had
> | > shutdown when you cycled the stone?
> | >
> |
> |   Yes, I did, there are not gem or topaz sessions when I start back
> |   up.
> |
> | > Other than that it still sounds like you don't have FastCGI gems
> | > listening on the correct ports ... shut down stone, clear out log
> | > files, ensure that gem and topaz processes gone, start system ...
> | > if you are still having trouble zip up the fastcgi and swazoo
> | > server logs and let me take a peek...
> | >
> |
> |   The thing is, this is the machine image where I have never run
> |   Swazoo. I has been up for a week or so on nginx.
> | I loaded some new code today, and I was running from a web browser
> | for twenty minutes without any problems.
> | Then, I accessed the site from a mobile app, which also worked ok for
> | a bit, and then, boom, bad gateway from nginx and I can't reach it
> | from anywhere.
> |
> |   There are no FastCGI or Swazoo _server* log files created when I
> |   get this error. Since I moved all those logs into a backup,
> | I know there are no new ones. I only have that nginx.log
> |
> |   I can send that file to you...
> |
> |   Thanks...
> |
> |   Larry
> |
> |
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Saturday, January 28, 2012 2:52:54 PM
> | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway with a
> | > | new twist
> | > |
> | > | Sigh, back to a Bad Gateway errors.
> | > |
> | > | The heartbreaking part of this problem is that all of the
> | > | connections
> | > | were working for about 3-4 calls before the Bad Gateway message
> | > | popped up again.
> | > |
> | > | My Amazon service is still up and running according to the
> | > | diagnostics
> | > | and I can log into the box.
> | > |
> | > |   I get a connection refused error in my nginx.log
> | > |
> | > | 2012/01/28 22:35:54 [error] 14525#0: *5 connect() failed (111:
> | > | Connection refused) while connecting to upstream,
> | > |
> | > | and there are no *_server-*.log error messages in the Gemstone
> | > | directory.
> | > |
> | > | I have tried bringing down everything and restarting, to no
> | > | avail.
> | > |
> | > |   Any ideas on this error?
> | > |
> | > |   Larry
> | > |
> | > |
> | > |
> | > |
> | > | On Jan 24, 2012, at 4:33 PM, Dale Henrichs wrote:
> | > |
> | > | > Lawrence,
> | > | >
> | > | > Excellent! ... My pleasure...
> | > | >
> | > | > Dale
> | > | >
> | > | > ----- Original Message -----
> | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | To: "GemStone Seaside beta discussion"
> | > | > | <[hidden email]>
> | > | > | Sent: Tuesday, January 24, 2012 1:05:18 PM
> | > | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | > |
> | > | > |
> | > | > | On Jan 23, 2012, at 2:36 PM, Dale Henrichs wrote:
> | > | > |
> | > | > | > Lawrence,
> | > | > | >
> | > | > | > The 'Bad Gateway' message is probably coming from the fact
> | > | > | > that
> | > | > | > you
> | > | > | > are still not running a fastcgi server on the correct port
> | > | > | > and
> | > | > | > possibly running a swazoo server on the port that is
> | > | > | > supposed
> | > | > | > to
> | > | > | > be fastcgi.
> | > | > | >
> | > | > | > To get to the bottom of this we probably need to make sure
> | > | > | > that
> | > | > | > there are no other gems running seaside adaptors:
> | > | > | >
> | > | > | >  ps -efw | grep topaz
> | > | > | >
> | > | > | > should list all of the topaz sessions.
> | > | > | >
> | > | > | > For completeness you should logout of any GemTools images
> | > | > | > that
> | > | > | > are
> | > | > | > running and then login again for a fresh GemTools instance.
> | > | > | >
> | > | > | > Next you should delete all of the seaside server logs (or
> | > | > | > mv to
> | > | > | > a
> | > | > | > backup directory if you want to keep the logs):
> | > | > | >
> | > | > | >  rm /opt/gemstone/log/*_server-*.log
> | > | > | >
> | > | > | > Now start up your fastcgi server(s) and hit the site with a
> | > | > | > request. If you are still getting the error kill each of
> | > | > | > the
> | > | > | > seaside servers and send mail with the complete server logs
> | > | > | > (*_server-*.log) attached and we will go from there.
> | > | > | >
> | > | > |
> | > | > |   Thanks, Dale, I got it working again by making sure
> | > | > |   everything
> | > | > |   was
> | > | > |   shutdown and starting over.
> | > | > | As soon as I get my one user off of Swazoo, I won't have to
> | > | > | deal
> | > | > | with
> | > | > | it anymore, I'll just use the
> | > | > | FastCGI connection through nginx.
> | > | > |
> | > | > |   Thanks for your help and for your patience. Much
> | > | > |   appreciated.
> | > | > |
> | > | > |   Regards,
> | > | > |
> | > | > |   Larry
> | > | > |
> | > | > | > Dale
> | > | > | >
> | > | > | > ----- Original Message -----
> | > | > | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | > | > | To: "GemStone Seaside beta discussion"
> | > | > | > | <[hidden email]>
> | > | > | > | Sent: Monday, January 23, 2012 11:06:27 AM
> | > | > | > | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | On Jan 23, 2012, at 1:14 PM, Dale Henrichs wrote:
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | Lawrence,
> | > | > | > |
> | > | > | > | The reason that the FastCGI server is not working is that
> | > | > | > | you
> | > | > | > | have
> | > | > | > | set the default server to be WAGsSwazooAdaptor. The
> | > | > | > | standard
> | > | > | > | script
> | > | > | > | uses `WAGemStoneRunSeasideGems default`, which is set to
> | > | > | > | WAGsSwazooAdaptor and that means that your gem that is
> | > | > | > | listening
> | > | > | > | on
> | > | > | > | the FastCGI ports (9001-9003) are using the Swazoo
> | > | > | > | adaptor
> | > | > | > | and
> | > | > | > | not
> | > | > | > | the FastCGI adaptor as they should. Evaluate the
> | > | > | > | following to
> | > | > | > | reset
> | > | > | > | the default adaptor to be FastCGI:
> | > | > | > |
> | > | > | > | WAGemStoneRunSeasideGems default
> | > | > | > | name: 'FastCGI';
> | > | > | > | adaptorClass: WAFastCGIAdaptor;
> | > | > | > | ports: #(9001 9002 9003).
> | > | > | > |
> | > | > | > | Then create a new script using the changes I suggested in
> | > | > | > | my
> | > | > | > | last
> | > | > | > | email to create a swazoo script ...
> | > | > | > |
> | > | > | > | The point of WAGemStoneRunSeasideGems is to allow one to
> | > | > | > | use
> | > | > | > | a
> | > | > | > | single
> | > | > | > | script to run a variety of adaptors. If you intend to run
> | > | > | > | more
> | > | > | > | than
> | > | > | > | one adaptor, then you need to customize your scripts.
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | I'm confused. Why does it matter what the default is when
> | > | > | > | the
> | > | > | > | processes are listening on different ports?
> | > | > | > |
> | > | > | > |
> | > | > | > | Before, I was starting WAFastCGIAdaptor on 9001 from this
> | > | > | > | command
> | > | > | > | line:
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | runSeasideGems30 start WAFastCGIAdaptor 9001
> | > | > | > |
> | > | > | > |
> | > | > | > | and then starting Swazoo from within a workspace in the
> | > | > | > | image
> | > | > | > | with
> | > | > | > | this:
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | WAGemStoneRunSeasideGems default
> | > | > | > | name: 'Swazoo';
> | > | > | > | adaptorClass: WAGsSwazooAdaptor;
> | > | > | > | ports: #(8080).
> | > | > | > | WAGemStoneRunSeasideGems restartGems.
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | I had it working. I guess I don't remember how i got it
> | > | > | > | to
> | > | > | > | work.
> | > | > | > | ;-)
> | > | > | > |
> | > | > | > |
> | > | > | > | Anyway, shutting everything down and then just bringing
> | > | > | > | up
> | > | > | > | WAFastCGIAdaptor on 9001,
> | > | > | > | after resetting the default, as you suggested, still
> | > | > | > | yields a
> | > | > | > | Bad
> | > | > | > | Gateway message.
> | > | > | > |
> | > | > | > |
> | > | > | > | I'm missing something...
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | Larry
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > |
> | > | > | > | Dale
> | > | > | > |
> | > | > | > | ----- Original Message -----
> | > | > | > | | From: "Lawrence Kellogg" < [hidden email] >
> | > | > | > | | To: "GemStone Seaside beta discussion" <
> | > | > | > | | [hidden email]
> | > | > | > | | >
> | > | > | > | | Sent: Monday, January 23, 2012 9:55:47 AM
> | > | > | > | | Subject: Re: [GS/SS Beta] nginx error - 502 Bad Gateway
> | > | > | > | |
> | > | > | > | |
> | > | > | > | | On Jan 23, 2012, at 12:50 PM, Lawrence Kellogg wrote:
> | > | > | > | |
> | > | > | > | | >
> | > | > | > | | > On Jan 23, 2012, at 12:23 PM, Dale Henrichs wrote:
> | > | > | > | | >
> | > | > | > | | >> Lawrence,
> | > | > | > | | >>
> | > | > | > | | >> The stack that you are getting is from Swazoo
> | > | > | > | | >> (HTTPConnection is
> | > | > | > | | >> a
> | > | > | > | | >> Swazoo class), but the script thinks you should be
> | > | > | > | | >> running
> | > | > | > | | >> the
> | > | > | > | | >> WAFastCGIAdaptor, which is very strange ... So Off
> | > | > | > | | >> the
> | > | > | > | | >> top
> | > | > | > | | >> of my
> | > | > | > | | >> head, I'd guess that the error you are getting is
> | > | > | > | | >> what
> | > | > | > | | >> happens
> | > | > | > | | >> when swazoo tries to read a FastCGI stream...
> | > | > | > | | >>
> | > | > | > | | >> You should check to see the value of
> | > | > | > | | >> `WAGemStoneRunSeasideGems
> | > | > | > | | >> default`, because something may have gotten confused
> | > | > | > | | >> when
> | > | > | > | | >> you
> | > | > | > | | >> tried to run both Swazoo and FastCGI Seaside servers
> | > | > | > | | >> at
> | > | > | > | | >> the
> | > | > | > | | >> same
> | > | > | > | | >> time ...
> | > | > | > | | >>
> | > | > | > | | >
> | > | > | > | | > Dale,
> | > | > | > | | > The default is WAGemStoneRunSeasideGems port: 8080.
> | > | > | > | |
> | > | > | > | | Sorry, I meant WAGsSwazooAdaptor on port: 8080
> | > | > | > | |
> | > | > | > | | Larry
> | > | > | > | |
> | > | > | > |
> | > | > | > |
> | > | > |
> | > | > |
> | > |
> | > |
> |
> |

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

> 2012/1/29 Lawrence Kellogg <[hidden email]>:
>> 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.
>
> Do you at any point create "empty" users?