Regarding my last mail ('SMTP component not ready' exception),
I learnt that the problem doesn't occur if I put the whole
'case RqType of: .. end;' into a try..except and simply ignore the
exception.
But I'm not sure if this is the correct way to handle it.
I haven't read the whole message
Hello Arno,
I would play with sligtly increased SocketSndBufSize and a BufSize set
to something below like 16/8 and 32/16 kb. TWSocket's property
BufSize actually is the block size and the amount of data copied into
the winsock buffer in a single (winsock) send call.
Unfortunately the
I have a multi-threaded application that uses a dynamically created
THttpCli synchronously. I know that ICS is normally used
asynchronously, but I could not determine a good way to handle that
with all the dynamically created threads I have to use for database
access anyway.
When I want to
I have a multi-threaded application that uses a dynamically created
THttpCli synchronously. I know that ICS is normally used
asynchronously, but I could not determine a good way to handle that
with all the dynamically created threads I have to use for database
access anyway.
When I want to
I think my problems may have been with the receive stream being freed
before the THttpCli was aborted. Kind of like removing the road before
telling your car to stop.
I am continuing to test, but was curious what other people do when
THttpCli absolutely must be stopped before doing anything else.
When I want to terminate the thread normally or when I force it to
terminate I call the THttpCli.Abort method. How can I insure that the
THttpCli component is indeed aborted before freeing it and ending the
thread?
Right now I do:
HTTP.Abort;
while HTTP.StatehttpReady do
Sleep(10);
Is
