Frans,
It's an page request that generates a 301 status. HttpAsy is not a
threaded application, seems there the same url will then not
generate a problem. HttpThr1 doesn't do a async call so again no
problem.
There should be no difference between running the component in the
context of a
Arno Garrels wrote:
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the HTTP component is busy
error message when using the async get.
It still doesn't work probably so don't send it to your customer
yet. I'm working
@elists.org
Sent: Monday, March 28, 2011 5:01 PM
Subject: Re: [twsocket] HttpCli / Async in thread problems --- Tryng to trace
Arno Garrels wrote:
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the HTTP component
Hi,
thanks for the report.
Sorry to inform you that the problem is still there. Even when not behind
a
proxy the GetAsync will fired the requestdone even when not ready causing
the next call to generate an exception HTTP component is busy
Are you able to reproduce the issue with
Frans van Daalen wrote:
Hi,
thanks for the report.
Sorry to inform you that the problem is still there. Even when not
behind a
proxy the GetAsync will fired the requestdone even when not ready
causing the next call to generate an exception HTTP component is
busy
Are you able to
Arno Garrels wrote:
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the HTTP component is busy
error message when using the async get.
It still doesn't work probably so don't send it to your customer
yet. I'm
Frans van Daalen wrote:
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the HTTP component is busy
error message when using the async get.
It still doesn't work probably so don't send it to your customer yet.
I'm working on this stuff
Frans van Daalen wrote:
What proxy server does your client use?
One was using webmarshal and the other ISA. But i'm not behind a
proxy and also still keep getting the HTTP component is busy error
message when using the async get.
It still doesn't work probably so don't send it to your
Arno Garrels wrote:
Frans van Daalen wrote:
Update : Seems there are still scenario's where the problem returns
also sometimes the proxy settings are lost creating a 407 when a
relocation happens. Seems to happen when executing a GetAsync and a
relocate is triggered (with follow relocation
Arno Garrels wrote:
Arno Garrels wrote:
Frans van Daalen wrote:
Update : Seems there are still scenario's where the problem
returns also sometimes the proxy settings are lost creating a 407
when a relocation happens. Seems to happen when executing a
GetAsync and a relocate is triggered (with
That's not all, I found and fixed some more problems so far.
I just checked in Rev. #670 into SVN, please test the fix
and report back as soon as possible, thanks for your help.
Log:
Proxy authentication with relocations (hopefully) fixed. SSL not tested
yet.
If it still doesn't work it's
Frans van Daalen wrote:
That's not all, I found and fixed some more problems so far.
I just checked in Rev. #670 into SVN, please test the fix
and report back as soon as possible, thanks for your help.
Log:
Proxy authentication with relocations (hopefully) fixed. SSL not
tested yet.
If it
What proxy server does your client use?
One was using webmarshal and the other ISA. But i'm not behind a proxy and
also still keep getting the HTTP component is busy error message when
using the async get.
--
To unsubscribe or change your settings for TWSocket mailing list
please goto
Update : Seems there are still scenario's where the problem returns
also sometimes the proxy settings are lost creating a 407 when a
relocation happens. Seems to happen when executing a GetAsync and a
relocate is triggered (with follow relocation set)
Thanks for the report. That's probably
Frans van Daalen wrote:
Update : Seems there are still scenario's where the problem returns
also sometimes the proxy settings are lost creating a 407 when a
relocation happens. Seems to happen when executing a GetAsync and a
relocate is triggered (with follow relocation set)
Thanks for the
Tracing and debugging is a problem when there's not much on the call
stack as with the THttpCli where many events are triggered by posting
messages instead of calling event handlers directly.
Just a side note: Posting a message and calling event handlers directly have
totally different
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
When I add a check for FLocationFlag there it _SEEMS_ to fix it,
has to be still tested very hard in order
Frans van Daalen wrote:
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
When I add a check for FLocationFlag there it _SEEMS_ to fix it,
has to be
Frans van Daalen wrote:
seems that the bug is also somewhere related to the NTLM code or call
because the icslogger shows the following
- Starting relocation process
- state = httpReady
- PrepareNTLM
- PrepareNTLM
- RequestDone psss why is that
there??
Frans van Daalen wrote:
Frans van Daalen wrote:
seems that the bug is also somewhere related to the NTLM code or
call because the icslogger shows the following
- Starting relocation process
- state = httpReady
- PrepareNTLM
- PrepareNTLM
- RequestDone
You are right, I did not test the GetAsync, in async mode
RequestDone is actually fired with StatusCode 0 after relocation.
Triggered by a call to CheckDelaySetReady in GetBodyLineNext.
When I add a check for FLocationFlag there it _SEEMS_ to fix it,
has to be still tested very hard in order
Forgot to say that the logged status after the call is almost always
HttpDnsLookup
and that the exact line in HttpRequestDone is
If (Sender as ThttpCli).State in [httpReady,httpAborting,httpClosing]
then
Begin
PostMessage((Sender as THttpCli).CtrlSocket.Handle, WM_QUIT, 0, 0);
Forgot to say that the logged status after the call is almost always
HttpDnsLookup
and that the exact line in HttpRequestDone is
If (Sender as ThttpCli).State in [httpReady,httpAborting,httpClosing]
then
Begin
PostMessage((Sender as THttpCli).CtrlSocket.Handle, WM_QUIT, 0, 0);
23 matches
Mail list logo
