RTC Forums
April 30, 2024, 10:06:48 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Messenger example and delayed calls  (Read 4037 times)
xstarter
RTC Expired
*
Posts: 8


« on: September 14, 2011, 04:13:44 PM »

Hello,

I am using some blocks of Messenger demo code in my project and sometimes receive strange results.
In the unit rtcMessengerProvider in procedure TMessenger_Provider.MsgGetDataExecute with heavy loaded data transmittion not all records go to client side. I was add log writing in most important parts of this procedure, so I know:
1. Param.asBoolean['delayed']=True, so cb is not preparing
2. data exists, so procedure going inside block
if assigned(arr) then
3. Result.NewRecord calling well
4. Record is not receiving in the Client. There are logs too.

Is it possible what record don't sending well because cb=nil and CancelDelayedCall executing with it? Inside CancelDelayedCall I can not see check is cb nil or not. By the way, there are no exceptions what can catch EurekaLog and all procedure commands after CancelDelayedCall executing well.

How it's possible to check was record sent well or not here? If I can check it I can mark data as sended or as not sended.

Thank you.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: September 14, 2011, 07:25:23 PM »

Are you sure the problem is that the Server sends out a correct Result and the OnReturn event is triggered on the Client side, but that the Client doesn't get the same Result inside its OnReturn event? How does the Result object look like on the Server and how does it look like when received on the Client side?

When using RTC remote functions, the Client will get the "RequestAborted" event if there was a problem receiving a response from the Server, or if the response from Server was incomplete. But the Server can NOT know if his response was received by the Client, unless the Client sends a new request to the Server to let him know about it. If you are using a messaging queue on the Server, you need to make sure that a message will NOT be removed from the Queue before the Client notifies the Server that it has picked the message up.

Best Regards,
Danijel Tkalcec
Logged
xstarter
RTC Expired
*
Posts: 8


« Reply #2 on: September 15, 2011, 10:28:03 AM »

Some messages was not received by Client at all.

As I can see now I was found a problem in my code. I was sent back messages with list of received packets to mark in server Queue was it received by client or not. This list I have send from resTimerReturn. Sometime ago I was read help for RTC and modify code in such way
Call(resNotify);
-->
Call(resNotify, True, Sender);
Today I was drop second and third paramters and it seems work now.

Thank you!
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: September 15, 2011, 01:54:24 PM »

If you use the Call method with the 2nd parameter TRUE (FromInsideEvent), but the Call was NOT made from inside the OnResult event, the request will be placed on the request queue but won't be sent to the Server until another request is sent.

To simplify things, I've now release an update for the RTC SDK (v4.36) which allows using the Call() method from within the OnResult event, without explicitly setting the "FromInsideEvent" parameter to TRUE (default=False), even if the Client is running in single-threaded mode.

This was not possible in older RTC SDK versions. It would have resulted in an exception because the 2nd request header was being sent immediately, before the last response was completed. And now, the request will correctly be placed into the request que, but it will NOT be processed before the last response is handled.

To make a long story short, the change you have made in your code now is OK, but I also recommend you to update your RTC SDK version to the latest release (v4.36) to avoid possible exceptions on the Client.

Best Regards,
Danijel Tkalcec
Logged
xstarter
RTC Expired
*
Posts: 8


« Reply #4 on: September 16, 2011, 05:33:36 AM »

Ok, thanks a lot!
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.024 seconds with 17 queries.