Repeated request ends in infinte loop on device

Remoting SDK
, ,
22

Hmm, i cannot reproduce any such problem with this attached modification of the original sample:

i can click send as often as i want, and i get the appropriate 5x responses :frowning:

Background Completion.zip (75.6 KB)

23

I tested the xcode sample just now and yep, it works for me as well. Could you check my Oxygene version?
The problem must be in a deeper way because in both projects (xcode and oxygene) I use the same static library.
RemObjects Test.zip (752.8 KB)

24

Yes, but you use it totally differently. for example, the sample app creates a new service stance for each call. your app (when i looked at it the first time) does not, and it uses async calls. My guess is that what you are seeing now is a totally unrelated bug (might still be in RO, might be in how you use it), because what caused the original problem was fixed by the change i made (and i say that not just based on “it worked after” but based on that the code had a logical problem with how it resumed the background thread, and that problem was fixed).

Can you at all reproduce the problem with a variant of the original Xcode project?

If not, i can debug your Oxygen project, but not until next week, as i’m afraid i’m off on vacation(ish), tis week…

—marc

25

Hi marc,

the usage is completely the same. The oxygene sample creates a new service instance too. And the xcode sample uses async calls as well.
It would be great If you could debug my sample.

thanks

26

One thing i’m noticing btw is that, for me, your app fails with

Error dispatching asynchronous request: The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.

until i add this to the plist. this is a known limitation when not using HTTPS on latest iOS versions. Im surprised it works at all, for you.

		<key>ITSAppUsesNonExemptEncryption</key>
		<false/>
		<key>NSAppTransportSecurity</key>
		<dict>
			<key>NSAllowsArbitraryLoads</key>
			<true/>
		</dict>

That said, moving on beyond that and investigating the actual issue now.

27

This iOS not the official/final fix, but: in ROClientChannel there are two occurrences of cancelThreadAndWaitFor:YES];. Can you replace the YES with a NO there, in both cases?

that should address the problem (at the cost of some potential leftover background threads sticking around, until have fixed this properly)

1 Like
28

Yeah, that’s it! Thank you a lot!

1 Like