RTC Forums
November 30, 2021, 07:28:40 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Problems after upgrading to v9.51  (Read 1130 times)
DPerkins
RTC License
***
Posts: 30


« on: September 02, 2020, 03:31:05 PM »

Hello

I've used v6.24 very successfully for a few years now, but I'm using BCB2007 and preparing to upgrade to 10.4 so I'm upgrading all my components to the latest version. 

After upgrading v9.51 I ran into problems.

v9.51 compiled okay and was installed in BCB2007 with no problems.

Our server uses rtcHttpServer/rtcServerModule/rtcFunctionGroups/rtcFunctions and appears to work fine with older clients.

Our client creates 5 sets of TRtcHttpClients/TRtcClientModules/TRtcResults.  I use the first one as an event mechanism using delayed calls every 30 seconds.  The other four clients in my 'client pool' are used to request data using either Execute or Call depending on what part of the software is asking for data.

After upgrading to v9.51, it appears that calling TRtcClientModule.Execute will never return if there is an existing Call() in progress (on a different TRtcClientModule).  I have Hyperthreading = false

I've been through all the previous release notes but cannot spot anything of note related to this.

What have I missed in this big upgrade leap?

Thanks

David
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1861


« Reply #1 on: September 02, 2020, 04:39:21 PM »

My guess is that your Client is calling the Execute method from inside an event triggered by a RTC component, which results in an endless loop, because the Execute method is waiting for the component to complete executing events, which is impossible, for the simple reason that the Execute method is running inside one of those events, blocking further event execution.

How do you solve the problem?

Well, one option is to rewrite parts of your code that currently use the Execute method, so they work by using the Call method, simply because mixing Execute and Call methods inside the same Project is going to get you in trouble with the latest RTC SDK version (as you've already seen).

The alternative is to get back to the old RTC SDK version, which has been working for you.

Best Regards,
Danijel Tkalcec
Logged
DPerkins
RTC License
***
Posts: 30


« Reply #2 on: September 04, 2020, 05:34:52 PM »

Thanks.

Each TRtcHttpClient (I declare 5) will only use one type of function: Execute or Call, so it's unlikely the same HttpClient will make a call in method in response to an RTC generated event from the same client.

Should each TRtcHttpClient be independent of other TRtcHttpClient instances or do they share a common back end/resources?  There may be a case where one TRtcHttpClient calls Execute in response to a different TRtcHttpClient instance event.

As v6.24 works, was there a particular version where this changed as I'd like to update to the most recent version where the behaviour matches v6.24.

Many thanks.

Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1861


« Reply #3 on: September 04, 2020, 06:49:44 PM »

In a single-threaded RTC Application, because all code is executed from the Main Thread, it doesn't matter which component calls the Execute method, because all RTC components share the same RTC message queue, where all events will be placed and executed sequentially (one after the other), following a simple first-in/first-out rule. So ... if any event doesn't finish and return control back to the message queue loop, no more events can be taken out of the message queue, which is why a call to the Execute method from inside a RTC event is a bad idea and causes your endless loop.

As far as I know, the Execute method was always meant to be called ONLY from inside the Main Thread and NEVER from inside any events triggered by any RTC component, so the fact that your code worked with RTC SDK v6.24 was more of a coincidence, than a result of my "intelligent design". And since I've made A LOT of changes over the years, I couldn't tell you which version might still work for you, even if I wanted to.

If you look up the "Execute" method in the RTC SDK HELP file, even in RTC SDK v6.24 (which you have been using), you will find this WARNING: Because of its blocking implementation, "Execute" method can NOT be used from events triggered by the RTC SDK (for example, from the OnResult or OnAbort events triggered by a remote call issued by using the "Call" method) and ... the "Execute" method can ONLY be used from one thread at a time.

Maybe you didn't see that warning before, or maybe you thought that the limitation only applied to Execute methods called from within events triggered by the component that issued the Execute call, but ... that is NOT the case, because all RTC components running in a single-threaded RTC Application share the same message queue loop, which can't continue running if an event triggered from the message queue loop gets blocked (for example, by a call to the Execute method from inside the event).

Anyway ... if you really wanted to find the latest RTC version that still works with your code, without the need for you to make changes, then you could try downloading every RTC version released after v6.24 until you find the first one that no longer works, at which point you'd have to roll back one version, since that would be the one you are looking for (the latest version that still works with your existing code).

Best Regards,
Danijel Tkalcec
Logged
DPerkins
RTC License
***
Posts: 30


« Reply #4 on: February 04, 2021, 11:57:51 AM »

I've managed to get this working by decoupling any RTC calls that arise in response to an RTC event.
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1861


« Reply #5 on: February 04, 2021, 12:02:33 PM »

Good to know. Thanks for your feedback.

Best Regards,
Danijel Tkalcec
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 16 queries.