[Glass] Swazoo server hangs
Johan Brichau
johan at yesplan.be
Tue Nov 5 10:45:48 PST 2013
Otto,
I just scanned through the mail thread (seem to have missed it before).
First off: given the number of problems you have using Swazoo and that Zinc server has not been battle tested in Gemstone (and there are open issues nobody really looked at), I definitely recommend to switch (back) to FastCGI. It is stable and fast. But, of course, it would be great if you can flesh out the remaining issues with Zinc server on Gemstone ;-)
Second, are you seeing the lock ups occurring frequently? Are they irregular or is there a pattern?
I am asking this because we do have a similar problem that occurs (rather infrequently) with FastCGI adaptors for Seaside [1]:
A seaside gem will become unresponsive after some time. I already managed to find out that the gateSemaphore of a quit system could still be less than 10 (i.e. some processes got locked and never signaled the semaphore) and that it might have something to do with the front-end server dropping connections. I'm not sure if these problems are related though.
Johan
[1] https://code.google.com/p/glassdb/issues/detail?id=341
On 01 Nov 2013, at 15:44, Otto Behrens <otto at finworks.biz> wrote:
>> Can you use the FastCGI server which I think was officially supported for 2.4? As far as I know Zinc works on 2.4 and people use it in production, but others would be better able to address its suitability. As a test you could add a Zinc and/or FastCGI server or two to your pool of 4 Swazoo servers and see if things change for the better.
>
> We initially used FastCGI but then switched to Hyper and then Swazoo,
> simply because it was easier for us to debug as we can use something
> like curl to do a get and see what the server pops up. I suppose that
> if fast cgi has some nice tools to talk to the GS FastCGI server it
> would be as good. But don't you like the simplicity of talking HTTP
> all the way through? Why must FastCGI be better?
More information about the Glass
mailing list