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.
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.)
Our applications are using the odbc driver to access an Impala database. We've discovered that in certain difficult-to-replicate situations, the driver will trigger a segfault within its cgo code, which manifests as a fatal error once it propagates back up through the driver and to our code. Since we want some cleanup and alerting to happen in these situations, I implemented a deferred panic catcher, hoping this might catch them.
However, it isn't working. The fatal error continues straight past the deferred function containing the recover() call (so apparently it's not a panic, despite the print output looking similar), though it does catch other panics. A github issue suggests that cgo signals cannot be caught, and that applications should gracelessly and immediately crash if one occurs. This is an unacceptable crash case for our production applications, so I'm wondering if that's changed in the last 6 years, or if anyone knows of another way of running some cleanup code in the event of a cgo signal. It seems like extremely poor design to have no way at all catch and handle these fatal errors.
Calling https://www.googleapis.com/appsmarket/v2/licenseNotification/[myAppId] has suddenly started returning 500 Backend Error every time.
500 error is a generic message, given when no more specific message is suitable. There are a number of causes for a 500 Internal Server Error to display in a web browser.
With any error message, particularly one as broad as the 500 Internal Server Error, you will first want to check your error logs for your server. These logs can provide valuable context related to any code failures or other potential causes of a site failure.
As stated in the answer in this SO question.
In general, every Backend error should be handled with an exponential retry, as
there might be service problems.
If the error still persists after let's say 10 hours then you should
contact the support in order to provide you 1:1 help to your problem.
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.
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?