RequestTimeout Native vs Indy at runtime

[Babis Michael]

Hello,

Changing RequestTimeout value at runtime with indy takes place instantly where with the native transport it has to timeout first.

eg.

Transport.RequestTimeout := 0; // Let current Requests to timeout now
Sleep(1000); // Wait to apply the transport changes
Client.Disconnect;

Indy timeouts instantly where native transport still waiting the old value (30 seconds) for the active connections.
IOW, i’m trying to disconnect all active connections instantly with native transport.

Any ideas ?

Thank you

• This topic was modified 3 years, 1 month ago by Babis Michael.

[kimbomadsen]

Hi,

I suppose you are talking about Indy Client messaging transport vs native Client messaging transport?

/Kim

[Babis Michael]

Yes, i’m using the messaging transport.
IOW, i want to kill all active connections/requests instantly and not wait to timeout.

Thank you

[Babis Michael]

the native messaging! with the indy messaging i do this with the code on the first post!

Thank you

[kimbomadsen]

When using messaging for request/response, it is in reality not the transport that is blocking since that is by definition non blocking, and in the native transports even more so (since the none blocking appearance is simulated using Indy which internally really _is_ blocking…. confused?? 🙂 )

But what is really blocking it is the TkbmMWCustomClient (and its descendants), who will ask the transport to maintain a list of outstanding requests and await the response of the one matching the client’s current request.

You can hook into the wait behaviour via the client event OnClientWaitingResponse.
You will be getting info in the arguments about how long time is left waiting for the client, roughly 10 times a second.

You will also be able to set the AAbort argument to true, in which case the wait will immediately stop.

So you could add this line to the event:

AAbort:=Application.Terminated;

Then the client will not await any responses from the server if the application is being shut down.

/Kim

[Babis Michael]

Thank you i’ll give it a try 🙂

[kimbomadsen]

I will in the fix release also provide a new global kbmMWShutdown method, which will be used for signalling all long running parts of kbmMW to shut down as soon as possible.

 

/Kim

[Babis Michael]

nice 🙂

[Babis Michael]

Kim,

OnClientWaitingResponse AAbort stopped working in 5.21!
After the server disconnects i get a TRANSPORT_PROCESSOR_EXCEPTION: Access violation at address 0195F414 in module ‘myapp.exe’. Read of address 00000000 and it doesn’t timeout. (Native Transport)

It seems the transport is trying to transfer data on a disconnected session.

Thank you

[Babis Michael]

Maybe it’s related to the error i get in the client when i terminate the server: EkbmMWSocket ‘Cannot execute StopLoop in IO thread’

[Babis Michael]

Seems Transport Disconnection isn’t working reverting back to 5.20 solved the problem!

[Babis Michael]

Kim,

Any news on this ?
I think it’s related to “native transport 5.21 TLS disconnect crash” topic too

• This reply was modified 2 years, 11 months ago by Babis Michael.

[kimbomadsen]

Is it possible to make a small sample provoking the error?

I do not see that problem while shutting down my own applications using latest kbmMW.
So probably there is a difference (one difference is that I do not use SSL in the most acticely worked on applications. I instead use AES256 directly of various reasons).

/Kim

[Babis Michael]

Sending you via email because here the link thinks it is spam.

[kimbomadsen]

Thanks! Received it. I will check it out!

/Kim

[Babis Michael]

Hi Kim,
Any news on the fixes ?

Thank you

[kimbomadsen]

I have had a look at it.
To fix the disconnection issue do the following:

At line 352 in kbmMWTCPMessagingClientTransport.pas, add line:

if not FConnection.IsClosed then

before

FConnection.Close;

Remove line 362 in the same unit. The line reads:

InternalCloseSocket;

/Kim

[Author]

Posts