Catch timeout exception for Ruby LSAPI

Discussion in 'Install/Configuration' started by Iscander, Oct 22, 2008.

  1. Iscander

    Iscander New Member

    Hello
    I need an advice about Ruby LSAPI process configuration. Things that I wona to see.

    If Ruby (working trough lsapi) does not to serve request at required time I need to interrupt the request and stop it processing. After that raise Ruby exception which I can catch in my application and send an e-mail with Subject "Bla-bla-bla timeout while processing request"

    That I can do. I've tune Initial Request Timeout, Retry Timeout, Connection Keepalive Timeout,Instances and Max Idle Time. I have tried various combination of LSAPI_* environments as well as Max Connection settings. Thats all for LiteSpeed API App Definition (Ruby LSAPI). It works but not exactly I wont.
    My application catn the exception about it interupted by SIGUSR1 - thats fine. But...
    Then I look to logs and see that
    then timeout (Initial Request Timeout) happen - WebServer call the application again trough dispatch.lsapi and does it 3 times for each request before raise 503 exception.
    I need to know how do avoid this behavior ? I need to give Ruby only one chance to serve request in required time but continue serve concurrent connections.

    The servers log:
    2008-10-22 18:57:20.964 [INFO] [192.168.1.111:43208-0#Test] [REWRITE] Source URI: '/projects/393/issues.html' => Result URI: '/dispatch.lsapi'
    2008-10-22 18:57:20.964 [INFO] [192.168.1.111:43208-0#Test] [REWRITE] Last Rule, stop!
    2008-10-22 18:57:20.984 [INFO] [Test] add child process pid: 25325
    2008-10-22 18:57:20.984 [INFO] [Test] pid list size: 1
    2008-10-22 18:58:03.016 [INFO] [192.168.1.111:43208-0#Test:lsapi] ExtConn timed out while processing.
    2008-10-22 18:58:03.016 [INFO] [192.168.1.111:43208-0#Test:lsapi] connection to [uds://tmp/lshttpd/Test.sock] on request #0, Connection timed out!
    2008-10-22 18:58:13.056 [INFO] [192.168.1.111:43208-0#Test:lsapi] No request delivery notification has been received from LSAPI process:-2, possible run away process.
    2008-10-22 18:58:13.056 [INFO] [192.168.1.111:43208-0#Test:lsapi] connection to [uds://tmp/lshttpd/Test.sock] on request #0, Connection timed out!
    2008-10-22 18:58:58.056 [INFO] [192.168.1.111:43208-0#Test:lsapi] ExtConn timed out while processing.
    2008-10-22 18:58:58.056 [INFO] [192.168.1.111:43208-0#Test:lsapi] connection to [uds://tmp/lshttpd/Test.sock] on request #0, Connection timed out!
    2008-10-22 18:58:58.056 [NOTICE] [192.168.1.111:43208-0#Test:lsapi] oops! 503 Service Unavailable
    2008-10-22 18:58:58.056 [NOTICE] [192.168.1.111:43208-0#Test:lsapi] Content len: 0, Request line:
    GET /projects/393/issues HTTP/1.1


    Thank You in advance. Googleing didn't help me :(
  2. mistwang

    mistwang LiteSpeed Staff

    That's correct behavior. LSWS will try three times on a failed requests.

    The initial request timeout should be set high enough to allow Rails finish serving a request normally. It is intended for catching a runaway request.

    So, you cannot implement what you want via initial request timeout, instead, just do whatever you would do with other Rails hosting solutions.
  3. Iscander

    Iscander New Member

    I was guesing about that - thank you for confirmation.
    Could you make any recomendations about dedicated hosting settings? links more then enough
  4. mistwang

    mistwang LiteSpeed Staff

    It depends on your web site and traffic volume.
    It should be good start point with

    Max connections 10
    Initial Request Timeout 60 (If some request takes longer, increase it).

    LSAPI Ruby can be fine tuned via environment variables

    http://www.litespeedtech.com/ruby-lsapi-module.html
  5. Iscander

    Iscander New Member

    Thanks. I read this links and have played with environment setings for lsapi.

    What about number of retries on a failed requests. Is it possible to add a configuration parameter or at least server startup key-option. Let me elaborate why.

    Just imagine web2 application based on Ruby. Ruby is very popular now, but it slow, very slow sometimes. An web2 application has ajax with all its powers and blemishes. It interactive but use a number requests across browser and server side. So its unreal to restrict a number request from host for a time interval, isn' it? From anothaer hand on server side we have Ruby on Rails with couple slow requests, no matter is it Ruby or slow DB connection. Those request should return something or nothing but to be in a time. Let say they draw a chart somther on user page or "processing" picture against chart if information is not actual. So those request could draw it quicly asap but sometimes freeze. Time limit is 2 minute. User excepts to see the chart and knows that in worst case it be or not after couple minute. But in our case we restrict time per request with 120 sec. And... User will not wait 6 minute(! server will try to receive response 3 times). User will refresh a page thinking that something wrong with connection, browser etc... So it refresh the page and send new requests which will processing again 3 times. And the previuse request is still processing same time. Another request is going for processing as well. So server need to fork new instances to proces them. It seems like DOS's timer bomb, doesn't it?

    In this case can I ask you for configuration parametr about number of retries on failures requests for a future release.

    Thank you in advance
  6. Iscander

    Iscander New Member

    Even more strong argument. We have an request which for example remove some records from DB. Let say it remove 10 first records and wait a confirmation from RDBS. Once DB server is busy, but it start the request and busy by rebuilding indexes. We got a timeout. It should not happen ussualy, but if server will repeat a request again and again the application remove not 10 but 30 records from DB and user will not know about because 503 exception.
    We need a way to restrict nuber of retry for some kind of requests, isn't it?

Share This Page