Re: Red Hat thread sync question

From: Sundial Services (info_at_sundialservices.com)
Date: 11/24/04

  • Next message: Felix Miata: "Re: Samba HOWTO" 
    Date: Tue, 23 Nov 2004 19:04:03 -0500

    Ramki wrote:
    > Hi,
    > I am using a multithreaded application, which hangs on RedHat 8.0
    > Linux.
    > The application is basically a server application which creates a
    > thread for processing each request. Each thread opens a socket, pumps
    > some data and would die.
    >
    > If I send lesser number of requests, the application works correctly.
    > But, when a large number of requests are sent simultaneously, the
    > threads would hang.
    >
    > This looks like a thread synchronization issue. But it is not
    > happening in RH 7.3

    Basically, Ramki, "you were simply lucky" that the application didn't hang
    on you in 7.3, and I suspect that if you had dumped excessive load on it
    frequently enough, it would have.

    The approach of creating a new thread for each request .. what I call the
    "flaming arrow approach" .. is inherently flawed because it has no means to
    control an overload. Sooner or later you'll find yourself with several
    hundred threads, all slogging it out with one another, none of them getting
    anywhere. Poor Linux (or Windows, or OS/X, or IBM MVS) doesn't stand a
    chance against such a design.

    A far, far better approach is to create a limited and controllable number of
    threads, which do _not_ die after finishing a request. What happens
    instead is that each incoming request is placed into a queue. The worker
    threads sleep until they can remove a request from the queue, process it,
    then go to sleep again.

    A server designed like this will always provide a consistent and reliable
    throughput of requests, and will never overload itself. Requests may pile
    up in the queue momentarily, but you can always predict that "X" requests
    per second will be processed, period. (If you wish, you can program the
    "gatekeeper" to refuse incoming requests if the queue is found to contain
    too-many unprocessed entries, e.g. as a defense against an intentional
    DOS-flood.)

  • Next message: Felix Miata: "Re: Samba HOWTO"

    Relevant Pages

    • Re: freebsd 7.0-RELEASE BUG ping: sendto: No buffer space available
      ... I'm facing a temporary network hang on my interfaces following a flood ... 0/1024 mbuf+clusters out of packet secondary zone in use (current/cache) ... requests for sfbufs delayed ... The fact that the interface is coming back to life without any driver ...
      (freebsd-net)
    • Synchronous / Asynchronous Multithreading Question
      ... This works find now when requests aren't that many. ... the server has major issues. ... Basically the request call needs to queue the request, ... I would like for the remoted object to simple call a method on the "manager" ...
      (microsoft.public.dotnet.framework)
    • IIS ISAPI Filter problem
      ... The ideia is to use an ISAPI Filter in IIS to redirect certain requests ... to another server and then send the response back. ... doesn't really hang or crash, it is just unable to respond properly. ... I put a counter in my ISAPI just to know how many requests it would ...
      (microsoft.public.inetserver.iis)
    • Re: Red Hat thread sync question
      ... > If I send lesser number of requests, ... Basically, Ramki, "you were simply lucky" that the application didn't hang ... instead is that each incoming request is placed into a queue. ... A server designed like this will always provide a consistent and reliable ...
      (comp.os.linux.setup)
    • Re: Red Hat thread sync question
      ... > If I send lesser number of requests, ... Basically, Ramki, "you were simply lucky" that the application didn't hang ... instead is that each incoming request is placed into a queue. ... A server designed like this will always provide a consistent and reliable ...
      (comp.os.linux.portable)