Using "Prepare" on DataModules hangs on shutdown

[kaju74]

Hi...

I've figured out a problem using the new "Prepare"-function on a datamodule. To reproduce this behaviour, just create a simple new VCL-app, place a TRtcHttpClient and a TRtcClientModule on Form1 and use the following code for the OnCreate-Event:

Code:

procedure TfrmMain.FormCreate(Sender: TObject);
var
  AResult: TRtcValue;
begin
  with rtcClientModule do
  begin
    Prepare('sampleFunc');
    with Param.NewArray('PARAMS') do
    begin
      asString[0] := 'data1';
      asString[1] := 'data2';
      asString[2] := 'data3';
    end;
    AResult := Execute(False);
    try
      ShowMessage('Done!');
    finally
      AResult.Free;
    end;
  end;
end;

Start the app, and as soon as the "Done"-MessageBox appears, close the app (e.g. ALT+F4). The app will close immediantly.

Now put the some code on a TDataModule and restart the app (remove the MainForm first). As soon as the infomessage appears,
try to close the app now....and it will about 10 seconds, bevore the app is closed.

If you replace the Prepare-method with the older one (Data.NewFunction('...').NewArray....) and use the "Call(...)"-method, everything
is fine.

It seems to be a problem placing the components on a TDataModule instead of a normal Form (BDS2009).

Any idea?

Thank you,
Marc

[D.Tkalcec (RTC)]

My guess is that your problem is related to the use of the Execute() method with the async WinSock API but without a working message queue. While the Call() method only posts a message and continues code execution, the Execute() method posts the request and waits in a loop for a result, blocking further code execution until a result is received (or until a timeout happens). If you are using Execute() with its default parameter for "AllowMessageProcessing" (TRUE), the method expects a working message queue. While this message queue is created by Delphi when you have a windowed application (Form), my guess is that this queue is missing when there are no forms created in your application.

If you are writing a Windows Service or a Console application and your application isn't supposed to have a message queue, try setting "useProxy" or "useWinHTTP" properties to TRUE on the rtcHttpClient component to use the blocking WinInet or WinHTTP API instead of the async non-blocking WinSock API.

If you do not want the application to block when using Call() methods, you can set also MultiThreaded to TRUE on the rtcHttpClient component. When MultiThreaded is TRUE, if you do not have a message queue (no forms) and do not want to allow user interaction while waiting for a result, you can use Execute(False,5000,False) instead of Execute(False) to NOT have a message loop inside Execute and use a timeout (in this example 5000 miliseconds) to make sure the function returns if there nothing happens for too long.

If that doesn't help, then I will need to know how you have set up your rtcHttpClient and rtcClientModule components properties to analyze the problem, since component properties define a lot of the component behavior. I will also need to know if you are doing your testing from a normal windowed application, from a windows service or a console application.

Best Regards,
Danijel Tkalcec

[kaju74]

Hi.

Thank you for your answer. Due of a short vacation, I couldn't check that out...but i'll do that asap.

Best regards,
Marc

[D.Tkalcec (RTC)]

Btw ... I've just released a new RTC SDK update (3.44) which implements a new connection provider using blocking socket. To use this new blocking sockets connection provider, simply set the new "Blocking" property of the TRtcHttpClient component to TRUE. Because this new blocking sockets connection provider doesn't use a message queue, it will work from console and service applications.

Best Regards,
Danijel Tkalcec

[kaju74]

Hi..

This sounds good....I'll try this...thank you 8-)

Regards,
Marc