"Larry" <lchiasson@autoeurope.com> wrote in message
news:446dd8ad$1@newsgroups.borland.com...
> However, when profiling for leaks, there are times when Critical
> Sections are not being released, and thus leading to a leak.
There are only 2 critical section "leaks" in Indy, and they are intentional
during application shutdown. Comments in the code explain why. Also, this
topic has been discussed many times before, so you can view them in the
newsgroup archives at http://www.deja.com.
As for the locks not being released at runtime, I highly doubt that.
Critical section locks are always being released properly, via try..finally
blocks.
> Also, there are times when a thread will try to obtain a socket
> connection (.Connect method) only to have it fail.
That is not very helpful. A socket connection can fail for a number of
reasons. You need to be more specific. When Connect() fails, it will throw
an exception, explaining why it failed. What EXACTLY are you seeing happen?
> From what I've read on Indy, I believe we are not doing things
> correctly in terms of Indy component use.
There is no way to answer that since you have not explained what you are
actually doing with them in the first place.
> A thread will create and release any resources it needs in the context
> of the thread, not the main thread (ie. .Create and .Destroy). For
example,
> a thread will create a db connection in the .Execute method of the thread.
> This includes socket creation and destruction
It is perfectly fine to create a socket in the main thread and then use it
in a worker thread. Blocking sockets work very well in that regard, as they
are not bound to any particular thread. Multi-threaded Indy servers create
inbound sockets in a listening thread and then pass it to a worker thread
for processing. Multi-threaded Indy clients that process incoming data
asynchronously pass their socket handle to an internal reading thread for
processing.
> a back plan is to go client/server with Indy, where each thread created
> by an instance of our ISAPI dll would be a client accessing an Indy Server
> (IS), where IS will then access the www for the web services provided by
> our vendor (making our IS a client of web services).
You don't need any Indy servers for that. Your ISAPI threads can access the
vendor web services directly.
Gambit
