Multiple GS sessions in Polycephaly drone

Hi Bob,

Suspect a deadlock with two semaphores acquired in a different sequence by two processes. I’ve found and avoided several of these over the years. I recall at least one would happen with code that is also used during debugging.

A trick for diagnosing is to have a background process that does a “GbsConfiguration dumpAllProcessStacks” every 30 seconds or so. All process stacks get written to a file that you can review. Review the most recent file after you notice a hang. Look for two processes each holding a semaphore and waiting on the semaphore held by the other. If the GBS version you use still has bugs like mentioned above then this trick may not work very well for you, but it is the approach that I use once the tools are fixed to allow it.

“logging in the second GS session locks up the Seaside interface”

You might want to refactor your code so that a background process handling requests is separate from the process that handles UI events. If the background process needs to do something UI related then have that happen within a #uiEventFor: block. It may be that Polycephaly is already giving you the UI separation but that your code needs #uiEventFor: for when a background process does something that involves a UI change.

“It's probably a unique mix of Polycephaly and GS; it would be cool to hear of another setup.”

This is probably overkill for your needs, but…

If you have a multiple-producers-but-one-consumer situation then you might think along the lines of a request-queue approach where a queue in VW is serviced in a background process that waits on a semaphore signal. You might think of it like an RcQueue for VW. An add to the queue would #signal the semaphore. The processing of each request involves a semaphore #wait. The queue acts to isolate and sequence the processing of requests in a uniform manner through GS. There are many ways you might want to notify when a request has been processed. You may need to protect code from changes in the queue collection (usually done with a second semaphore or a queue design like the EsQueue that you’d remember from VAST).

Paul Baumann

Hi Bob,

It is interesting that you are having trouble replicating arrays that are method literals and yet not strings that are often method literals too. That may suggest a problem related to managing persistent objects that are in the export set for more than one session. It seems you can avoid the problem by passing transient objects that another session would not also have. You might want GemTalk/vmware/GemStone/Brokat/GemStone/Servio to track that down.

It is eerily close to the block replication problem that has randomly affected us for a couple years now. In that case, GS and VW get out of agreement about the export status of the oop that had earlier represented the VW decompiled source for a block flushed to GS. GS thinks the oop is unused and assigns it to a different object that gets replicated to VW and VW uses the object (for the oop) that is still found in the GBS cache. The errors are easy to identify because the stack dumps show VW decompiled source for a block that ends up in an object graph. Finding the problem is a challenge because the bug happens sometime earlier. After years of trying to help track that down it was better to just avoid any replication and flushing of blocks. That workaround helps, but it is a challenge to find the patterns in existing code and also prevent re-introduction.

I’m glad Poly2 helped.

Regards,

Paul Baumann