TIdHttpServer Stops Responding, but Only to Non Indy Clients
Rob Snyder
I have an application whose role in life is to respond to queries and return
XML documents via HTTP. This app is currently experiencing a severe
production problem, and I'd appreciate any guidance anyone could give me on
how to deal with the stability problems I'm seeing.
The issue is essentially this - I have three types of clients that make
requests of my application. The first is a multi-threaded Delphi app that
uses the Indy HTTP client component. The second is a multi-threaded Java
application using the standard library network classes, and the third are
manual requests sent through a browser.
All three applications use the same semantics - a query is passed on the
URL, and an XML document is returned.
No matter how hard and fast I hit my application from the Delphi client, it
can take the load and remain stable. For example, I ran a test with 16
clients, each set to execute 5,000 requests as fast as possible. No
problems, my app held up fine.
However, the other clients will cause my app to crash fairly regularly. If I
stay "single user" (e.g. only one browser issuing requests, or one process
in the Java client), then my app will also survive forever. As soon as I add
2-3 simultaneous requests, such as having two or three web browsers doing
refreshes, in a matter of a few moments my app will completely stop
responding. Not close out, and I can still terminate my app normally, but it
acts as if it just doesn't "hear" any more incoming requests.
So... it seems either that there is / are bug(s) in my application that just
don't matter going Indy -> Indy, or there is something about the Indy
components that is not quite standard with the rest of the world. Either
way, I've tried everything I can think of to get to the root of the problem,
and I am really no closer.
I am running the 9.0.10 Release, although this problem also exists on all
the 8.x releases I tried. Delphi 5.
Thanks!
Rob Snyder
Rob Snyder
As a follow up, I dropped in a different component (www.dart.com) and the
problem went away. I changed only the code involved directly with calls to
this component... So... I'm pretty sure I see a bug here in the Indy stuff
that I would love to see resolved. What next?
Rob
"Rob Snyder" <r...@feisc.com> wrote in message news:3d2d8d53_2@dnews...
Stephane Grobety
> the problem went away. I changed only the code involved directly with
> calls to this component... So... I'm pretty sure I see a bug here in
> the Indy stuff that I would love to see resolved. What next?
Rob,
When Indy 8 came out, I stress-tested it using the MS web site stress
application. It performed correctly under a simulated load of 100 clients
using 5 threads each, all downloading a three pages web site involving 5 or
six JPEG images and a 200k ZIP file. I've run the test several times using
both "stateless" mode and the built-in session manager.
I haven't reproduced these tests with Indy 9 but I suppose I'll do so
sometime in the next two week. Meanwhile, could you please tell me more about
your application: it is very possible that there is something special about
it that will trigger the problem. I'd guess it would probably be in the
handeling of the HTTP request from the client in which case a trace of these
requests would be very helpful.
Good luck,
Stephane