Smalltalk › Gemtalk › GLASS

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

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 111 messages Options
123456
Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg

On Jan 16, 2012, at 3:33 PM, Johan Brichau wrote:

> Larry,
>
> You can use FastCGI with Apache as well: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
> There is no need to switch to Nginx for that.
>
> But you cannot connect to the fastcgi port with your webbrowser, simply because a FastCGI adaptor does not serve http.
> Instead, it serves the FastCGI protocol, which is understood by the fastcgi module of your front-end webserver. In turn, the front-end webserver, will serve http.
>
> So, the link in your iframe can never work if port 9001 is serving FastCGI.
>

  Ok, so, how does my iframe refer to the content being served by Seaside?
I'm a little unclear on the connections. Is it..

It works with:

User---->Apache:80----->iframe:Seaside:8080

but with FAST CGI it would be

User---->Apache:80--->Apache:FastCGI:9001--->Seaside FAST CGI Gems running on 9001??

Is that right?

I did CGI programming years and years ago. Sorry, I'm a little puzzled.

  Larry




> Johan
>
> On 16 Jan 2012, at 21:27, Lawrence Kellogg wrote:
>
>> Johan,
>>
>> On Jan 16, 2012, at 2:53 PM, Johan Brichau wrote:
>>
>>> Larry,
>>>
>>> Are you trying to connect to port 9001 from your webbrowser?
>>>
>>
>> Yes, well, from within an index.html file that was being served up by an Apache server, from within an
>> iFrame, like this:
>>
>> <body class="borderless">
>> <iframe src="http://myseasideserver.com:9001"
>> name="myapp" width="795" marginwidth="0" height="880" marginheight="0" scrolling="no" frameborder="0" class="borderless"></iframe>
>> </body>
>>
>> I guess this is not legit.
>>
>>
>>> If yes: Swazoo and FastCGI adaptors are different kinds of servers.
>>>
>>> A Swazoo adaptor brings up an http server, which you can directly connect to from your webbrowser.
>>> A FastCGI adaptor brings up a FastCGI server, which can only be connected to via a front-end http server (such as apache, nginx, lighttpd,...)
>>>
>>
>> So, nginx is a replacement for Apache, right? I just went through a few hours of work to get Apache
>> running but if nginx is better, I can try that route.
>>
>>> While Swazoo works OK, using a FastCGI behind a frond-end webserver is a lot faster (in my experience).
>>>
>>> A good post on using Seaside with FastCGI can be found here:
>>> http://www.monkeysnatchbanana.com/posts/2010/08/17/using-fastcgi-with-nginx-and-seaside.html
>>>
>>
>> Thanks for the link. I will study it and try to configure my system so that it uses nginx.
>> I appear to have nginx installed, at least, that's what sudo yum install nginx claims...
>>
>> Setting up Install Process
>> Package nginx-0.8.54-1.4.amzn1.x86_64 already installed and latest version
>> Nothing to do
>>
>>
>> Regards,
>>
>> Larry
>>
>>
>>> cheers,
>>> Johan
>>>
>>> On 16 Jan 2012, at 20:15, Lawrence Kellogg wrote:
>>>
>>>> Hello,
>>>> So, I'm a little confused about running Seaside Gems from the command line
>>>> versus from within an image.
>>>>
>>>> I have installed Apache and I am bringing up a page that embeds my Seaside
>>>> server in an iFrame.
>>>>
>>>> Now, if I just run Seaside Gems from the command line with this command:
>>>>
>>>> runSeasideGems30 start  WAFastCGIAdaptor 9001
>>>>
>>>> I cannot forward to my Seaside app on port 9001 from within my index.html but if I bring up
>>>> a Smalltalk image and run this command in a workspace:
>>>>
>>>>
>>>> WAGemStoneRunSeasideGems default
>>>> name: 'Swazoo';
>>>> adaptorClass: WAGsSwazooAdaptor;
>>>> ports: #(8080).
>>>> WAGemStoneRunSeasideGems restartGems.
>>>>
>>>> then I can forward to port 8080 for my application, from within index.html.
>>>>
>>>> I'm just a little confused about what is going on here.
>>>> Is the FastCGI server being used at all? Should I just start
>>>> Swazoo from inside the image and not start the FastCGI stuff?
>>>>
>>>> Why can't I get any response from the FastCGI code running on
>>>> port 9001?
>>>>
>>>> I'm not clear on what is going on.
>>>>
>>>> Thanks,
>>>>
>>>> Larry
>>>
>>
>

Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

Larry Kellogg
In reply to this post by James Foster-8
Huh, I take it back, the system crashed again:

topaz 1> topaz 1> [256818433 sz:3 cls: 114945 GsFile] a GsFile
  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
  pathName        [256818945 sz:57 cls: 74753 String] /opt/gemstone/product/seaside/data/Swazoo_server-8080.pid
  mode            [8827393 sz:1 cls: 74753 String] w

topaz 1> topaz 1> Swazoo Server started on port 8080
--transcript--'Error creating WAWalkback: You can only #call: and #answer: from within a callback or a Task.'
-----------------------------------------------------
GemStone: Error         Nonfatal
The object with object ID 81065893341168128 does not exist.
Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1 Context : 245271297
Arg 1: [648527146729345026 sz:0 cls: 74241 SmallInteger] 81065893341168128

Now executing the following command saved from "iferr 1":
   where
==> 1 WAComponent >> decoration @3 line 1   [GsMethod 194749441]
2 WAComponent >> addDecoration: @2 line 6   [GsMethod 194748417]
3 WAComponent >> show:onAnswer:delegation: @10 line 8   [GsMethod 194749185]
4 WAComponent >> show:onAnswer: @5 line 5   [GsMethod 194751233]
5 WAComponent >> call:onAnswer: @5 line 8   [GsMethod 194750977]
6 ComplexBlock in WAComponent >> call: @3 line 4   [GsMethod 191317249]
7 ComplexBlock in WAComponent >> wait: @3 line 3   [GsMethod 191268353]
8 GRGemStonePlatform >> seasideSuspendFlowDo: @9 line 5   [GsMethod 221050369]
9 WAComponent >> wait: @4 line 3   [GsMethod 191268353]
10 WAComponent >> call: @4 line 4   [GsMethod 191317249]
11 MyLoginTask >> go @15 line 12   [GsMethod 258591233]


Strange, my call: is from within a WATask....


  Larry


On Jan 16, 2012, at 3:31 PM, James Foster wrote:

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

Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

Larry Kellogg
Do you make anything out of this error, at the end of the stack dump:

0 ComplexVCBlock in HTTPServer >> start @14 line 6   [GsMethod 186054913]
151 GsProcess >> _startPart2 @15 line 17   [GsMethod 4501249]
152 GsProcess >> _start @1 line 9   [GsMethod 4501761]
  [GsProcess 245271297]
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> Mon Jan 16 21:07:38 UTC 2012
Mon Jan 16 21:07:38 UTC 2012

hostcalldebugger invoked in process 11128, at 01/16/2012 09:07:38 PM.309 UTC
 notifying stone of fatal error



On Jan 16, 2012, at 4:15 PM, Lawrence Kellogg wrote:

> Huh, I take it back, the system crashed again:
>
> topaz 1> topaz 1> [256818433 sz:3 cls: 114945 GsFile] a GsFile
>  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
>  pathName        [256818945 sz:57 cls: 74753 String] /opt/gemstone/product/seaside/data/Swazoo_server-8080.pid
>  mode            [8827393 sz:1 cls: 74753 String] w
>
> topaz 1> topaz 1> Swazoo Server started on port 8080
> --transcript--'Error creating WAWalkback: You can only #call: and #answer: from within a callback or a Task.'
> -----------------------------------------------------
> GemStone: Error         Nonfatal
> The object with object ID 81065893341168128 does not exist.
> Error Category: 231169 [GemStone] Number: 2101 Arg Count: 1 Context : 245271297
> Arg 1: [648527146729345026 sz:0 cls: 74241 SmallInteger] 81065893341168128
>
> Now executing the following command saved from "iferr 1":
>   where
> ==> 1 WAComponent >> decoration @3 line 1   [GsMethod 194749441]
> 2 WAComponent >> addDecoration: @2 line 6   [GsMethod 194748417]
> 3 WAComponent >> show:onAnswer:delegation: @10 line 8   [GsMethod 194749185]
> 4 WAComponent >> show:onAnswer: @5 line 5   [GsMethod 194751233]
> 5 WAComponent >> call:onAnswer: @5 line 8   [GsMethod 194750977]
> 6 ComplexBlock in WAComponent >> call: @3 line 4   [GsMethod 191317249]
> 7 ComplexBlock in WAComponent >> wait: @3 line 3   [GsMethod 191268353]
> 8 GRGemStonePlatform >> seasideSuspendFlowDo: @9 line 5   [GsMethod 221050369]
> 9 WAComponent >> wait: @4 line 3   [GsMethod 191268353]
> 10 WAComponent >> call: @4 line 4   [GsMethod 191317249]
> 11 MyLoginTask >> go @15 line 12   [GsMethod 258591233]
>
>
> Strange, my call: is from within a WATask....
>
>
>  Larry
>
>
> On Jan 16, 2012, at 3:31 PM, James Foster wrote:
>
>> You found the correct log file and provided a useful dump of the error. Now, as to the error... I think that "object does not exist" is something that shouldn't happen--that is, it probably isn't your configuration or Smalltalk code that is in error. What version of GemStone are you running?
>>
>> -James
>>
>> On Jan 16, 2012, at 12:21 PM, Lawrence Kellogg wrote:
>>
>>> 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
>>>>
>>>
>>
>

