[Glass] Monit scripts for gemstone?

[Mariano Martinez Peck via Glass]

On Thu, Feb 19, 2015 at 5:05 PM, Johan Brichau <johan at yesplan.be> wrote:

>
> On 19 Feb 2015, at 00:01, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
>
> Let me re-ask what is the more important question I have.... for that
> monit timeout  "timeout 40 seconds" I must setup a number like that, or
> exactly the timeout I define at my web server. For example, I have loooong
> request (yes, I know, I should be using service VM...but until then..), so
> my timeout for the upstreams at nginx level is 5 minutes. So which timeout
> do I need to set here? 5 minutes too?  Or still 40 seconds?
>
>
> Yes, you should use a service vm :)
> Anyway, our nginx timeout is set to 60s and I set the monit timeout always
> lower than that.
> We stick to the 60s timeout as the hard deadline for any request in
> Yesplan. Monit might sometimes cut one shorted but this raises an alarm for
> us to take a look what’s happening and see if we can fix the performance.
>
>
OK..good points.


> I ask because I don't want the scenario where I am processing a long
> request (imagine one of 4 minutes) and then monit after 40 seconds thinks
> the server is down and hence triggers a restar.  So I wonder...is the
> FastCGI server able to answer the Monit send even if it is processing a
> request? or the return to Monit will only be once it finishes processing
> current request?  That might tell me which timeout should I set here.
>
>
> If you want to allow longer requests, then make sure to set the timeout
> longer.
> GLASS is made to process only a single seaside request at a time and thus
> a request will get blocked until the previous one was processed. That
> includes the monit request.
> So, what you say is correct: if a gem is busy processing requests, it will
> not answer to monit.
>
>
mmmmm are we 100% sure about this? I mean...at which level is the "lock"
inside the gem to block requests? I thought it was at kind of at seaside
session level. If monit request is a plain fast cgi request (outside
seaside context) maybe the gem CAN answer because the lock happens further?
Let me CC Dale just in case ;)



> That’s how we work right but I have to admit this is still the same way as
> how we got started a few years ago. I should try to explore if there are
> better ways, so don’t take my advice for granted :)
>
>
hehehe okok. Thanks in either case!



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150219/a5b38fc9/attachment.html>