I'm not really sure what's going on, but today I've noticed that the facebook api is working extremely slow for me.
At first I though it was a bug in my code, but I tried the Graph API Explorer, and even that's causing timeout errors half the time (just using /me):
Failed to load resource: the server responded with a status of 504 (Server timeout)
I don't think its my internet connection, since everything else seems to be working quickly, and http://speedtest.net is giving me good results.
Is my problem somehow fixable or is this just some sort of freak occurance?
Has this happened for anyone else?
Do I need to consider the case that it will take exceedingly long in my application to recieve a response?
I currently have a registration page that waits for a FB.api response (with a spinner gif) before displaying the form. I could use a timeout to wait a few seconds and show it if the api doesn't respond, but I'd really rather not have to use this same sort of logic in every api call that my application depends on...
EDIT: its spontaneously fixed itself now. still no clue what happened.
You can check facebook api live status with this URL
https://developers.facebook.com/live_status
today at 11:13pm: API issues We're currently experiencing a problem
that may result in high API latency and timeouts. We are working on a
fix now.
Related
I have set up a small Mojolicious app to run behind Plack acting as proxy like this:
builder {
mount "/q" => builder {
Plack::App::Proxy->new(remote => "http://127.0.0.1:3010")->to_app;
};
};
I need to run it this way (rather than mounting the application directly) as I need to reload the app a few times a day, for reasons I can't go into here.
The app runs on hypnotoad, and when I hit it directly, everything's fine. However, when hit via the plack proxy, I often get a 502 response - Gateway error: Connection timed out.
The funny thing is, when I reload once or twice, everything seems fine, and I get the proper response.
Can anybody help figure this out?
It's more than possible that the default timeout values in Mojolicious aren't high enough for your app, which may lead to the worker process being stopped by the manager, resulting in an invalid response to the Plack app and thus the 502. So check the config settings for the timeouts and modify if necessary. You may also need to up the number of workers if your app is under heavy load, although i suspect that's not the problem here.
More useful information would be found in the mojolicious app log file - if you run hypnotoad under debug with MOJO_LOG_LEVEL=debug then you will see the connection hit the app, and then a timeout if this is indeed the problem.
The response being fine on a reload is indicative of maybe something being slow to load in your app, or perhaps a cache being populated, etc. Hard to say without log entries from the hypnotoad server
I've run into some weird issues with libSpotify. It seems that any libSpotify-based client will take ages to process requests (sometimes 20 seconds for a simple search, seconds for loading one single image, etc..) sent to Spotify servers, whereas Spotify's own desktop client for Windows works extremely well on the same system, processing requests and loading images in near realtime.
Even the demo app provided with libSpotify, called spshell, exhibits massive problems:
Did anyone experience similar problems and/or knows the cause?
Magically works again since today, no clue why.
We have implemented a system to upload our MP3 podcasts to SoundCloud on a regular basis by using Java SoundCloud API library. Everything works great in 99% of the time.
However, we've had a couple of occasions when a worker thread, which runs periodically every couple of minutes, and whose job is to upload new podcasts (if any) simply gets "stuck" and never finishes the execution, although the code is wrapped with exception catching blocks, no exception ever gets thrown. This stops the execution of any consecutive such thread and the server has to be restarted in order to regain the functionality.
The code used for obtaining access token seems to be the only place where the problem can occur since we were not uploading a podcast at the time when the problems occurred.
When the problem happened we were asking for the token every time the job run (even though there were no podcasts to upload), so we changed that now so we ask for the token only when we upload a podcast (once a week) and it's less likely we will have the same situation again, but we were wondering is this something you've heard about before, and if there is something we can do to avoid this kind of situations? Thank you.
I'll be happy to provide any additional information, if needed.
How does the notification area on Facebook works?
I'm taking about the automatically red box that appears.
If I have a message/something new on my wall.
I believe it is also in Stack Exchange, is that a Javascript interval?
Please see this thread
How does one do realtime updates of a web page?
Not sure about this, but I'd wager that both Facebook and SO use an implementation of Comet. Basically, you make a request to the server which is designed to be kept open a really long time, and the server only responds when it has something to say. When the request times out (or receives data back) you simply start up another one. This way you get as close to real-time data as you can without wasting a ton of bandwidth on empty requests.
When I test some web page using fiddler, sometimes the clientconnected time in the statistics tab is several seconds earlier than the clientDoneReqest time, so it makes the over all time much longer than the actual time it takes to load the page. is this a known issue or I missed something?
thanks.
This is a known issue which is introduced by the fact that the latest version makes much better reuse of client sockets.
You're now seeing the time when the original client socket was opened, for a prior request. In an upcoming version of Fiddler (v.2.2.9) it will be much more clear what's going on, as a new timestamp will be introduced for the client request.