James Foster-8
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

James Foster-8
This one is easy. It is telling us that Swazoo is not defined. That is, the global does not exist (or at least is not visible). Does 'Swazoo' exist as a global when you are in a GemTools workspace?

Of course, this happens after the other error so fixing it won't help the original problem.

-James


On Jan 16, 2012, at 1:27 PM, Lawrence Kellogg wrote:

> Do you make anything out of this error, at the end of the stack dump:
>
> 0 ComplexVCBlock in HTTPServer >> start @14 line 6   [GsMethod 186054913]
> 151 GsProcess >> _startPart2 @15 line 17   [GsMethod 4501249]
> 152 GsProcess >> _start @1 line 9   [GsMethod 4501761]
>  [GsProcess 245271297]
> 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> Mon Jan 16 21:07:38 UTC 2012
> Mon Jan 16 21:07:38 UTC 2012
>
> hostcalldebugger invoked in process 11128, at 01/16/2012 09:07:38 PM.309 UTC
> notifying stone of fatal error

Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

Larry Kellogg

On Jan 16, 2012, at 5:34 PM, James Foster wrote:

> This one is easy. It is telling us that Swazoo is not defined. That is, the global does not exist (or at least is not visible). Does 'Swazoo' exist as a global when you are in a GemTools workspace?
>
> Of course, this happens after the other error so fixing it won't help the original problem.
>

  Interesting. There is every other kind of Swazoo class in the image but no "Swazoo" class.
You're right, of course, this error is not going to help me with the original problem, which is
sort of a mystery to me, at the moment. I have no idea which object does not exist, and why.





I'm trying to get nginx working with fastcgi, so Swazoo would  be taken out of the picture.
I have nginx up and running, and a config file, but still don't have it talking to my Seaside server.
I'm sure I will figure it out fairly soon, I hope.

Nick's page, here, also has a lot of info on nginx:

http://www.nickager.com/blog/Installing-Gemstone-on-an-Amazon-EC2-Linux-instance/

Larry



> -James
>
>
> On Jan 16, 2012, at 1:27 PM, Lawrence Kellogg wrote:
>
>> Do you make anything out of this error, at the end of the stack dump:
>>
>> 0 ComplexVCBlock in HTTPServer >> start @14 line 6   [GsMethod 186054913]
>> 151 GsProcess >> _startPart2 @15 line 17   [GsMethod 4501249]
>> 152 GsProcess >> _start @1 line 9   [GsMethod 4501761]
>> [GsProcess 245271297]
>> 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> Mon Jan 16 21:07:38 UTC 2012
>> Mon Jan 16 21:07:38 UTC 2012
>>
>> hostcalldebugger invoked in process 11128, at 01/16/2012 09:07:38 PM.309 UTC
>> notifying stone of fatal error
>


Screen shot 2012-01-16 at 5.47.47 PM.png (76K) Download Attachment
Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg
In reply to this post by Larry Kellogg
Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
I seem to be getting the following walkback when trying to access my Seaside server.

I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
instead of the Gateway timeout message that I got with the walkback.

  Any thoughts?

  Larry




PROCESS ID: 14262     DATE: 01/17/2012 02:04:32 AM UTC                      |
|   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: 7
[Info]: GCI Client Host: <Linked>
[Info]: Page server PID: -1
[Info]: Login Time: 01/17/2012 02:04:32 AM.531 UTC
[01/17/2012 02:04:32 AM.567 UTC] gci login: currSession 1 rpc gem processId -1
successful login
topaz 1> topaz 1> [175332353 sz:3 cls: 114945 GsFile] a GsFile
  isClient        [2 sz:0 cls: 74241 SmallInteger] 0
  pathName        [175332865 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 <#''raiseResponse:''
> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-16T18:04:58.97784996032715-08:00
MessageNotUnderstood 2010: No method was found for the selector <#'raiseResponse:'> when sent to <HTTPException> with argum
ents contained in <anArray( aHTTPResponse)>.
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 185648385]
4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 185651457]
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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP 185463297]
16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod OOP 186133761]
17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP 186134017]
18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6  [GsMethod OOP 185649665]
19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod OOP 22311937]
23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP 185649665]
24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod OOP 185651201]
25 ComplexBlock in HTTPConnection >> interact @7 line 6  [GsMethod OOP 185651457]
26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
29 ComplexVCBlock in HTTPConnection >> interact @12 line 9  [GsMethod OOP 185651457]
30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6  [GsMethod OOP 116163329]
31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8  [GsMethod OOP 116163329]
34 ComplexVCBlock in HTTPConnection >> interact @19 line 13  [GsMethod OOP 185651457]
35 HTTPConnection >> interact @26 line 18  [GsMethod OOP 185651457]
36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP 186054145]
37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP 186054913]
38 ComplexBlock in BlockClosure >> repeat @3 line 5  [GsMethod OOP 19138561]
39 ComplexVCBlock in HTTPServer >> start @14 line 6  [GsMethod OOP 186054913]
40 GsProcess >> _startPart2 @15 line 17  [GsMethod OOP 4501249]
41 GsProcess >> _start @1 line 9  [GsMethod OOP 4501761]
-----------
--transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''raiseResponse:''> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
-----------




On Jan 16, 2012, at 3:54 PM, Lawrence Kellogg wrote:

>
> On Jan 16, 2012, at 3:33 PM, Johan Brichau wrote:
>
>> Larry,
>>
>> You can use FastCGI with Apache as well: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
>> There is no need to switch to Nginx for that.
>>
>> But you cannot connect to the fastcgi port with your webbrowser, simply because a FastCGI adaptor does not serve http.
>> Instead, it serves the FastCGI protocol, which is understood by the fastcgi module of your front-end webserver. In turn, the front-end webserver, will serve http.
>>
>> So, the link in your iframe can never work if port 9001 is serving FastCGI.
>>
>
>  Ok, so, how does my iframe refer to the content being served by Seaside?
> I'm a little unclear on the connections. Is it..
>
> It works with:
>
> User---->Apache:80----->iframe:Seaside:8080
>
> but with FAST CGI it would be
>
> User---->Apache:80--->Apache:FastCGI:9001--->Seaside FAST CGI Gems running on 9001??
>
> Is that right?
>
> I did CGI programming years and years ago. Sorry, I'm a little puzzled.
>
>  Larry
>
>
>
>
>> Johan
>>
>> On 16 Jan 2012, at 21:27, Lawrence Kellogg wrote:
>>
>>> Johan,
>>>
>>> On Jan 16, 2012, at 2:53 PM, Johan Brichau wrote:
>>>
>>>> Larry,
>>>>
>>>> Are you trying to connect to port 9001 from your webbrowser?
>>>>
>>>
>>> Yes, well, from within an index.html file that was being served up by an Apache server, from within an
>>> iFrame, like this:
>>>
>>> <body class="borderless">
>>> <iframe src="http://myseasideserver.com:9001"
>>> name="myapp" width="795" marginwidth="0" height="880" marginheight="0" scrolling="no" frameborder="0" class="borderless"></iframe>
>>> </body>
>>>
>>> I guess this is not legit.
>>>
>>>
>>>> If yes: Swazoo and FastCGI adaptors are different kinds of servers.
>>>>
>>>> A Swazoo adaptor brings up an http server, which you can directly connect to from your webbrowser.
>>>> A FastCGI adaptor brings up a FastCGI server, which can only be connected to via a front-end http server (such as apache, nginx, lighttpd,...)
>>>>
>>>
>>> So, nginx is a replacement for Apache, right? I just went through a few hours of work to get Apache
>>> running but if nginx is better, I can try that route.
>>>
>>>> While Swazoo works OK, using a FastCGI behind a frond-end webserver is a lot faster (in my experience).
>>>>
>>>> A good post on using Seaside with FastCGI can be found here:
>>>> http://www.monkeysnatchbanana.com/posts/2010/08/17/using-fastcgi-with-nginx-and-seaside.html
>>>>
>>>
>>> Thanks for the link. I will study it and try to configure my system so that it uses nginx.
>>> I appear to have nginx installed, at least, that's what sudo yum install nginx claims...
>>>
>>> Setting up Install Process
>>> Package nginx-0.8.54-1.4.amzn1.x86_64 already installed and latest version
>>> Nothing to do
>>>
>>>
>>> Regards,
>>>
>>> Larry
>>>
>>>
>>>> cheers,
>>>> Johan
>>>>
>>>> On 16 Jan 2012, at 20:15, Lawrence Kellogg wrote:
>>>>
>>>>> Hello,
>>>>> So, I'm a little confused about running Seaside Gems from the command line
>>>>> versus from within an image.
>>>>>
>>>>> I have installed Apache and I am bringing up a page that embeds my Seaside
>>>>> server in an iFrame.
>>>>>
>>>>> Now, if I just run Seaside Gems from the command line with this command:
>>>>>
>>>>> runSeasideGems30 start  WAFastCGIAdaptor 9001
>>>>>
>>>>> I cannot forward to my Seaside app on port 9001 from within my index.html but if I bring up
>>>>> a Smalltalk image and run this command in a workspace:
>>>>>
>>>>>
>>>>> WAGemStoneRunSeasideGems default
>>>>> name: 'Swazoo';
>>>>> adaptorClass: WAGsSwazooAdaptor;
>>>>> ports: #(8080).
>>>>> WAGemStoneRunSeasideGems restartGems.
>>>>>
>>>>> then I can forward to port 8080 for my application, from within index.html.
>>>>>
>>>>> I'm just a little confused about what is going on here.
>>>>> Is the FastCGI server being used at all? Should I just start
>>>>> Swazoo from inside the image and not start the FastCGI stuff?
>>>>>
>>>>> Why can't I get any response from the FastCGI code running on
>>>>> port 9001?
>>>>>
>>>>> I'm not clear on what is going on.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Larry
>>>>
>>>
>>
>

Paul DeBruicker
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Paul DeBruicker
On 12-01-16 06:29 PM, Lawrence Kellogg wrote:

> Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
> I seem to be getting the following walkback when trying to access my Seaside server.
>
> I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
> but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
> instead of the Gateway timeout message that I got with the walkback.
>
>    Any thoughts?
>
>    Larry


You might be hitting an error or a halt in your code/system.  Before
starting the WAFastCGIAdaptor from inside the image open a Gemstone
Process Browser.  You can use it to terminate the WAFastCGIAdaptor after
getting the 502 error and then examine the Object Log for errors.


Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg

On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:

> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
>> Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
>> I seem to be getting the following walkback when trying to access my Seaside server.
>>
>> I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
>> but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
>> instead of the Gateway timeout message that I got with the walkback.
>>
>>   Any thoughts?
>>
>>   Larry
>
>
> You might be hitting an error or a halt in your code/system.  Before starting the WAFastCGIAdaptor from inside the image open a Gemstone Process Browser.  You can use it to terminate the WAFastCGIAdaptor after getting the 502 error and then examine the Object Log for errors.
>
>

  Thanks, Paul, but I can't seem to get this to work. How should I start the Fast CGI process, like this:


WAGemStoneRunSeasideGems default
        name: 'FastCGI';
        adaptorClass: WAFastCGIAdaptor;
        ports: #(9001 9002 9003).
WAGemStoneRunSeasideGems restartGems.

or

WAFastCGIAdaptor startOn: 9001.

??

Looking in the process browser, I don't see anything that I can
easily identify as a FasCGI process. What does it look like?

Bringing up the object log does not seem to give me the exception
I need to debug.


I think I have this walkback: HTTPException does not have a raiseResponse method, although, poking around I found this

raiseResponseCode: aNumber
        "Raise an exception to immediatelly return http response with that code"
        ^self raiseResponse: (HTTPResponse new code: aNumber)


raiseResponse: aHTTPResponse
        "Raise an exception to immediatelly return that response."
        ^self new
                response: aHTTPResponse;
                signal.

which I found back in Swazoo 2.1


Which version of Swazoo should I be loading?

Larry



[seasideuser@ip-10-245-218-240 log]$ vi WAFastCGIAdaptor_server-9001.log

topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
--transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''raiseResponse:''> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-16T18:57:58.17819499969482-08:00
MessageNotUnderstood 2010: No method was found for the selector <#'raiseResponse:'> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.
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 185648385]
4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 185651457]
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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP 185463297]
16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod OOP 186133761]
17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP 186134017]
18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6  [GsMethod OOP 185649665]
19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod OOP 22311937]
23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP 185649665]
24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod OOP 185651201]
25 ComplexBlock in HTTPConnection >> interact @7 line 6  [GsMethod OOP 185651457]
26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
29 ComplexVCBlock in HTTPConnection >> interact @12 line 9  [GsMethod OOP 185651457]
30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6  [GsMethod OOP 116163329]
31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8  [GsMethod OOP 116163329]
34 ComplexVCBlock in HTTPConnection >> interact @19 line 13  [GsMethod OOP 185651457]
35 HTTPConnection >> interact @26 line 18  [GsMethod OOP 185651457]
36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP 186054145]
37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP 186054913]



Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg
I also found this error in the nginx.log file:

 FastCGI sent in stderr: "Reading a number failed: a digit between 0 and 9 expected" while reading response header from upstream,

I'm not sure how to g about figuring out why that is happening...

Larry



On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:

>
> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
>
>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
>>> Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
>>> I seem to be getting the following walkback when trying to access my Seaside server.
>>>
>>> I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
>>> but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
>>> instead of the Gateway timeout message that I got with the walkback.
>>>
>>>  Any thoughts?
>>>
>>>  Larry
>>
>>
>> You might be hitting an error or a halt in your code/system.  Before starting the WAFastCGIAdaptor from inside the image open a Gemstone Process Browser.  You can use it to terminate the WAFastCGIAdaptor after getting the 502 error and then examine the Object Log for errors.
>>
>>
>
>  Thanks, Paul, but I can't seem to get this to work. How should I start the Fast CGI process, like this:
>
>
> WAGemStoneRunSeasideGems default
> name: 'FastCGI';
> adaptorClass: WAFastCGIAdaptor;
> ports: #(9001 9002 9003).
> WAGemStoneRunSeasideGems restartGems.
>
> or
>
> WAFastCGIAdaptor startOn: 9001.
>
> ??
>
> Looking in the process browser, I don't see anything that I can
> easily identify as a FasCGI process. What does it look like?
>
> Bringing up the object log does not seem to give me the exception
> I need to debug.
>
>
> I think I have this walkback: HTTPException does not have a raiseResponse method, although, poking around I found this
>
> raiseResponseCode: aNumber
> "Raise an exception to immediatelly return http response with that code"
> ^self raiseResponse: (HTTPResponse new code: aNumber)
>
>
> raiseResponse: aHTTPResponse
> "Raise an exception to immediatelly return that response."
> ^self new
> response: aHTTPResponse;
> signal.
>
> which I found back in Swazoo 2.1
>
>
> Which version of Swazoo should I be loading?
>
> Larry
>
>
>
> [seasideuser@ip-10-245-218-240 log]$ vi WAFastCGIAdaptor_server-9001.log
>
> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''raiseResponse:''> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-16T18:57:58.17819499969482-08:00
> MessageNotUnderstood 2010: No method was found for the selector <#'raiseResponse:'> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.
> 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 185648385]
> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 185651457]
> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP 185463297]
> 16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod OOP 186133761]
> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP 186134017]
> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6  [GsMethod OOP 185649665]
> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
> 22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod OOP 22311937]
> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP 185649665]
> 24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod OOP 185651201]
> 25 ComplexBlock in HTTPConnection >> interact @7 line 6  [GsMethod OOP 185651457]
> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9  [GsMethod OOP 185651457]
> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6  [GsMethod OOP 116163329]
> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8  [GsMethod OOP 116163329]
> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13  [GsMethod OOP 185651457]
> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP 185651457]
> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP 186054145]
> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP 186054913]
>
>
>

Johan Brichau-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Johan Brichau-2
What version of GLASS are you running?

This error pops up when you load Seaside 3.0.6+ in a GLASS version that is lower than 1.0-beta-8.7.1

On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:

> I also found this error in the nginx.log file:
>
> FastCGI sent in stderr: "Reading a number failed: a digit between 0 and 9 expected" while reading response header from upstream,
>
> I'm not sure how to g about figuring out why that is happening...
>
> Larry
>
>
>
> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
>
>>
>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
>>
>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
>>>> Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
>>>> I seem to be getting the following walkback when trying to access my Seaside server.
>>>>
>>>> I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
>>>> but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
>>>> instead of the Gateway timeout message that I got with the walkback.
>>>>
>>>> Any thoughts?
>>>>
>>>> Larry
>>>
>>>
>>> You might be hitting an error or a halt in your code/system.  Before starting the WAFastCGIAdaptor from inside the image open a Gemstone Process Browser.  You can use it to terminate the WAFastCGIAdaptor after getting the 502 error and then examine the Object Log for errors.
>>>
>>>
>>
>> Thanks, Paul, but I can't seem to get this to work. How should I start the Fast CGI process, like this:
>>
>>
>> WAGemStoneRunSeasideGems default
>> name: 'FastCGI';
>> adaptorClass: WAFastCGIAdaptor;
>> ports: #(9001 9002 9003).
>> WAGemStoneRunSeasideGems restartGems.
>>
>> or
>>
>> WAFastCGIAdaptor startOn: 9001.
>>
>> ??
>>
>> Looking in the process browser, I don't see anything that I can
>> easily identify as a FasCGI process. What does it look like?
>>
>> Bringing up the object log does not seem to give me the exception
>> I need to debug.
>>
>>
>> I think I have this walkback: HTTPException does not have a raiseResponse method, although, poking around I found this
>>
>> raiseResponseCode: aNumber
>> "Raise an exception to immediatelly return http response with that code"
>> ^self raiseResponse: (HTTPResponse new code: aNumber)
>>
>>
>> raiseResponse: aHTTPResponse
>> "Raise an exception to immediatelly return that response."
>> ^self new
>> response: aHTTPResponse;
>> signal.
>>
>> which I found back in Swazoo 2.1
>>
>>
>> Which version of Swazoo should I be loading?
>>
>> Larry
>>
>>
>>
>> [seasideuser@ip-10-245-218-240 log]$ vi WAFastCGIAdaptor_server-9001.log
>>
>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''raiseResponse:''> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
>> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
>> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-16T18:57:58.17819499969482-08:00
>> MessageNotUnderstood 2010: No method was found for the selector <#'raiseResponse:'> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.
>> 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 185648385]
>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 185651457]
>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP 185463297]
>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod OOP 186133761]
>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP 186134017]
>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6  [GsMethod OOP 185649665]
>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
>> 22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod OOP 22311937]
>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP 185649665]
>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod OOP 185651201]
>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6  [GsMethod OOP 185651457]
>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9  [GsMethod OOP 185651457]
>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6  [GsMethod OOP 116163329]
>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8  [GsMethod OOP 116163329]
>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13  [GsMethod OOP 185651457]
>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP 185651457]
>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP 186054145]
>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP 186054913]
>>
>>
>>
>

Tobias Pape
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Tobias Pape
In reply to this post by Larry Kellogg

Am 2012-01-17 um 14:50 schrieb Lawrence Kellogg:

> I also found this error in the nginx.log file:
>
> FastCGI sent in stderr: "Reading a number failed: a digit between 0 and 9 expected" while reading response header from upstream,
>
> I'm not sure how to g about figuring out why that is happening...

This is a known thing.

Look at
http://code.google.com/p/squeaksource3/issues/detail?id=16

where Norbert says
that the solution in
http://code.google.com/p/glassdb/issues/detail?id=298

works.

And, for me, this worked for SqueakSource :)

best
        -Tobias

Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg

On Jan 17, 2012, at 9:34 AM, Tobias Pape wrote:

>
> Am 2012-01-17 um 14:50 schrieb Lawrence Kellogg:
>
>> I also found this error in the nginx.log file:
>>
>> FastCGI sent in stderr: "Reading a number failed: a digit between 0 and 9 expected" while reading response header from upstream,
>>
>> I'm not sure how to g about figuring out why that is happening...
>
> This is a known thing.
>
> Look at
> http://code.google.com/p/squeaksource3/issues/detail?id=16
>
> where Norbert says
> that the solution in
> http://code.google.com/p/glassdb/issues/detail?id=298
>
> works.
>
> And, for me, this worked for SqueakSource :)
>

  Eureka!!! It works now.Thanks, Tobias, much appreciated.

  I could have sworn I updated GLASS to 1.0-beta.8.7.1, but now, I have.


> best
> -Tobias
>

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

Dale Henrichs
In reply to this post by Larry Kellogg
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
| >
|
|
Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Fatal Internal Notification from Gem

Larry Kellogg

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

  Thanks for the information. I was using the WAGemStoneWalkbackErrorHandler. I will switch over to the production error handler.


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

  Great!  I will start using the most up to date scripts.

  Larry




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

Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg
In reply to this post by Johan Brichau-2
Hello Johan,

On Jan 17, 2012, at 8:53 AM, Johan Brichau wrote:

> What version of GLASS are you running?
>
> This error pops up when you load Seaside 3.0.6+ in a GLASS version that is lower than 1.0-beta-8.7.1
>

  I have now upgraded to 1.0 beta 8.7.1.

  Hmmm, I think I am on Seaside 3.0.

  Should I upgrade to Seaside 3.0.6? Is there an easy way to do that?
Do I just load all of the various packages under http://seaside.gemstone.com/ss/Seaside30?

  My system seems to be in a pretty stable state, at the moment, but I will move along with
the minor releases.

  Regards,

  Larry


 

> On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:
>
>> I also found this error in the nginx.log file:
>>
>> FastCGI sent in stderr: "Reading a number failed: a digit between 0 and 9 expected" while reading response header from upstream,
>>
>> I'm not sure how to g about figuring out why that is happening...
>>
>> Larry
>>
>>
>>
>> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
>>
>>>
>>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
>>>
>>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
>>>>> Now, I've moved on to trying to get nginx to run through FASTCGI to Seaside on port 9001.
>>>>> I seem to be getting the following walkback when trying to access my Seaside server.
>>>>>
>>>>> I'm trying to start the WAFastCGIAdaptor from inside an image (WAFastCGIAdaptor startOn: 9001)
>>>>> but that never returns and if I try to execute an http request I get a 502 Bad Gateway message
>>>>> instead of the Gateway timeout message that I got with the walkback.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Larry
>>>>
>>>>
>>>> You might be hitting an error or a halt in your code/system.  Before starting the WAFastCGIAdaptor from inside the image open a Gemstone Process Browser.  You can use it to terminate the WAFastCGIAdaptor after getting the 502 error and then examine the Object Log for errors.
>>>>
>>>>
>>>
>>> Thanks, Paul, but I can't seem to get this to work. How should I start the Fast CGI process, like this:
>>>
>>>
>>> WAGemStoneRunSeasideGems default
>>> name: 'FastCGI';
>>> adaptorClass: WAFastCGIAdaptor;
>>> ports: #(9001 9002 9003).
>>> WAGemStoneRunSeasideGems restartGems.
>>>
>>> or
>>>
>>> WAFastCGIAdaptor startOn: 9001.
>>>
>>> ??
>>>
>>> Looking in the process browser, I don't see anything that I can
>>> easily identify as a FasCGI process. What does it look like?
>>>
>>> Bringing up the object log does not seem to give me the exception
>>> I need to debug.
>>>
>>>
>>> I think I have this walkback: HTTPException does not have a raiseResponse method, although, poking around I found this
>>>
>>> raiseResponseCode: aNumber
>>> "Raise an exception to immediatelly return http response with that code"
>>> ^self raiseResponse: (HTTPResponse new code: aNumber)
>>>
>>>
>>> raiseResponse: aHTTPResponse
>>> "Raise an exception to immediatelly return that response."
>>> ^self new
>>> response: aHTTPResponse;
>>> signal.
>>>
>>> which I found back in Swazoo 2.1
>>>
>>>
>>> Which version of Swazoo should I be loading?
>>>
>>> Larry
>>>
>>>
>>>
>>> [seasideuser@ip-10-245-218-240 log]$ vi WAFastCGIAdaptor_server-9001.log
>>>
>>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
>>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010: No method was found for the selector <#''raiseResponse:''> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.'
>>> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
>>> ----------- Swazoo2 Internal Error ERROR Encountered: 2012-01-16T18:57:58.17819499969482-08:00
>>> MessageNotUnderstood 2010: No method was found for the selector <#'raiseResponse:'> when sent to <HTTPException> with arguments contained in <anArray( aHTTPResponse)>.
>>> 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 185648385]
>>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12  [GsMethod OOP 185651457]
>>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP 185463297]
>>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod OOP 186133761]
>>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP 186134017]
>>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6  [GsMethod OOP 185649665]
>>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
>>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
>>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
>>> 22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod OOP 22311937]
>>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP 185649665]
>>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod OOP 185651201]
>>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6  [GsMethod OOP 185651457]
>>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP 10065409]
>>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP 10062081]
>>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod OOP 9005057]
>>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9  [GsMethod OOP 185651457]
>>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6  [GsMethod OOP 116163329]
>>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11  [GsMethod OOP 2304001]
>>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11  [GsMethod OOP 2304001]
>>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8  [GsMethod OOP 116163329]
>>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13  [GsMethod OOP 185651457]
>>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP 185651457]
>>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP 186054145]
>>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP 186054913]
>>>
>>>
>>>
>>
>

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Dale Henrichs
Lawrence,

