Repeated request ends in infinte loop on device

oxygene
ios
delphi

(marc hoffman) #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)


(Benjamin Keffer) #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)


(marc hoffman) #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


(Benjamin Keffer) #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


(marc hoffman) #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.


(marc hoffman) #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)


(Benjamin Keffer) #28

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