Status: Accepted
Owner:
[hidden email]
Labels: Type-Defect Priority-Medium GLASS-Server Version-GLASS0.231
New issue 341 by
[hidden email]: Hanging FastCGI gems
http://code.google.com/p/glassdb/issues/detail?id=341There have been several reports of haning FastCGI gems[1]. In a recent mai,
Johan has voiced his suspicions and they sound like they have merit:
I have not yet gotten to the bottom of this problem yet because it's
something that pops up relatively rare. However, I found that the
unresponsiveness is probably due to the gatesemaphore being 'depleted'
(i.e. 10 processes have decreased the semaphore but never increased it
again). This is because I have been tracing the state of the semaphore over
time, where I notice that the gatesemaphore's value can be less than 10
(which is its initial value) on an idle server. The gem would be blocked
once the gatesemaphore hits 0.
I have a suspicion that it has something to do with concurrency conflicts
because I notice a correlation with the number of concurrency conflict
messages in the log and the decreasing value of the gatesemaphore. But it's
not really consistent and I have not seen any paths in the code that might
lead to this.
-------------
Presumably if FSConnection>>closeConnection doesn't get called ... There's
an ensure block in GSConnection>>safeServer, but there are (obscure)
circumstances (bug) under which an ensure block may not be evaluated, so it
is sounding like this is likely the case ...
[1]
http://forum.world.st/Web-request-problem-on-server-with-two-Glass-environment-tt4519143.html
Locked
