what does this means?
Locked
 
|
Hi,
I'm having this error message... without callback or any other explanation. Does anybody knows what this means? InterpreterError 2407: The object may not be committed, instances of its class are non-persistent. Cheers, Esteban |
|
|
Am 02.12.2010 um 00:02 schrieb Esteban Lorenzano: > Hi, > I'm having this error message... without callback or any other > explanation. Does anybody knows what this means? > > InterpreterError 2407: The object may not be committed, instances of > its class are non-persistent. I had this sort of error just yesterday. I am porting the Toothpick logging framework from Pharo to GemStone and it uses the class Semaphore. In GemStone Semaphore is a non-persisting class and yields to that error, if you store it in an other's object instance variable. The solution for Semaphore was to use the special db-transient wrapper called TransientSemaphore (see the GemStone ProgGuide on keyword "DbTransient" for general explanation). Maybe your problem is related to Semaphore or any other class in GemStone which can not be persisted. BTW: Grease has a platform specific helper to get the correct semaphore class on each platform: GRPlatform>>semaphoreClass. Greetings Andreas |
|
|
On 12/02/2010 12:50 AM, Brodbeck Andreas wrote:
> > Am 02.12.2010 um 00:02 schrieb Esteban Lorenzano: > >> Hi, >> I'm having this error message... without callback or any other >> explanation. Does anybody knows what this means? >> >> InterpreterError 2407: The object may not be committed, instances of >> its class are non-persistent. > > > I had this sort of error just yesterday. I am porting the Toothpick > logging framework from Pharo to GemStone and it uses the class > Semaphore. In GemStone Semaphore is a non-persisting class and yields > to that error, if you store it in an other's object instance variable. > The solution for Semaphore was to use the special db-transient wrapper > called TransientSemaphore (see the GemStone ProgGuide on keyword > "DbTransient" for general explanation). Maybe your problem is related > to Semaphore or any other class in GemStone which can not be persisted. > > BTW: Grease has a platform specific helper to get the correct > semaphore class on each platform: GRPlatform>>semaphoreClass. > > Greetings > > Andreas > Esteban, Brodbeck is correct... it is likely to be a Semaphore instance ... there were older issues where the Seaside framework itself was introducing Semaphores ... then there were issues like Issue 123 (http://code.google.com/p/glassdb/issues/detail?id=123) where a continuation was hanging onto stale process state that included a semaphore... I'd be interested in knowing if you have introduced some "background processing" and the Sempahore is "one of yours" or the Semaphore is sneaking into the persistent graph some other way... Brodbeck, I am curious how Toothpick is using processes/semaphore. Any processes that are running in a Seaside http vm, need to be "aware" of the fact that the Seaside framework is aborting and committing which could cause problems with threads that are running in parallel.. Dale |
|
|
Am 03.12.2010 um 00:31 schrieb Dale Henrichs: > > Brodbeck, > Actually that's my family name. Andreas = 'Andrew'. ;-) > I am curious how Toothpick is using processes/semaphore. Any > processes that are running in a Seaside http vm, need to be "aware" > of the fact that the Seaside framework is aborting and committing > which could cause problems with threads that are running in parallel.. > > Dale Toothpick uses Semaphores to prevent concurrent writes to a logger stream/file from being interwoven. The mutex is instantiated only at 2 places, both time with "GRPlatform current semaphoreClass forMutualExclusion". It is used in a few places, always with "mutex critical: [...]". I don't understand this topic deeply, but I guess that Toothpick does not have own processes, and should be safe for usage with seaside, I guess. Andreas |
|
|
On 12/03/2010 01:36 PM, Brodbeck Andreas wrote:
> > Am 03.12.2010 um 00:31 schrieb Dale Henrichs: > >> >> Brodbeck, >> > > Actually that's my family name. Andreas = 'Andrew'. ;-) Sorry about that .... Andreas, I get confused at times.... > >> I am curious how Toothpick is using processes/semaphore. Any >> processes that are running in a Seaside http vm, need to be "aware" >> of the fact that the Seaside framework is aborting and committing >> which could cause problems with threads that are running in parallel.. >> >> Dale > > Toothpick uses Semaphores to prevent concurrent writes to a logger > stream/file from being interwoven. The mutex is instantiated only at 2 > places, both time with "GRPlatform current semaphoreClass > forMutualExclusion". It is used in a few places, always with "mutex > critical: [...]". > > I don't understand this topic deeply, but I guess that Toothpick does > not have own processes, and should be safe for usage with seaside, I > guess. In your scenario where you keep a persistent logger around, then using the TransientSemaphore is the correct solution. It doesn't sound like the logger has any of "it's own threads" running around. For GemStone you might want to consider what could happen if two gems tried to write to the same file at the same time...an object lock would probably be the thing to use instead of (or in addition to) a semaphore. If each gem is intended to log to a unique file then no object lock would be needed. Dale |
|
|
In reply to this post by Dale Henrichs
On 12/02/2010 06:31 PM, Dale Henrichs wrote:
> > I'd be interested in knowing if you have introduced some "background > processing" and the Sempahore is "one of yours" or the Semaphore is > sneaking into the persistent graph some other way... Hi Dale, I think they may be sneaking in some other way. In porting this application I'm getting some 2407 errors as it attempts to commit instances of ProcessorScheduler. I've pasted what I think are the relevant parts of the Swazoo_server-8383.log below. I don't know how to get a full stack of the error. Let me know if you need it and how to get it and I'll send it along. Thanks Paul ----------- Internal Swazoo ERROR Encountered: 2010-12-07T07:39:25.14772009849548-08:00 InterpreterError 2407: The object <aProcessorScheduler> may not be committed, instances of its class are non-persistent. 1 GRGemStonePlatform >> logError:title: @2 line 4 [GsMethod OOP 153291777] 2 WAGsSwazooAdaptor >> internalServerErrorMessage: @10 line 12 [GsMethod OOP 172146433] 3 ComplexBlock in GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: @29 line 20 [GsMethod OOP 153294081] 4 ExceptionHandler >> caughtExceptionWithAction: @5 line 4 [GsMethod OOP 10065153] 5 ComplexBlock in ExceptionHandler >> caughtEx:number:cat:args:handler: @12 line 13 [GsMethod OOP 10064641] 6 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod OOP 2304001] 7 ComplexBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod OOP 2304001] 8 ExceptionHandler >> caughtEx:number:cat:args:handler: @16 line 14 [GsMethod OOP 10064641] 9 ComplexBlock in ExceptionHandler >> try:on:do: @10 line 12 [GsMethod OOP 10062081] 10 Object >> _gsReturnTos @1 line 1 [GsMethod OOP 1877761] 11 System class >> __commit: @1 line 8 [GsMethod OOP 3222017] 12 System class >> _localCommit: @8 line 30 [GsMethod OOP 3222529] 13 TransactionBoundaryDefaultPolicy >> commit: @2 line 3 [GsMethod OOP 7713281] 14 System class >> _commit: @6 line 16 [GsMethod OOP 3222785] 15 System class >> commitTransaction @2 line 28 [GsMethod OOP 3230465] 16 System class >> _commitPrintingDiagnostics @2 line 9 [GsMethod OOP 3151105] 17 SystemCommitTransaction >> defaultAction @1 line 3 [GsMethod OOP 151059201] 18 ExceptionA >> _defaultAction @1 line 4 [GsMethod OOP 10050561] 19 ExceptionA >> signal @7 line 37 [GsMethod OOP 10057473] 20 ExceptionA >> signal: @3 line 12 [GsMethod OOP 10050817] 21 ExceptionA class >> signal: @2 line 3 [GsMethod OOP 11895041] 22 ExceptionA class >> signal @2 line 9 [GsMethod OOP 11896577] 23 GRGemStonePlatform >> doCommitTransaction @3 line 3 [GsMethod OOP 153292545] 24 ComplexVCBlock in GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: @32 line 32 [GsMethod OOP 153293825] 25 ComplexBlock in ExecutableBlock >> ensure: @4 line 11 [GsMethod OOP 2304001] 26 ComplexVCBlock in ExecutableBlock >> ensure: @6 line 11 [GsMethod OOP 2304001] 27 TransientRecursionLock >> critical: @15 line 8 [GsMethod OOP 21159937] 28 GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock: @43 line 5 [GsMethod OOP 153293825] 29 ComplexBlock in GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock: @7 line 9 [GsMethod OOP 153294081] 30 ExceptionHandler >> doTryBlock: @9 line 7 [GsMethod OOP 10065409] 31 ExceptionHandler >> try:on:do: @15 line 18 [GsMethod OOP 10062081] |
|
|
Paul,
It is difficult to debug these problems, because it is difficult to find the offending reference and you can't (obviously) commit anything of interest when the error occurs. And the stack isn't much help ... At first blush this looks like it could be related to Issue 123, but then the bug was fixed in 2.4.4.1 in the vm...there might be other spots in the vm that expose this bug though.... What version of GemStone/S are you using? Are you certain that the application that you are porting is not doing any forking or other process manipulation? Probably the best way to get a handle on the problem is to run the seaside server in a development vm, so that you can use the GemTools debugger to poke around. Since you are using Swazoo you'd do something like this in a GemTools workspace: WAGsSwazooAdaptor startOn: 8383. Take a look at the Seaside3.0 workspace (under View... menu) for additional expressions that might be useful. Swazoo doesn't reliably shut down it's socket when using #stop, so sometimes you have to restart your GemTools vm ... Anyway once you get your hands on this commit problem we'll want to know what http request you were performing and therefore what seaside component was involved in the bad transaction ... it will be interesting to note if it caused by the same http request every time or if there are any other useful patters...If we're able to isolate to a specific component and there is nothing obviously funky going on, then we need to start paring back on what the component does until we can isolate the offending message ... then set a breakpoint and track the execution to see if we can find the problem ... With ProcessScheduler involved we have to assume that someone is doing a Delay or some other operation that involves Semaphores or Process manipulation... Dale On 12/07/2010 08:09 AM, Paul DeBruicker wrote: > On 12/02/2010 06:31 PM, Dale Henrichs wrote: >> >> I'd be interested in knowing if you have introduced some "background >> processing" and the Sempahore is "one of yours" or the Semaphore is >> sneaking into the persistent graph some other way... > > Hi Dale, > > I think they may be sneaking in some other way. In porting this > application I'm getting some 2407 errors as it attempts to commit > instances of ProcessorScheduler. > > I've pasted what I think are the relevant parts of the > Swazoo_server-8383.log below. I don't know how to get a full stack of > the error. Let me know if you need it and how to get it and I'll send > it along. > > Thanks > > Paul > > ----------- Internal Swazoo ERROR Encountered: > 2010-12-07T07:39:25.14772009849548-08:00 > InterpreterError 2407: The object<aProcessorScheduler> may not be > committed, instances of its class are non-persistent. > 1 GRGemStonePlatform>> logError:title: @2 line 4 [GsMethod OOP 153291777] > 2 WAGsSwazooAdaptor>> internalServerErrorMessage: @10 line 12 > [GsMethod OOP 172146433] > 3 ComplexBlock in GRGemStonePlatform>> > seasideProcessRequest:adaptor:resultBlock: @29 line 20 [GsMethod OOP > 153294081] > 4 ExceptionHandler>> caughtExceptionWithAction: @5 line 4 [GsMethod > OOP 10065153] > 5 ComplexBlock in ExceptionHandler>> caughtEx:number:cat:args:handler: > @12 line 13 [GsMethod OOP 10064641] > 6 ComplexBlock in ExecutableBlock>> ensure: @4 line 11 [GsMethod OOP > 2304001] > 7 ComplexBlock in ExecutableBlock>> ensure: @6 line 11 [GsMethod OOP > 2304001] > 8 ExceptionHandler>> caughtEx:number:cat:args:handler: @16 line 14 > [GsMethod OOP 10064641] > 9 ComplexBlock in ExceptionHandler>> try:on:do: @10 line 12 [GsMethod > OOP 10062081] > 10 Object>> _gsReturnTos @1 line 1 [GsMethod OOP 1877761] > 11 System class>> __commit: @1 line 8 [GsMethod OOP 3222017] > 12 System class>> _localCommit: @8 line 30 [GsMethod OOP 3222529] > 13 TransactionBoundaryDefaultPolicy>> commit: @2 line 3 [GsMethod OOP > 7713281] > 14 System class>> _commit: @6 line 16 [GsMethod OOP 3222785] > 15 System class>> commitTransaction @2 line 28 [GsMethod OOP 3230465] > 16 System class>> _commitPrintingDiagnostics @2 line 9 [GsMethod OOP > 3151105] > 17 SystemCommitTransaction>> defaultAction @1 line 3 [GsMethod OOP > 151059201] > 18 ExceptionA>> _defaultAction @1 line 4 [GsMethod OOP 10050561] > 19 ExceptionA>> signal @7 line 37 [GsMethod OOP 10057473] > 20 ExceptionA>> signal: @3 line 12 [GsMethod OOP 10050817] > 21 ExceptionA class>> signal: @2 line 3 [GsMethod OOP 11895041] > 22 ExceptionA class>> signal @2 line 9 [GsMethod OOP 11896577] > 23 GRGemStonePlatform>> doCommitTransaction @3 line 3 [GsMethod OOP > 153292545] > 24 ComplexVCBlock in GRGemStonePlatform>> > seasideProcessRequestWithRetry:resultBlock: @32 line 32 [GsMethod OOP > 153293825] > 25 ComplexBlock in ExecutableBlock>> ensure: @4 line 11 [GsMethod OOP > 2304001] > 26 ComplexVCBlock in ExecutableBlock>> ensure: @6 line 11 [GsMethod > OOP 2304001] > 27 TransientRecursionLock>> critical: @15 line 8 [GsMethod OOP 21159937] > 28 GRGemStonePlatform>> seasideProcessRequestWithRetry:resultBlock: @43 > line 5 [GsMethod OOP 153293825] > 29 ComplexBlock in GRGemStonePlatform>> > seasideProcessRequest:adaptor:resultBlock: @7 line 9 [GsMethod OOP > 153294081] > 30 ExceptionHandler>> doTryBlock: @9 line 7 [GsMethod OOP 10065409] > 31 ExceptionHandler>> try:on:do: @15 line 18 [GsMethod OOP 10062081] > |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |