I was testing my app and I noticed this error message popping up from the PFQueryCollectionViewController:
2015-07-06 21:40:58.445 Noms[320:29335] [Error]: The Internet connection appears to be offline. (Code: 100, Version: 1.7.5)
2015-07-06 21:40:58.446 Noms[320:29335] [Error]: Network connection failed. Making attempt 2 after sleeping for 1.604623 seconds.
This was expected, since my phone was not connected to the internet. However, I want to detect this error and handle it myself, rather having the endless loading scroll on the screen. Looking at the documentation didn't yield any variables that I thought could be useful.
Does anyone know how I might receive this callback so I can handle them?
Parse provides a "cancel" method on all PFQueries, including the one in PFQueryTableViewController. In theory, you could cancel your query after a timeout of your choosing. Unfortunately, many developers are reporting a bug in that method that prevents it from working.
My best recommendation recommendation is to check for internet connection before firing your query. Apple's Reachability project is a great tool for this.
Related
We have a subscription to an RxJS Observable that's obtained from the Sanity javascript client's listen method.
This works fine except that every now and then we get an error "The operation timed out". I haven't been able to pinpoint exactly when and where this arises but I suspect it happens after a certain timeout without the subscription receiving any message. This does not, however, indicate any issue in our case.
I'm not well versed in observables; is there something basic I'm missing, or has anyone had a similar issue?
Listeners are currently automatically closed after 5 minutes. This might be what you're encountering.
It's actually a regression that we discovered recently; listeners are supposed to time out only after 30 minutes. We are expecting a fix for it this week. Edit: The fix has now been released.
It's important for a client to be resilient against any kind of error, though. On the Internet, network timeouts and other glithces are of course very common and must be handled appropriately. eventually the listener will close itself, as this is the intended behaviour.
(I'm a developer at Sanity.)
I have an indy IDHTTP component which is called repeatedly using a timer (4-5 times a second)
I have a poor internet connection so occasionally there are timeout problems or garbage responses that cause an error with the idHTTP component.
I have a try except finally clause around the component but when an error occurs the code shows an error and execution stops.
I know what causes the errors, its my poor internet connection, but what i want to do is just ignore the invalid response or error and just continue so that my program doesn't break.
I'm getting these errors because of a poor internet connection, I can't fix that. The code is used to access the Betfair API so advising Betfair won't help.
I have a very tremendous issue in my app. App is using webrtc to create video connection between two people.
Currently the app it's in the test phase.
Everything is working fine on Chrome, but on Firefox there is a strange issue.
When the second Peer connects I receive this error:
Error adding ice candidate for pcInvalidStateError: setRemoteDescription needs to called before addIceCandidate
I know that the error message seems to be clear, but how it's possible that on Chrome this error does not exist?
I mean, maybe there is a bigger issue, not completely depending on this error message.
Do you have any ideas or solutions to this?
A part from WebRTC doc: (See Deprecated Exception section)
Deprecated exceptions
When using the deprecated callback-based version of
setRemoteDescription(), the following exceptions may occur:
InvalidStateError The connection's signalingState is "closed",
indicating that the connection is not currently open, so negotiation
cannot take place.
You should check you are not using deprecated callback version of this function. Also you should keep an eye on signalingState of the peer connection.
Hope it helps!
A customer is reporting a connection failure with a strange profile: it apparently only fails for the very first URL request via CFNetwork since the app has launched.
The error code apparently being returned by CFNetwork is domain CFStreamErrorHTTP, but with error code -4, which does not correspond to any publicly defined error code for this domain.
In CFHTTPStream.h, the publicly defined error codes for CFStreamErrorHTTP end auspiciously at -3, strongly hinting that -4 may be an error code that Apple is using but which has not yet been publicly documented.
Any idea what's going on here? Has anybody else seen this error code and found rhyme or reason for it?
Probably not the final answer and this may have changed since they closed sourced CFNetwork, but I did find the following online which indicates that -4 is a connection lost error.
http://www.opensource.apple.com/source/CFNetwork/CFNetwork-129.9/HTTP/CFHTTPConnection.c
I guess you'll have to show some of the code that's failing, but a few questions spring to mind. First, can you trace this issue yourself, can you reproduce it? In particular, it would be interesting to see on which thread this happens, and what's the current runLoop mode. It could be indicative of a stream or connection that fails scheduling on the internal CF runloops.
Other than this (and it's a shame CFNetwork is no longer publicly updated), it could be a zillion things, but you'll need to log as much information as you can if you can't directly debug the failure (hint hint -- https://github.com/fpillet/NSLogger can help you remotely log the info from the client).
Finally, ask the question on Mac Dev Forums (or iOS Dev Forums if your code runs on iOS). Ping Quinn, He Knows It All. Once he can't publicly answer the question, open a DTS incident and send him the ticket #. He's the guy you want to look into your problem :-)
We have a fairly standard client/server application built using MS RPC. Both client and server are implemented in C++. The client establishes a session to the server, then makes repeated calls to it over a period of time before finally closing the session.
Periodically, however, especially under heavy load conditions, we are seeing an RPC exception show up with code 1754: RPC_S_NOTHING_TO_EXPORT.
It appears that this happens in the middle of a session. The user is logged on for a while, making successful calls, then one of the calls inexplicably returns this error. As far as we can tell, the server receives no indication that anything went wrong - and it definitely doesn't see the call the client made.
The error code appears to have permanent implications, as well. Having the client retry the connection doesn't work, either. However, if the user has multiple user sessions active simultaneously between the same client and server, the other connections are unaffected.
In essence, I have two questions:
Does anyone know what RPC_S_NOTHING_TO_EXPORT means? The MSDN documentation simply says: "No interfaces have been exported." ... Huh? The session was working fine for numerous instances of the same call up until this point...
Does anyone have any ideas as to how to identify the real problem? Note: Capturing network traffic is something we would rather avoid, if possible, as the problem is sporadic enough that we would likely go through multiple gigabytes of traffic before running into an occurrence.
Capturing network traffic would be one of the best ways to tackle this issue. If you can't do that, could you dump the client process and debug with WinDBG or Visual Studio? Perhaps compare a dump when operating normally versus in the error state?