Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread RemoteProcedure: client app freezes while waiting for server answer
Thu, Apr 8 2010 6:39 AMPermanent Link

Luis Conception Gonzalez

Hi!

I use the following code to send a message to the server from a client:

CLIENT SIDE:

   with DBISAMSession1 do
   begin
       RemoteParams.CreateParam(ftString,'Texto').AsString:=inputstr;

      CallRemoteProcedure('Message');
      if RemoteParams.ParamByName('Result').AsString<>'' then
         ShowMessage(RemoteParams.ParamByName('Result').AsString);
   end;

SERVER SIDE:

[OnServerProcedure Event]

  if (AnsiCompareText(ProcedureName,'Message')=0) then
  begin
      with ServerSession do
      begin
         if RemoteParams.ParamByName('Texto').AsString<>'' then
         begin
             form1:=tform1.create(nil);
             try
               form1.memo1.text:=RemoteParams.ParamByName('Texto').AsString;
               form1.showmodal;
               RemoteParams.Clear;
               if form1.edit1.text<>'' then
                   RemoteParams.CreateParam(ftString,'Result').AsString:=form1.edit1.text;
             finally
               form1.release;
             end;
         end;
      end;
  end

It works fine, but the problem is that client PC has to wait until server answers, and client application is 'freezed'.
So, if there is nobody at Server PC, Client application is not usable at all.

Is it possible to solve this?

Thanks!

--
Santy C
Thu, Apr 8 2010 1:43 PMPermanent Link

Raul

Team Elevate Team Elevate


Yes - you're intentionally blocking on the server so it would freeze. There are couple of issues that i think you have

1. Since server side procedure runs in the context of the remote sessions thread it also means that you have blocked the server so even  if client would not be freezing it's BDISAM connection would be dead anyways (maybe somebody else can confirm this)

2. You could in theory use the SendProcedureProgress in server procedure and then handle OnRemoteProcedureProgress event on client so it's not blocking.

3. Finally it seems you're assuming server runs as interactive application. It can run as service in which case this might not even work if there was a user logged in and looking at screen (if service could not interact with desktop).

Overall though i personally think this is not good design in the first place - to block on server with modal form.

You would be better off doing a non-blocking solution. Unfortunately async is a lot more complex. i think main question is what exactly are you trying to achieve ?

If you're just trying to open a form on server to get user input then a small external app and server side table that app populates and client checks might be a quick 'n dirty solution (server side proc would just create a row in table and launch app for example).

Raul
Thu, Apr 8 2010 2:46 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Luis,

<< It works fine, but the problem is that client PC has to wait until server
answers, and client application is 'freezed'.   So, if there is nobody at
Server PC, Client application is not usable at all. >>

The client will timeout after the TDBISAMSession.RemoteTimeout time period,
provided that the client application was connected already.

--
Tim Young
Elevate Software
www.elevatesoft.com
Image