Closed dalehenrich closed 9 years ago
This patch is not quite correct ... apparently there are additional errors ... and on further review ... ex pass
is not the right thing ... without a beforeUnwind: the exception is being passed, No stacks available yet for the additional errors...
After reading the code some more I take back my original assertion that the ex pass
doesn't do anything ... the ex pass
should indeed cause the gem to exit ... I am however, not convinced that we get the whole story this way ... and I think that at the end of the day, a different fix is called for ... need to think a bit ...
No ... now I do believe that the ex pass
is the right solution ... the ex pass
will be done after the original error is logged and the error will cause the gem to exit ... which is supposed to happen ... looking at the error message will tell you what you need to do to fix the problem ...
In fact what I expect to see as the additional error is actually the original error that caused the connection to fail in the first place .... so the root cause is the error that gets masked by the missing ex pass ... I think ...
So at this point, we need to apply the patch and then pay attention to the next error to figure out what is going on ...
Here's a snippet of the error encountered after applying the suggested fix:
a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #'add:'
1 GemServer >> writeGemLogEntryFor:titled: (envId 0) @3 line 3 [GsNMethod 176062209]
2 GemServer >> logStack:titled:inTransactionDo: (envId 0) @2 line 2 [GsNMethod 176066561]
3 GemServer >> logStack:titled: (envId 0) @2 line 2 [GsNMethod 176042241]
4 GemServer >> gemServerHandleErrorException: (envId 0) @9 line 6 [GsNMethod 176062465]
5 Error >> exceptionHandlingForGemServer: (envId 0) @2 line 2 [GsNMethod 176884993]
6 GemServer >> handleGemServerException: (envId 0) @2 line 5 [GsNMethod 176050945]
7 [] in GemServer >> gemServer:exceptionSet:beforeUnwind:ensure: (envId 0) @3 line 9 [GsNMethod 176569601]
8 ExecBlock >> on:do: (envId 0) @3 line 42 [GsNMethod 3730689]
9 [] in GemServer >> gemServer:exceptionSet:beforeUnwind:ensure: (envId 0) @2 line 11 [GsNMethod 176681985]
10 AbstractException >> _executeHandler: (envId 0) @3 line 8 [GsNMethod 4617217]
11 AbstractException >> _signalWith: (envId 0) @1 line 1 [GsNMethod 4594689]
12 AbstractException >> signal (envId 0) @2 line 47 [GsNMethod 4587009]
13 Object >> doesNotUnderstand: (envId 0) @9 line 10 [GsNMethod 3595265]
14 Object >> _doesNotUnderstand:args:envId:reason: (envId 0) @7 line 12 [GsNMethod 3584513]
15 [] in ZnGemServerManagingMultiThreadedServer >> socketStreamOn: (envId 0) @3 line 5 [GsNMethod 185304321]
and looking at ZnGemServerManagingMultiThreadedServer>>connections:
connections
connections
ifNil: [ connections := TransientStackValue value: OrderedCollection new ].
^ connections value
I see that the TransientStackValue class is intended to be used ONLY for objects that are alive on the stack (temps and args) ... TransientValue is the class to use for objects that are not guaranteed to be referenced from the stack for their entire lifetime ...
Let's follow the logic of using TransientStackValue in the first place:
connections
OrderedCollection is stashed in a TransientStackValue so that the collection of sockets will not be persisted in the case that a continuation causes the ZnGemServerManagingMultiThreadedServer instance to be persisted ... _setNoStubbing
is used for objects directly referenced from stack that may themselves be using TransientStackValues like instances of ZnGemServerManagingMultiThreadedServer ... and _setNoStubbing
may be needed at the next level if TransientStackValues are being used further down the chain ...green ... it looks like the real error, beyond the potential error in basicTransactionReentry method are covered by the Zinc bug: https://github.com/GsDevKit/zinc/issues/75
@JupiterJones reported the following in his log file ... scads and scads of this:
The problem appears to be in ZnNewGemServer>>basicServerOn:. The #gemServer: call in ZnNewGemServer>>basicServerOn: records the error to the log and returns, causing the system to spin the in the #repeat loop. Instead I think that the code should pass the exception after logging so that the gem will die instead of looping: