I'm not sure if it's something I added in my code recently, but when I try and use Shotgun or Rerun to run my server, it will sometimes hang before it actually says the "Listening on 0.0.0.0" line in Terminal.
I haven't seen this occur when I run my Sinatra server directly with ruby.
There's no errors popping up anywhere - it just seems to hang on starting or reloading after a save... happens about 20% of the time I'd say.
How can I figure out what is causing the issue? I would assume it's either A) something in my code, or B) something going on with my file system.
Why are you using rerun with shotgun? shotgun auto reloads the connection on change.
If you're serving it with puma or something that doesn't refresh when you change the project, then rerun would be necessary.
If you're concerned with speed have a look at this: http://scorchedrb.com/docs/further_reading/code_reloading
Related
I have a Sinatra app, overall configured like described here sinatra docs.
It basically starts an event machine loop.
Now, If I want to write a RSpec test, how do I start server like this and shutdown it after?
I can do this from console by ruby server.rb, I may execute this command from spec file in test suit setup (however, I'm not sure if it is right). But then, even if I do so, how I stop it after? (and do I need or it will be stopped after test is finished?)
I think, in any case, you can use Rack::Test to test your Sinatra app. In order to run the specs, you don't need to run the server from the terminal.
Take a look at the documentation, you can find different examples:
http://www.sinatrarb.com/testing.html
I had run into a few problems getting Ruby fully installed and working, so I could start building. I finished installing and tested my server at localhost:3000, and it came up fine. Then the next day when I tried to go back to it, it didn't connect and I could not figure out why.
First of all, there's no specific way for us to address this issue. You haven't mentioned any of what happened between the server working and malfunctioning? It could be as simple as the server not being started. Is the server currently running? If it is than you should have some sort of response when you try to hit localhost.3000.
Make sure your server is running with rails s and then let us know.
Perhaps you can try resetting your DB with a rake db:reset if that doesn't work.
Besides that, there really isn't anything we can do on this end without more information.
I have done something silly and written a script for a website that does an ajax check every 2 seconds. In this case its using wordpress and its admin-ajax.php file every 2 seconds. This essentially burned up all the CPU power of the server, and made every site on the server run really slowly.
After a lot of detective work, i finally found the script and stopped it, so that it doesn't happen on new loads of that website. But looking at my apache log, i can see that it is still running in one browser somewhere.
Is there a way for me to stop that browser from requesting that ajax-call, or perhaps block it from my server? Or will I just have to wait until that browser is being refreshed or closed?
Try to use netstat or something similar through ssh to detect the IP and port of the unknown browser. Also you should try to reboot the server so it may will loose connection.
PS: It's pretty hard to give a clue or answer in the right direction without having any logs or evidence to ensure you answer to this question correctly.
I am using Meteor on Heroku (free tier) with MongoHQ. My app is very simple right now, it loads 3-4 entries from a Collection, but when I deploy it to Heroku, I am seeing ridiculous load times (1-2 minutes). The HTML is rendered immediately. When I deploy to Meteor.com's free server, load times are a lot lower but still about 15 seconds for 4 tiny pieces of data. I'm not seeing this whatsoever when I deploy locally, app pulls data from the DB right away.
It is worth noting that I don't think it's an "idling" issue for Heroku. Even if I already have one browser window with the app just opened, if I use a different browser and try again I still get 1-2 minute load times. Once the data is loaded, however, performance goes back to being great, I can read and write with no problems.
What am I missing? I'm not seeing any errors in the console, mongo shows several queries in the logs and shows that it is responding quickly with 4 documents, but apparently somewhere in the middle there's a traffic jam. Any help with this is greatly appreciated, if I can't get past this Meteor is useless for my needs right now.
UPDATE: I've been watching it closely in Firebug, and it looks like the performance is largely inconsistent. Sometimes a simple refresh will take 1 minute, sometimes it will take 10 seconds. But what I've noticed is that the times when its slow, it GETs the sockjs/info file, then right after that the sockjs POST is aborted (sometimes multiple times). When it runs fast, the POST and subsequent POSTs run smoothly
Slow:
GET http://pocleaderboard.herokuapp.com/sockjs/info 200 OK 22ms
POST http://pocleaderboard.herokuapp.com/sockjs/029/su0d77fb/xhr Aborted
GET http://pocleaderboard.herokuapp.com/sockjs/info 200 OK 27ms
POST http://pocleaderboard.herokuapp.com/sockjs/132/uljqusxd/xhr Aborted
GET http://pocleaderboard.herokuapp.com/sockjs/info 200 OK 28ms
POST http://pocleaderboard.herokuapp.com/sockjs/154/kcbr6a5p/xhr Aborted
Fast(er):
GET http://pocleaderboard.herokuapp.com/sockjs/info 200 OK 1.08s
POST http://pocleaderboard.herokuapp.com/sockjs/755/xiggb555/xhr 200 OK 1.02s
Meteor gets loaded that fast locally, because it doesn't depend on your internet connection and the files can just be read from your harddrive and don't need to be downloaded.
And once the data is loaded it's the same everywhere you host, because the client (you) perform all actions on your cached mongo database and then just wait for the server to say if the action was alright or not.
But for the Heroku loading times, I have no idea, Sorry!
UPDATE:
These are the long-pulls from SockJS that is used by Meteor.
Normally these pulls only get Aborted on a hot code push (when a file is added/changed/removed).
Either you or Heroku seem to write or change something in the directory.
Because then a hot code push may be initiated by Meteor.
Heroku may not support web-sockets, which means you're stuck with the slower polling approach. See this:
https://devcenter.heroku.com/articles/using-socket-io-with-node-js-on-heroku
How can I force Redis to do a blocking save? I am using the Ruby Redis gem, but I believe this question is not specific to that library. It seems like SAVE and a BGSAVE commands seem to flutter away doing stuff in the background, causing "-ERR background save in progress" errors on subsequent calls.
Hopefully this would be a boring, synchronous call that blocks all other Redis commands until the save over "dump.rdb" is finished. And hopefully this will not require actually shutting down the server, mucking around with "/etc/init.d/redis-server". Presumably I should be polling with the LASTSAVE command?
if you call SAVE but you get an error about a background save in progress, this means that there is also a BGSAVE in progress, becuase one of this is true:
1) Somebody called BGSAVE
2) Redis is configured to save from time to time (the default).
So your SAVE fails since there is already a save in progress. You can check if there is a background in progress, and when it is completed, checking the INFO output.
SAVE is a synchronous save; BGSAVE is the asynchronous one.
Why do you think SAVE is running in the background?
Redis#save does just that. What version of Redis and redis gem are you using?