You can tell what version of Seaside you are using by printing the following:

  ConfigurationOfSeaside30 project currentVersion

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, January 18, 2012 5:43:22 AM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| Hello Johan,
|
| On Jan 17, 2012, at 8:53 AM, Johan Brichau wrote:
|
| > What version of GLASS are you running?
| >
| > This error pops up when you load Seaside 3.0.6+ in a GLASS version
| > that is lower than 1.0-beta-8.7.1
| >
|
|   I have now upgraded to 1.0 beta 8.7.1.
|
|   Hmmm, I think I am on Seaside 3.0.
|
|   Should I upgrade to Seaside 3.0.6? Is there an easy way to do that?
| Do I just load all of the various packages under
| http://seaside.gemstone.com/ss/Seaside30?
|
|   My system seems to be in a pretty stable state, at the moment, but
|   I will move along with
| the minor releases.
|
|   Regards,
|
|   Larry
|
|
|  
|
| > On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:
| >
| >> I also found this error in the nginx.log file:
| >>
| >> FastCGI sent in stderr: "Reading a number failed: a digit between
| >> 0 and 9 expected" while reading response header from upstream,
| >>
| >> I'm not sure how to g about figuring out why that is happening...
| >>
| >> Larry
| >>
| >>
| >>
| >> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
| >>
| >>>
| >>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
| >>>
| >>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
| >>>>> Now, I've moved on to trying to get nginx to run through
| >>>>> FASTCGI to Seaside on port 9001.
| >>>>> I seem to be getting the following walkback when trying to
| >>>>> access my Seaside server.
| >>>>>
| >>>>> I'm trying to start the WAFastCGIAdaptor from inside an image
| >>>>> (WAFastCGIAdaptor startOn: 9001)
| >>>>> but that never returns and if I try to execute an http request
| >>>>> I get a 502 Bad Gateway message
| >>>>> instead of the Gateway timeout message that I got with the
| >>>>> walkback.
| >>>>>
| >>>>> Any thoughts?
| >>>>>
| >>>>> Larry
| >>>>
| >>>>
| >>>> You might be hitting an error or a halt in your code/system.
| >>>>  Before starting the WAFastCGIAdaptor from inside the image
| >>>> open a Gemstone Process Browser.  You can use it to terminate
| >>>> the WAFastCGIAdaptor after getting the 502 error and then
| >>>> examine the Object Log for errors.
| >>>>
| >>>>
| >>>
| >>> Thanks, Paul, but I can't seem to get this to work. How should I
| >>> start the Fast CGI process, like this:
| >>>
| >>>
| >>> WAGemStoneRunSeasideGems default
| >>> name: 'FastCGI';
| >>> adaptorClass: WAFastCGIAdaptor;
| >>> ports: #(9001 9002 9003).
| >>> WAGemStoneRunSeasideGems restartGems.
| >>>
| >>> or
| >>>
| >>> WAFastCGIAdaptor startOn: 9001.
| >>>
| >>> ??
| >>>
| >>> Looking in the process browser, I don't see anything that I can
| >>> easily identify as a FasCGI process. What does it look like?
| >>>
| >>> Bringing up the object log does not seem to give me the exception
| >>> I need to debug.
| >>>
| >>>
| >>> I think I have this walkback: HTTPException does not have a
| >>> raiseResponse method, although, poking around I found this
| >>>
| >>> raiseResponseCode: aNumber
| >>> "Raise an exception to immediatelly return http response with
| >>> that code"
| >>> ^self raiseResponse: (HTTPResponse new code: aNumber)
| >>>
| >>>
| >>> raiseResponse: aHTTPResponse
| >>> "Raise an exception to immediatelly return that response."
| >>> ^self new
| >>> response: aHTTPResponse;
| >>> signal.
| >>>
| >>> which I found back in Swazoo 2.1
| >>>
| >>>
| >>> Which version of Swazoo should I be loading?
| >>>
| >>> Larry
| >>>
| >>>
| >>>
| >>> [seasideuser@ip-10-245-218-240 log]$ vi
| >>> WAFastCGIAdaptor_server-9001.log
| >>>
| >>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
| >>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010:
| >>> No method was found for the selector <#''raiseResponse:''> when
| >>> sent to <HTTPException> with arguments contained in <anArray(
| >>> aHTTPResponse)>.'
| >>> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
| >>> ----------- Swazoo2 Internal Error ERROR Encountered:
| >>> 2012-01-16T18:57:58.17819499969482-08:00
| >>> MessageNotUnderstood 2010: No method was found for the selector
| >>> <#'raiseResponse:'> when sent to <HTTPException> with arguments
| >>> contained in <anArray( aHTTPResponse)>.
| >>> 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
| >>> 185648385]
| >>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12
| >>>  [GsMethod OOP 185651457]
| >>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP
| >>> 185463297]
| >>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod
| >>> OOP 186133761]
| >>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP
| >>> 186134017]
| >>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6
| >>>  [GsMethod OOP 185649665]
| >>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| >>> 10065409]
| >>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| >>> 10062081]
| >>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
| >>>  [GsMethod OOP 9005057]
| >>> 22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod
| >>> OOP 22311937]
| >>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP
| >>> 185649665]
| >>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod
| >>> OOP 185651201]
| >>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6
| >>>  [GsMethod OOP 185651457]
| >>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| >>> 10065409]
| >>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| >>> 10062081]
| >>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
| >>> OOP 9005057]
| >>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9
| >>>  [GsMethod OOP 185651457]
| >>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
| >>>  [GsMethod OOP 116163329]
| >>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| >>>  [GsMethod OOP 2304001]
| >>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| >>>  [GsMethod OOP 2304001]
| >>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8
| >>>  [GsMethod OOP 116163329]
| >>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13
| >>>  [GsMethod OOP 185651457]
| >>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP
| >>> 185651457]
| >>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP
| >>> 186054145]
| >>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP
| >>> 186054913]
| >>>
| >>>
| >>>
| >>
| >
|
|
Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg

On Jan 18, 2012, at 12:40 PM, Dale Henrichs wrote:

> Lawrence,
>
> You can tell what version of Seaside you are using by printing the following:
>
>  ConfigurationOfSeaside30 project currentVersion
>

Hello Dale,
  I'm on 3.0.6

 >=3.0.6 [ConfigurationOfSeaside30]

It doesn't seem like there is an Update Seaside button on the launcher.
What is the easiest way of loading in changes? Should I look through all of the
Seaside packages and load more recent change sets?

  Larry


> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Wednesday, January 18, 2012 5:43:22 AM
> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
> |
> | Hello Johan,
> |
> | On Jan 17, 2012, at 8:53 AM, Johan Brichau wrote:
> |
> | > What version of GLASS are you running?
> | >
> | > This error pops up when you load Seaside 3.0.6+ in a GLASS version
> | > that is lower than 1.0-beta-8.7.1
> | >
> |
> |   I have now upgraded to 1.0 beta 8.7.1.
> |
> |   Hmmm, I think I am on Seaside 3.0.
> |
> |   Should I upgrade to Seaside 3.0.6? Is there an easy way to do that?
> | Do I just load all of the various packages under
> | http://seaside.gemstone.com/ss/Seaside30?
> |
> |   My system seems to be in a pretty stable state, at the moment, but
> |   I will move along with
> | the minor releases.
> |
> |   Regards,
> |
> |   Larry
> |
> |
> |  
> |
> | > On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:
> | >
> | >> I also found this error in the nginx.log file:
> | >>
> | >> FastCGI sent in stderr: "Reading a number failed: a digit between
> | >> 0 and 9 expected" while reading response header from upstream,
> | >>
> | >> I'm not sure how to g about figuring out why that is happening...
> | >>
> | >> Larry
> | >>
> | >>
> | >>
> | >> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
> | >>
> | >>>
> | >>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
> | >>>
> | >>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
> | >>>>> Now, I've moved on to trying to get nginx to run through
> | >>>>> FASTCGI to Seaside on port 9001.
> | >>>>> I seem to be getting the following walkback when trying to
> | >>>>> access my Seaside server.
> | >>>>>
> | >>>>> I'm trying to start the WAFastCGIAdaptor from inside an image
> | >>>>> (WAFastCGIAdaptor startOn: 9001)
> | >>>>> but that never returns and if I try to execute an http request
> | >>>>> I get a 502 Bad Gateway message
> | >>>>> instead of the Gateway timeout message that I got with the
> | >>>>> walkback.
> | >>>>>
> | >>>>> Any thoughts?
> | >>>>>
> | >>>>> Larry
> | >>>>
> | >>>>
> | >>>> You might be hitting an error or a halt in your code/system.
> | >>>>  Before starting the WAFastCGIAdaptor from inside the image
> | >>>> open a Gemstone Process Browser.  You can use it to terminate
> | >>>> the WAFastCGIAdaptor after getting the 502 error and then
> | >>>> examine the Object Log for errors.
> | >>>>
> | >>>>
> | >>>
> | >>> Thanks, Paul, but I can't seem to get this to work. How should I
> | >>> start the Fast CGI process, like this:
> | >>>
> | >>>
> | >>> WAGemStoneRunSeasideGems default
> | >>> name: 'FastCGI';
> | >>> adaptorClass: WAFastCGIAdaptor;
> | >>> ports: #(9001 9002 9003).
> | >>> WAGemStoneRunSeasideGems restartGems.
> | >>>
> | >>> or
> | >>>
> | >>> WAFastCGIAdaptor startOn: 9001.
> | >>>
> | >>> ??
> | >>>
> | >>> Looking in the process browser, I don't see anything that I can
> | >>> easily identify as a FasCGI process. What does it look like?
> | >>>
> | >>> Bringing up the object log does not seem to give me the exception
> | >>> I need to debug.
> | >>>
> | >>>
> | >>> I think I have this walkback: HTTPException does not have a
> | >>> raiseResponse method, although, poking around I found this
> | >>>
> | >>> raiseResponseCode: aNumber
> | >>> "Raise an exception to immediatelly return http response with
> | >>> that code"
> | >>> ^self raiseResponse: (HTTPResponse new code: aNumber)
> | >>>
> | >>>
> | >>> raiseResponse: aHTTPResponse
> | >>> "Raise an exception to immediatelly return that response."
> | >>> ^self new
> | >>> response: aHTTPResponse;
> | >>> signal.
> | >>>
> | >>> which I found back in Swazoo 2.1
> | >>>
> | >>>
> | >>> Which version of Swazoo should I be loading?
> | >>>
> | >>> Larry
> | >>>
> | >>>
> | >>>
> | >>> [seasideuser@ip-10-245-218-240 log]$ vi
> | >>> WAFastCGIAdaptor_server-9001.log
> | >>>
> | >>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port 9001
> | >>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood 2010:
> | >>> No method was found for the selector <#''raiseResponse:''> when
> | >>> sent to <HTTPException> with arguments contained in <anArray(
> | >>> aHTTPResponse)>.'
> | >>> ----------- Swazoo2 Internal Error LOG ENTRY: anArray-----------
> | >>> ----------- Swazoo2 Internal Error ERROR Encountered:
> | >>> 2012-01-16T18:57:58.17819499969482-08:00
> | >>> MessageNotUnderstood 2010: No method was found for the selector
> | >>> <#'raiseResponse:'> when sent to <HTTPException> with arguments
> | >>> contained in <anArray( aHTTPResponse)>.
> | >>> 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
> | >>> 185648385]
> | >>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12
> | >>>  [GsMethod OOP 185651457]
> | >>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod OOP
> | >>> 185463297]
> | >>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10  [GsMethod
> | >>> OOP 186133761]
> | >>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP
> | >>> 186134017]
> | >>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4 line 6
> | >>>  [GsMethod OOP 185649665]
> | >>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
> | >>> 10065409]
> | >>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
> | >>> 10062081]
> | >>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
> | >>>  [GsMethod OOP 9005057]
> | >>> 22 SpExceptionContext class >> for:on:do: @2 line 6  [GsMethod
> | >>> OOP 22311937]
> | >>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod OOP
> | >>> 185649665]
> | >>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8  [GsMethod
> | >>> OOP 185651201]
> | >>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6
> | >>>  [GsMethod OOP 185651457]
> | >>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
> | >>> 10065409]
> | >>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
> | >>> 10062081]
> | >>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8  [GsMethod
> | >>> OOP 9005057]
> | >>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9
> | >>>  [GsMethod OOP 185651457]
> | >>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
> | >>>  [GsMethod OOP 116163329]
> | >>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | >>>  [GsMethod OOP 2304001]
> | >>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | >>>  [GsMethod OOP 2304001]
> | >>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line 8
> | >>>  [GsMethod OOP 116163329]
> | >>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13
> | >>>  [GsMethod OOP 185651457]
> | >>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP
> | >>> 185651457]
> | >>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP
> | >>> 186054145]
> | >>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod OOP
> | >>> 186054913]
> | >>>
> | >>>
> | >>>
> | >>
> | >
> |
> |

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Dale Henrichs
Lawrence,

To manually check for a new version of Seaside, you can print the following:

  ConfigurationOfSeaside30 project updateProject.
  ConfigurationOfSeaside30 project latestVersion.

If I were to implement an 'Update Seaside' button it would do the following:

  ConfigurationOfSeaside30 project updateProject.
  (ConfigurationOfSeaside30 project latestVersion > ConfigurationOfSeaside30 project currentVersion)
        ifTrue: [ ConfigurationOfSeaside30 project latestVersion load ].

Of course you'd want to do a backup first and you'd want to customize the load expression to load only the things that you want from Seaside30.

Using #load will get just about everything loaded (except the Zinc adaptor). For production I usually don't like to have the Seaside-Development packages loaded because they install the dev tool bar and allow anyone to access an inspector (which means they can evaluate arbitrary expressions) which is not cool for production.

I think that Seaside 3.0.6.3 is the latest version for GemStone ...

Dale

----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, January 18, 2012 10:03:05 AM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
|
| On Jan 18, 2012, at 12:40 PM, Dale Henrichs wrote:
|
| > Lawrence,
| >
| > You can tell what version of Seaside you are using by printing the
| > following:
| >
| >  ConfigurationOfSeaside30 project currentVersion
| >
|
| Hello Dale,
|   I'm on 3.0.6
|
|  >=3.0.6 [ConfigurationOfSeaside30]
|
| It doesn't seem like there is an Update Seaside button on the
| launcher.
| What is the easiest way of loading in changes? Should I look through
| all of the
| Seaside packages and load more recent change sets?
|
|   Larry
|
|
| > Dale
| >
| > ----- Original Message -----
| > | From: "Lawrence Kellogg" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Wednesday, January 18, 2012 5:43:22 AM
| > | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
| > |
| > | Hello Johan,
| > |
| > | On Jan 17, 2012, at 8:53 AM, Johan Brichau wrote:
| > |
| > | > What version of GLASS are you running?
| > | >
| > | > This error pops up when you load Seaside 3.0.6+ in a GLASS
| > | > version
| > | > that is lower than 1.0-beta-8.7.1
| > | >
| > |
| > |   I have now upgraded to 1.0 beta 8.7.1.
| > |
| > |   Hmmm, I think I am on Seaside 3.0.
| > |
| > |   Should I upgrade to Seaside 3.0.6? Is there an easy way to do
| > |   that?
| > | Do I just load all of the various packages under
| > | http://seaside.gemstone.com/ss/Seaside30?
| > |
| > |   My system seems to be in a pretty stable state, at the moment,
| > |   but
| > |   I will move along with
| > | the minor releases.
| > |
| > |   Regards,
| > |
| > |   Larry
| > |
| > |
| > |  
| > |
| > | > On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:
| > | >
| > | >> I also found this error in the nginx.log file:
| > | >>
| > | >> FastCGI sent in stderr: "Reading a number failed: a digit
| > | >> between
| > | >> 0 and 9 expected" while reading response header from upstream,
| > | >>
| > | >> I'm not sure how to g about figuring out why that is
| > | >> happening...
| > | >>
| > | >> Larry
| > | >>
| > | >>
| > | >>
| > | >> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
| > | >>
| > | >>>
| > | >>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
| > | >>>
| > | >>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
| > | >>>>> Now, I've moved on to trying to get nginx to run through
| > | >>>>> FASTCGI to Seaside on port 9001.
| > | >>>>> I seem to be getting the following walkback when trying to
| > | >>>>> access my Seaside server.
| > | >>>>>
| > | >>>>> I'm trying to start the WAFastCGIAdaptor from inside an
| > | >>>>> image
| > | >>>>> (WAFastCGIAdaptor startOn: 9001)
| > | >>>>> but that never returns and if I try to execute an http
| > | >>>>> request
| > | >>>>> I get a 502 Bad Gateway message
| > | >>>>> instead of the Gateway timeout message that I got with the
| > | >>>>> walkback.
| > | >>>>>
| > | >>>>> Any thoughts?
| > | >>>>>
| > | >>>>> Larry
| > | >>>>
| > | >>>>
| > | >>>> You might be hitting an error or a halt in your code/system.
| > | >>>>  Before starting the WAFastCGIAdaptor from inside the image
| > | >>>> open a Gemstone Process Browser.  You can use it to
| > | >>>> terminate
| > | >>>> the WAFastCGIAdaptor after getting the 502 error and then
| > | >>>> examine the Object Log for errors.
| > | >>>>
| > | >>>>
| > | >>>
| > | >>> Thanks, Paul, but I can't seem to get this to work. How
| > | >>> should I
| > | >>> start the Fast CGI process, like this:
| > | >>>
| > | >>>
| > | >>> WAGemStoneRunSeasideGems default
| > | >>> name: 'FastCGI';
| > | >>> adaptorClass: WAFastCGIAdaptor;
| > | >>> ports: #(9001 9002 9003).
| > | >>> WAGemStoneRunSeasideGems restartGems.
| > | >>>
| > | >>> or
| > | >>>
| > | >>> WAFastCGIAdaptor startOn: 9001.
| > | >>>
| > | >>> ??
| > | >>>
| > | >>> Looking in the process browser, I don't see anything that I
| > | >>> can
| > | >>> easily identify as a FasCGI process. What does it look like?
| > | >>>
| > | >>> Bringing up the object log does not seem to give me the
| > | >>> exception
| > | >>> I need to debug.
| > | >>>
| > | >>>
| > | >>> I think I have this walkback: HTTPException does not have a
| > | >>> raiseResponse method, although, poking around I found this
| > | >>>
| > | >>> raiseResponseCode: aNumber
| > | >>> "Raise an exception to immediatelly return http response
| > | >>> with
| > | >>> that code"
| > | >>> ^self raiseResponse: (HTTPResponse new code: aNumber)
| > | >>>
| > | >>>
| > | >>> raiseResponse: aHTTPResponse
| > | >>> "Raise an exception to immediatelly return that response."
| > | >>> ^self new
| > | >>> response: aHTTPResponse;
| > | >>> signal.
| > | >>>
| > | >>> which I found back in Swazoo 2.1
| > | >>>
| > | >>>
| > | >>> Which version of Swazoo should I be loading?
| > | >>>
| > | >>> Larry
| > | >>>
| > | >>>
| > | >>>
| > | >>> [seasideuser@ip-10-245-218-240 log]$ vi
| > | >>> WAFastCGIAdaptor_server-9001.log
| > | >>>
| > | >>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port
| > | >>> 9001
| > | >>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood
| > | >>> 2010:
| > | >>> No method was found for the selector <#''raiseResponse:''>
| > | >>> when
| > | >>> sent to <HTTPException> with arguments contained in <anArray(
| > | >>> aHTTPResponse)>.'
| > | >>> ----------- Swazoo2 Internal Error LOG ENTRY:
| > | >>> anArray-----------
| > | >>> ----------- Swazoo2 Internal Error ERROR Encountered:
| > | >>> 2012-01-16T18:57:58.17819499969482-08:00
| > | >>> MessageNotUnderstood 2010: No method was found for the
| > | >>> selector
| > | >>> <#'raiseResponse:'> when sent to <HTTPException> with
| > | >>> arguments
| > | >>> contained in <anArray( aHTTPResponse)>.
| > | >>> 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
| > | >>> 185648385]
| > | >>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12
| > | >>>  [GsMethod OOP 185651457]
| > | >>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod
| > | >>> OOP
| > | >>> 185463297]
| > | >>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10
| > | >>>  [GsMethod
| > | >>> OOP 186133761]
| > | >>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP
| > | >>> 186134017]
| > | >>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4
| > | >>> line 6
| > | >>>  [GsMethod OOP 185649665]
| > | >>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | >>> 10065409]
| > | >>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | >>> 10062081]
| > | >>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
| > | >>>  [GsMethod OOP 9005057]
| > | >>> 22 SpExceptionContext class >> for:on:do: @2 line 6
| > | >>>  [GsMethod
| > | >>> OOP 22311937]
| > | >>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod
| > | >>> OOP
| > | >>> 185649665]
| > | >>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8
| > | >>>  [GsMethod
| > | >>> OOP 185651201]
| > | >>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6
| > | >>>  [GsMethod OOP 185651457]
| > | >>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
| > | >>> 10065409]
| > | >>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
| > | >>> 10062081]
| > | >>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
| > | >>>  [GsMethod
| > | >>> OOP 9005057]
| > | >>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9
| > | >>>  [GsMethod OOP 185651457]
| > | >>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
| > | >>>  [GsMethod OOP 116163329]
| > | >>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
| > | >>>  [GsMethod OOP 2304001]
| > | >>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
| > | >>>  [GsMethod OOP 2304001]
| > | >>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line
| > | >>> 8
| > | >>>  [GsMethod OOP 116163329]
| > | >>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13
| > | >>>  [GsMethod OOP 185651457]
| > | >>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP
| > | >>> 185651457]
| > | >>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP
| > | >>> 186054145]
| > | >>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod
| > | >>> OOP
| > | >>> 186054913]
| > | >>>
| > | >>>
| > | >>>
| > | >>
| > | >
| > |
| > |
|
|
Larry Kellogg
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Larry Kellogg

On Jan 18, 2012, at 2:31 PM, Dale Henrichs wrote:

> Lawrence,
>
> To manually check for a new version of Seaside, you can print the following:
>
>  ConfigurationOfSeaside30 project updateProject.
>  ConfigurationOfSeaside30 project latestVersion.
>
> If I were to implement an 'Update Seaside' button it would do the following:
>
>  ConfigurationOfSeaside30 project updateProject.
>  (ConfigurationOfSeaside30 project latestVersion > ConfigurationOfSeaside30 project currentVersion)
> ifTrue: [ ConfigurationOfSeaside30 project latestVersion load ].
>
> Of course you'd want to do a backup first and you'd want to customize the load expression to load only the things that you want from Seaside30.
>

Dale,
  Thanks for the code. I have become used to backing up both my systems now. I try out changes in my Staging environment first before applying the same changes to Production.

> Using #load will get just about everything loaded (except the Zinc adaptor). For production I usually don't like to have the Seaside-Development packages loaded because they install the dev tool bar and allow anyone to access an inspector (which means they can evaluate arbitrary expressions) which is not cool for production.
>

  Is there a way to hide the dev tool bar for normal users but show it for adminstrators? It seems like I might have to debug problems in the Production environment and it might be nice to have some of those tools.
When you say dev tool bar, you mean the one with "New Session Configure Halos XHTML", right?

  I have noticed kind of a funny thing with regards to sessions. After logging out, and going back to my login task, sometimes a valid login attempt will just clear the fields and do nothing.
Hitting the new session button fixes this issue. Maybe I'm not resetting something properly.

  As for not letting the users mess with code, I agree. A programmer (not me!) on one of the projects I worked on decided to store Smalltalk code in an SQL database, in the clear! Later, to our horror, we
discovered that some clients were updating the Smalltalk code through SQL!

  Regards,

  Larry




> I think that Seaside 3.0.6.3 is the latest version for GemStone ...
>
> Dale
>
> ----- Original Message -----
> | From: "Lawrence Kellogg" <[hidden email]>
> | To: "GemStone Seaside beta discussion" <[hidden email]>
> | Sent: Wednesday, January 18, 2012 10:03:05 AM
> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
> |
> |
> | On Jan 18, 2012, at 12:40 PM, Dale Henrichs wrote:
> |
> | > Lawrence,
> | >
> | > You can tell what version of Seaside you are using by printing the
> | > following:
> | >
> | >  ConfigurationOfSeaside30 project currentVersion
> | >
> |
> | Hello Dale,
> |   I'm on 3.0.6
> |
> |  >=3.0.6 [ConfigurationOfSeaside30]
> |
> | It doesn't seem like there is an Update Seaside button on the
> | launcher.
> | What is the easiest way of loading in changes? Should I look through
> | all of the
> | Seaside packages and load more recent change sets?
> |
> |   Larry
> |
> |
> | > Dale
> | >
> | > ----- Original Message -----
> | > | From: "Lawrence Kellogg" <[hidden email]>
> | > | To: "GemStone Seaside beta discussion"
> | > | <[hidden email]>
> | > | Sent: Wednesday, January 18, 2012 5:43:22 AM
> | > | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
> | > |
> | > | Hello Johan,
> | > |
> | > | On Jan 17, 2012, at 8:53 AM, Johan Brichau wrote:
> | > |
> | > | > What version of GLASS are you running?
> | > | >
> | > | > This error pops up when you load Seaside 3.0.6+ in a GLASS
> | > | > version
> | > | > that is lower than 1.0-beta-8.7.1
> | > | >
> | > |
> | > |   I have now upgraded to 1.0 beta 8.7.1.
> | > |
> | > |   Hmmm, I think I am on Seaside 3.0.
> | > |
> | > |   Should I upgrade to Seaside 3.0.6? Is there an easy way to do
> | > |   that?
> | > | Do I just load all of the various packages under
> | > | http://seaside.gemstone.com/ss/Seaside30?
> | > |
> | > |   My system seems to be in a pretty stable state, at the moment,
> | > |   but
> | > |   I will move along with
> | > | the minor releases.
> | > |
> | > |   Regards,
> | > |
> | > |   Larry
> | > |
> | > |
> | > |  
> | > |
> | > | > On 17 Jan 2012, at 14:50, Lawrence Kellogg wrote:
> | > | >
> | > | >> I also found this error in the nginx.log file:
> | > | >>
> | > | >> FastCGI sent in stderr: "Reading a number failed: a digit
> | > | >> between
> | > | >> 0 and 9 expected" while reading response header from upstream,
> | > | >>
> | > | >> I'm not sure how to g about figuring out why that is
> | > | >> happening...
> | > | >>
> | > | >> Larry
> | > | >>
> | > | >>
> | > | >>
> | > | >> On Jan 17, 2012, at 6:50 AM, Lawrence Kellogg wrote:
> | > | >>
> | > | >>>
> | > | >>> On Jan 16, 2012, at 11:17 PM, Paul DeBruicker wrote:
> | > | >>>
> | > | >>>> On 12-01-16 06:29 PM, Lawrence Kellogg wrote:
> | > | >>>>> Now, I've moved on to trying to get nginx to run through
> | > | >>>>> FASTCGI to Seaside on port 9001.
> | > | >>>>> I seem to be getting the following walkback when trying to
> | > | >>>>> access my Seaside server.
> | > | >>>>>
> | > | >>>>> I'm trying to start the WAFastCGIAdaptor from inside an
> | > | >>>>> image
> | > | >>>>> (WAFastCGIAdaptor startOn: 9001)
> | > | >>>>> but that never returns and if I try to execute an http
> | > | >>>>> request
> | > | >>>>> I get a 502 Bad Gateway message
> | > | >>>>> instead of the Gateway timeout message that I got with the
> | > | >>>>> walkback.
> | > | >>>>>
> | > | >>>>> Any thoughts?
> | > | >>>>>
> | > | >>>>> Larry
> | > | >>>>
> | > | >>>>
> | > | >>>> You might be hitting an error or a halt in your code/system.
> | > | >>>>  Before starting the WAFastCGIAdaptor from inside the image
> | > | >>>> open a Gemstone Process Browser.  You can use it to
> | > | >>>> terminate
> | > | >>>> the WAFastCGIAdaptor after getting the 502 error and then
> | > | >>>> examine the Object Log for errors.
> | > | >>>>
> | > | >>>>
> | > | >>>
> | > | >>> Thanks, Paul, but I can't seem to get this to work. How
> | > | >>> should I
> | > | >>> start the Fast CGI process, like this:
> | > | >>>
> | > | >>>
> | > | >>> WAGemStoneRunSeasideGems default
> | > | >>> name: 'FastCGI';
> | > | >>> adaptorClass: WAFastCGIAdaptor;
> | > | >>> ports: #(9001 9002 9003).
> | > | >>> WAGemStoneRunSeasideGems restartGems.
> | > | >>>
> | > | >>> or
> | > | >>>
> | > | >>> WAFastCGIAdaptor startOn: 9001.
> | > | >>>
> | > | >>> ??
> | > | >>>
> | > | >>> Looking in the process browser, I don't see anything that I
> | > | >>> can
> | > | >>> easily identify as a FasCGI process. What does it look like?
> | > | >>>
> | > | >>> Bringing up the object log does not seem to give me the
> | > | >>> exception
> | > | >>> I need to debug.
> | > | >>>
> | > | >>>
> | > | >>> I think I have this walkback: HTTPException does not have a
> | > | >>> raiseResponse method, although, poking around I found this
> | > | >>>
> | > | >>> raiseResponseCode: aNumber
> | > | >>> "Raise an exception to immediatelly return http response
> | > | >>> with
> | > | >>> that code"
> | > | >>> ^self raiseResponse: (HTTPResponse new code: aNumber)
> | > | >>>
> | > | >>>
> | > | >>> raiseResponse: aHTTPResponse
> | > | >>> "Raise an exception to immediatelly return that response."
> | > | >>> ^self new
> | > | >>> response: aHTTPResponse;
> | > | >>> signal.
> | > | >>>
> | > | >>> which I found back in Swazoo 2.1
> | > | >>>
> | > | >>>
> | > | >>> Which version of Swazoo should I be loading?
> | > | >>>
> | > | >>> Larry
> | > | >>>
> | > | >>>
> | > | >>>
> | > | >>> [seasideuser@ip-10-245-218-240 log]$ vi
> | > | >>> WAFastCGIAdaptor_server-9001.log
> | > | >>>
> | > | >>> topaz 1> topaz 1> WAFastCGIAdaptor Server started on port
> | > | >>> 9001
> | > | >>> --transcript--'Swazoo2 Internal Error: MessageNotUnderstood
> | > | >>> 2010:
> | > | >>> No method was found for the selector <#''raiseResponse:''>
> | > | >>> when
> | > | >>> sent to <HTTPException> with arguments contained in <anArray(
> | > | >>> aHTTPResponse)>.'
> | > | >>> ----------- Swazoo2 Internal Error LOG ENTRY:
> | > | >>> anArray-----------
> | > | >>> ----------- Swazoo2 Internal Error ERROR Encountered:
> | > | >>> 2012-01-16T18:57:58.17819499969482-08:00
> | > | >>> MessageNotUnderstood 2010: No method was found for the
> | > | >>> selector
> | > | >>> <#'raiseResponse:'> when sent to <HTTPException> with
> | > | >>> arguments
> | > | >>> contained in <anArray( aHTTPResponse)>.
> | > | >>> 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
> | > | >>> 185648385]
> | > | >>> 4 ComplexBlock in HTTPConnection >> interact @11 line 12
> | > | >>>  [GsMethod OOP 185651457]
> | > | >>> 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 HTTPException class >> notImplemented @4 line 2  [GsMethod
> | > | >>> OOP
> | > | >>> 185463297]
> | > | >>> 16 HTTPRequest class >> newFor:readFrom: @17 line 10
> | > | >>>  [GsMethod
> | > | >>> OOP 186133761]
> | > | >>> 17 HTTPRequest class >> readFrom: @4 line 8  [GsMethod OOP
> | > | >>> 186134017]
> | > | >>> 18 ComplexVCBlock in HTTPConnection >> readRequestFor: @4
> | > | >>> line 6
> | > | >>>  [GsMethod OOP 185649665]
> | > | >>> 19 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
> | > | >>> 10065409]
> | > | >>> 20 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
> | > | >>> 10062081]
> | > | >>> 21 ComplexVCBlock in ExecutableBlock >> on:do: @2 line 8
> | > | >>>  [GsMethod OOP 9005057]
> | > | >>> 22 SpExceptionContext class >> for:on:do: @2 line 6
> | > | >>>  [GsMethod
> | > | >>> OOP 22311937]
> | > | >>> 23 HTTPConnection >> readRequestFor: @40 line 5  [GsMethod
> | > | >>> OOP
> | > | >>> 185649665]
> | > | >>> 24 HTTPConnection >> getAndDispatchMessages @7 line 8
> | > | >>>  [GsMethod
> | > | >>> OOP 185651201]
> | > | >>> 25 ComplexBlock in HTTPConnection >> interact @7 line 6
> | > | >>>  [GsMethod OOP 185651457]
> | > | >>> 26 ExceptionHandler >> doTryBlock: @9 line 7  [GsMethod OOP
> | > | >>> 10065409]
> | > | >>> 27 ExceptionHandler >> try:on:do: @15 line 18  [GsMethod OOP
> | > | >>> 10062081]
> | > | >>> 28 ComplexBlock in ExecutableBlock >> on:do: @2 line 8
> | > | >>>  [GsMethod
> | > | >>> OOP 9005057]
> | > | >>> 29 ComplexVCBlock in HTTPConnection >> interact @12 line 9
> | > | >>>  [GsMethod OOP 185651457]
> | > | >>> 30 ComplexBlock in ExecutableBlock >> ifCurtailed: @4 line 6
> | > | >>>  [GsMethod OOP 116163329]
> | > | >>> 31 ComplexBlock in ExecutableBlock >> ensure: @4 line 11
> | > | >>>  [GsMethod OOP 2304001]
> | > | >>> 32 ComplexBlock in ExecutableBlock >> ensure: @6 line 11
> | > | >>>  [GsMethod OOP 2304001]
> | > | >>> 33 ComplexVCBlock in ExecutableBlock >> ifCurtailed: @8 line
> | > | >>> 8
> | > | >>>  [GsMethod OOP 116163329]
> | > | >>> 34 ComplexVCBlock in HTTPConnection >> interact @19 line 13
> | > | >>>  [GsMethod OOP 185651457]
> | > | >>> 35 HTTPConnection >> interact @26 line 18  [GsMethod OOP
> | > | >>> 185651457]
> | > | >>> 36 HTTPServer >> acceptConnection @14 line 13  [GsMethod OOP
> | > | >>> 186054145]
> | > | >>> 37 ComplexBlock in HTTPServer >> start @13 line 6  [GsMethod
> | > | >>> OOP
> | > | >>> 186054913]
> | > | >>>
> | > | >>>
> | > | >>>
> | > | >>
> | > | >
> | > |
> | > |
> |
> |

Dale Henrichs
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Running SeasideGems, confusion

Dale Henrichs


----- Original Message -----
| From: "Lawrence Kellogg" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, January 18, 2012 2:01:32 PM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
|
| On Jan 18, 2012, at 2:31 PM, Dale Henrichs wrote:
|
| Dale,
|   Thanks for the code. I have become used to backing up both my
|   systems now. I try out changes in my Staging environment first
|   before applying the same changes to Production.
|
| > Using #load will get just about everything loaded (except the Zinc
| > adaptor). For production I usually don't like to have the
| > Seaside-Development packages loaded because they install the dev
| > tool bar and allow anyone to access an inspector (which means they
| > can evaluate arbitrary expressions) which is not cool for
| > production.
| >
|
|   Is there a way to hide the dev tool bar for normal users but show
|   it for adminstrators? It seems like I might have to debug problems
|   in the Production environment and it might be nice to have some of
|   those tools.
| When you say dev tool bar, you mean the one with "New Session
| Configure Halos XHTML", right?

Yes that's the one.

I don't believe that there is a way to conditionally hide the tool bar. For production issues you should be able to get nearly everything that you need by debugging the continuation for errors, since you can use the GemTools inspectors/browsers etc. to debug errors ...

As for the other tool bar capabilities ... you could have the tool bar enabled in your Scratch environment and disabled in production ...

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

I think I need a more explicit example of the problem to understand what might be happening.

|
|   As for not letting the users mess with code, I agree. A programmer
|   (not me!) on one of the projects I worked on decided to store
|   Smalltalk code in an SQL database, in the clear! Later, to our
|   horror, we
| discovered that some clients were updating the Smalltalk code through
| SQL!

Haha, that can be spooky ... makes it really hard to debug issues:)

Dale
123456
Free forum by Nabble Edit this page