I had a problem where my image became unusable a few seconds after starting up. I got help on the database discord channel, and got my image back to usable. Here’s a summary. [MacOS, Pharo9, MongoTalk 1.24, the image runs a Seaside,Voyage,Mongo app].
1. I got the stack trace (see attached) a few seconds after image startup, then the image became unusable and had to be terminated from the OS. 2. I eventually figured out that I needed to re-establish the ssh tunnel to my mongo database. After that, I was able to start the image without problem. 3. A potential fix may have been in MongoTalk 1.25, where connections were being leaked due to non-local returns. The fix (see attached) would add an ensure: block. I filed-in the fix, which I was able to do, with the ssh tunnel on. 4. I turned off the ssh tunnel, then tried to start the image with the MongoTalk change installed and saved. But I still got the debugger after a few seconds. I eventually noticed that the image was still usable, if I just closed the debugger (actually, closed it two times, because it came up again). In the Transcript was: WARNING: Had to GC to make room for more external objects. If this happens often, it would be a good idea to either: - Raise the maxExternalSemaphores size. - Write your code to explicitly release them rather than wait for finalization. WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use You should increase this size at startup using #maxExternalSemaphoresSilently: Current table size: 1024 WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use You should increase this size at startup using #maxExternalSemaphoresSilently: Current table size: 2048 So the MongoTalk fix would have salvaged the image too. 5. Digging around, I found the following would clean things up: MongoMonitor allInstances. "size: 95" MongoMonitor allInstancesDo: [ :each | each stop; tearDown ]. Smalltalk garbageCollect. MongoMonitor allInstances. "size: 6” After that, the pharo CPU usage went down from 23% to 5% Cheers, Yanni Chiu
VirtualMachine(Object)>>error:
VirtualMachine>>maxExternalSemaphores:
ExternalSemaphoreTable class>>freedSlotsIn:ratherThanIncreaseSizeTo:
ExternalSemaphoreTable class>>collectionBasedOn:withRoomFor:
ExternalSemaphoreTable class>>privateRegisterExternalObject:
[self privateRegisterExternalObject: anObject] in ExternalSemaphoreTable
class>>registerExternalObject: in Block: [self privateRegisterExternalObject:
anObject]
[
caught := true.
self wait.
blockValue := mutuallyExcludedBlock value
] in Semaphore>>critical: in Block: [...
FullBlockClosure(BlockClosure)>>ensure:
Semaphore>>critical:
ExternalSemaphoreTable class>>registerExternalObject:
SmalltalkImage>>registerExternalObject:
Socket>>initialize:
[ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [
super new initialize: TCPSocketType ]
FullBlockClosure(BlockClosure)>>repeatWithGCIf:
Socket class>>newTCP
Socket class>>new
SocketStream class>>openConnectionToHost:port:timeout:
Mongo>>openWithTimeout:
MongoMonitor>>ensureMongoIsOpened
[ self ensureMongoIsOpened.
self doCheckAndHandleSuccess ] in MongoMonitor>>checkOnce in Block: [
self ensureMongoIsOpened....
FullBlockClosure(BlockClosure)>>on:do:
MongoMonitor>>checkOnce
MongoMonitor>>stepService
MongoMonitor(TKTService)>>iterateService
[
self iterateService.
self scheduleRecursiveTask ] in
MongoMonitor(TKTService)>>start in Block: [ ...
TKTGenericTask>>evaluateOn:
TKTTaskExecution>>doExecuteTask
TKTReadyTaskState>>performTaskExecution:
TKTTaskExecution>>executeTask
[ self executeTask ] in TKTTaskExecution>>value in Block: [ self executeTask ]
MongoPool-mongoDo...st
Description: Binary data
