Repeated request ends in infinte loop on device


(Benjamin Keffer) #1


I’m really surprised about the Remoting SDK and it’s possibilities. Thank you for this great solution!

I created a simple client-server application to control some GPIOs from remote and I’m happy to see it working.
The only bigger problem I have occurs on my iPhone 7 iOS 10.2 device when after some requests the client doesn’t get any response. I can see the network indicator at the status bar circle without end.
To get a response again I have to send 3-4 new requests until the server will start to answer again.
This scenario doesn’t occur when using the simulator. There are now network problems.

My server is built up with Delphi 7 Indy 9. I checked if there are any incoming data when the problem occurs, but there will be no request recognizable.

It would be great if you could help me.

Best regards
Benjamin Keffer

(EvgenyK) #2

if you used Indy10 with D7, would it improve situation?

Note: after changing Indy version, you need to update
For the latest Indy snapshot (Indy 10.5.9+), you need to uncomment

  {.$DEFINE RemObjects_INDY10D}

(Benjamin Keffer) #3

I can’t install Indy10 in the next few weeks. So it would be great If I could get the Indy9 server running.
But isn’t it strange that the app works without any problem on simulator? (Edit: it just takes longer, but the same problem occurs as well)
On device just the first two requests will be successful. Almost every following requests will hang up although the timeout was set to 5 seconds.

When a request fails and I manually cancel it and I then restart the server, nothing will change. All new requests will still fail until I restart the app. So I guess it’s more a client problem.

(EvgenyK) #4

What language and SDK is used for client-side (Remoting SDK for Cocoa, Remoting SDK for .NET, etc)?

(Benjamin Keffer) #5

Remoting SDK for Cocoa Oxygene

(marc hoffman) #6


is this with the very latest version 9.1 of Remoting SDK?


(Benjamin Keffer) #7

Hi marc,

yes since today I’m using the newest version. Nothing changed. This happens with the iOSBackgroundCompletion demo as well.

(marc hoffman) #8

Curious. we did some fixes that should prevent occasional lock-ups of NSURLSession for 9.1, but we’re not aware of any outstanding problems isn that area :(. We’ll need to investigate. Any particular steps needed to make this reproduce with the iOSBackgroundCompletion sample? What version of Xcode, SDK and the Simulator are you using?


(Benjamin Keffer) #9

I have played the whole day around with the iOSBackgroundCompletionServer. Here’s the summary:
First I built up a new network to exclude suchlike problems. Then I installed (on a new PC) Delphi XE5 and the newest Indy Thereby I compiled the iOSBackgroundCompletionServer with the newest ROSDK version Next I compiled the provided client side with xcode (8.2.1(8C1002), ROSDK version for my iPhone 7 (iOS 10.2(14C92)). Running the app and requesting 2-3 times in succession (immediately after the server responded) a 1 second sleep will show up exactly the same problem.

I have no idea what goes wrong… I’ve my back to the wall.

(marc hoffman) #10

Can you test one more thing for me? when the client gets to the point where all RO requests hang — can you, on a separate thread (i assume Main() is still responsive), laugh a plain NSURLSession request (see here request to any random domain (say, and check if that too hangs?

I’ve seen scenarios where all of NSURLSession just gets completely stuck (RO or no RO), and knowing if tisanes the case here will narrow this down.


(Benjamin Keffer) #11

Hm, unfortunately the NSURLSession requests will work…
What I found out: if you reference the outgoing RORequests and kill them when they hang, the following requests will have a chance to be answered.

EDIT: ok, if you fire enough you don’t need to cancel them
What I saw is that the xcode network monitor won’t show any traffic when all RO request hang and I send new requests. The manual NSURLSession request is visible.

(marc hoffman) #12

Ok, this seems to be a different tissue then. i’ll need to log see if we can reproduce this on our end to investigate further…

(RemObjects) #13

Thanks, logged as bugs://77121

(Benjamin Keffer) #14

It would be great if you keep me up to date, because I have to publish my project in the next two weeks… :-/

(marc hoffman) #15


i’ve started looking into this issue, and i’m i cannot reproduce the problem with the iOSBackgroundCompletionService app. i can start as many requests as i try, and the all succeed, and sorting hangs. What could i be missing?

(Benjamin Keffer) #16

Hmm… I have no idea. I took the xcode sample, the Delphi 7 sample and built them without any changes. Then I executed both and tried it as described.

I think it’s better If we talk about the same source code. I attached the Delphi server version and a Oxygene client version (I don’t like Xcode). Press the appearing UIButton up to 10 times and the problem occurs (on device).

(marc hoffman) #17

Reproduced, and — i think — fixed. I’ll PM you an updated ROClientChannel.m file — can you rebuild RO with that and see if that solves the problem for you, as well? (it’s a tentative fix and will need more cleanup before i fully commit).

(Benjamin Keffer) #19

Thanks! It got more than 100% better. But the problem still occurs.
One app do like 10 requests at the same time. At least one request will hang.
If the app fires only one request at the same time, it needs some more time until the app doesn’t accept new requests.

(marc hoffman) #20

Ok :(. is this with 10 (long) requests fired of in the iOS Backgrounding sample? or with a different app that runs 10 requests tab the same time? in the latter case, can you give me a testcase? do you use one client channel for all requests, or 10?

(Benjamin Keffer) #21

I modified the refresh method from the last sample I uploaded. Check it out.
Press the sleep button as soon as the acitivty indicator stops. After 3-4 tries you will see the problem. I don’t show an alert view anymore, so you can repeat the requests faster. This delay seems to be a deciding factor too.