"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:44a3005c$1@newsgroups.borland.com...
> Sounds like you are not managing the connections properly. What does your
> actual code look like? Are you adequately protecting your pool from
> providing the same outbound connection to multiple server threads? Are
> you
> associating the outbound connection with each thread, such as via the
> TIdPeerThread.Data (Indy 9) or TIdContext.Data (Indy 10) property, so that
> each inbound connection knows exactly which outbound connection to access?
Hi Gambit:
Yes the pool is thread safe. It won't assign the same connection to a
server thread unless the connection has been released. Upon assignment I
"lock" the connection and the pool checks if the connection is locked before
it assign it again. If it is locked it goes to the next connection in the
pool, if it is nil (connection gets destroyed when inactive for 5 min) it
creates a new one otherwise it assigns it if not locked. Upon completion of
a socket write - socket read sequence the connection is released back to the
pool.
I have done some more testing by eliminating the pool and assign dedicated
connections for each server thread. I had a timeout of 5000ms on it and
found that the read times out but the other server still writes to the
socket so all results after that is one read behind. That's the reason why
the client responses appears to be mixed up, when using the pool, because
they share the connections. One way to solve this is probably to connect ,
request and disconnect which are normally costly operations. That is what
the whole idea behind the pool was.
Regards
Gerhard
