Rails Server working in command line. Not at Localhost - ruby-on-rails

rails server
=> Booting Puma
=> Rails 5.2.0 application starting in development
=> Run rails server -h for more startup options
[44266] Puma starting in cluster mode...
[44266] * Version 3.6.2 (ruby 2.5.1-p57), codename: Sleepy Sunday Serenity
[44266] * Min threads: 5, max threads: 5
[44266] * Environment: development
[44266] * Process workers: 1
[44266] * Preloading application
[44266] * Listening on tcp://localhost:3000
[44266] Use Ctrl-C to stop
[44266] - Worker 0 (pid: 44286) booted, phase: 0
^C[44266] - Gracefully shutting down workers...
[44266] === puma shutdown: 2018-06-12 14:28:53 -0500 ===
[44266] - Goodbye!
Exiting
went to http://www.localhost3000.org/
says you forgot to start your server
Running
Rails 5.2.0
Postgesql 9.6

It looks like http://www.localhost3000.org/ is a website that someone bought to help you when you mistype your attempt to get to your localhost. It's not your own server responding
As the website suggests, try to go instead to http://localhost:3000

Use this address localhost:3000. The link you included is a live website someone has published as a reminder to start your server.

Use this address http://localhost:3000 but you can still edit your url, follow this article: Edit localhost

Related

Rails 6 are you trying to open an SSL connection to a non-SSL Puma?

I'm trying to set up Rails on AWS ECS with HTTPS access. When my ECS Service is deployed, these are the logs:
=> Rails 6.1.3.2 application starting in production
=> Booting Puma
* Listening on http://0.0.0.0:3000
* PID: 1
* Environment: production
* Max threads: 5
* Min threads: 5
* Puma version: 5.3.2 (ruby 3.0.1-p64) ("Sweetnighter")
Puma starting in single mode...
* Listening on http://0.0.0.0:3000
Use Ctrl-C to stop
2021-08-06 06:21:21 +0000 HTTP parse error, malformed request:
#<Puma::HttpParserError: Invalid HTTP format, parsing fails. Are you trying to open an SSL connection to a non-SSL Puma?>
I believe the health checks are hitting the container and failing. I'm not sure why this is happening. I already set config.force_ssl = true in my environments/production.rb. Any suggestions on what I am missing?
I'm using Rails 6.1.3.2 and ruby 3.0.1. Thanks!

Heroku Rails server API not setting the correct port number when starting up

I have a Rails API Backend with a React front end that is deployed to Heroku. When I try to load a page that makes a call to the API, it hangs and then finally gives this error in the console:
GET https://MYAPP.herokuapp.com:3001/auth/refresh_token net::ERR_TIMED_OUT
When I look at the logs while the application is starting up, it looks as though I'm setting the port to 3001 which is what I want but it looks as those puma is listening on a different port number:
2020-10-01T04:28:51.720203+00:00 heroku[web.1]: Starting process with command `bundle exec puma -t 5:5 -p ${PORT:-3001} -e ${RACK_ENV:-production}`
2020-10-01T04:28:55.321298+00:00 app[web.1]: Puma starting in single mode...
2020-10-01T04:28:55.321325+00:00 app[web.1]: * Version 4.3.5 (ruby 2.6.6-p146), codename: Mysterious Traveller
2020-10-01T04:28:55.321326+00:00 app[web.1]: * Min threads: 5, max threads: 5
2020-10-01T04:28:55.321326+00:00 app[web.1]: * Environment: production
2020-10-01T04:29:04.625683+00:00 app[web.1]: * Listening on tcp://0.0.0.0:55912
Should I be configuring my fetches to use this URL instead?: https://MYAPP.herokuapp.com/auth/refresh_token
Basically, what I'm asking is: Based on this log information where is my Rails API listening if my React application is listening at: https://MYAPP.herokuapp.com?

ROR: Puma webserver doesn't process multiple request at a time

I'm using rails5.2. For testing i've created below controller.
class IndexController < ApplicationController
def index
sleep(10)
render text: "done"
end
end
If I make 5 parallel requests, 1st request takes 10s, 2nd takes 20s, 3rd takes 30s and so on..
myAppRails5 aravind$ bin/rails server
=> Booting Puma
=> Rails 5.2.0 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.11.4 (ruby 2.5.1-p57), codename: Love Song
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000
Use Ctrl-C to stop
Puma configuration : Min threads: 5, max threads: 5
Rails 5.2.0 application starting in development
development.rb
puma.rb
As per puma doc, threaded is supported. How do I achieve multi threading here?

Rails initializer (using JRuby, Puma) at_exit is occasionally not executed

I'm trying to make a little library that wraps over march_hare and is used as part of our Rails app. It needs to connect on app startup and disconnect on shutdown.
I'am aiming to something similar to the ruby-kafka Rails integration via initializer:
configure my service
run it
specify shutdown procedure
The problem is my at_exit blocks are sometimes not executed. What may be the cause of this issue? Is there a way to fix it and ensure my at_exit blocks are called?
Investigating the issue, I created a blank demo app with the following initializer:
class SomeClass
def self.shutdown(reason)
msg = "#{Time.now} SHUTDOWN via #{reason}!"
puts msg
open('log/development.log', 'a') do |f|
f.puts msg
end
end
end
at_exit { SomeClass.shutdown(:at_exit1) }
at_exit { SomeClass.shutdown(:at_exit2) }
at_exit { SomeClass.shutdown(:at_exit3) }
puts "#{Time.now} INITIALIZED!"
In 9 out of 10 run + terminate cycles I get:
$ rails s
=> Booting Puma
=> Rails 4.2.7.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
2017-05-22 15:29:16 +0300 INITIALIZED!
Puma starting in single mode...
* Version 3.4.0 (jruby 9.1.2.0 - ruby 2.3.0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
^C- Gracefully stopping, waiting for requests to finish
Exiting
=== puma shutdown: 2017-05-22 15:29:30 +0300 ===
- Goodbye!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit3!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit2!
2017-05-22 15:29:30 +0300 SHUTDOWN via at_exit1!
But once in a while the result is:
$ rails s
=> Booting Puma
=> Rails 4.2.7.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
2017-05-22 15:29:45 +0300 INITIALIZED!
Puma starting in single mode...
* Version 3.4.0 (jruby 9.1.2.0 - ruby 2.3.0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
^C- Gracefully stopping, waiting for requests to finish
Exiting
=== puma shutdown: 2017-05-22 15:30:17 +0300 ===
- Goodbye!
2017-05-22 15:30:17 +0300 SHUTDOWN via at_exit2!
2017-05-22 15:30:17 +0300 SHUTDOWN via at_exit1!
My Gemfile has only gem 'puma' added.
Ruby version: jruby 9.1.2.0
Rails version: Rails 4.2.7.1
System Version: macOS 10.12.4
This is something to do with JRuby. You could try upgrading JRuby to the latest version and see if that's fixed.
Else follow this thread for more reference.
https://github.com/jruby/jruby/issues/5437

Why is rails server listing on tcp

I am working on a project which is an updated version of a new project. Using vagrant to load virtual environment and when i run
RAILS_ENV=development bundle exec rails s
The following is returned:
=> Booting Puma
=> Rails 5.0.0.1 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.6.0 (ruby 2.3.3-p222), codename: Sleepy Sunday Serenity
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://localhost:3000
Use Ctrl-C to stop
When i visit the browser I have tried localhost:3000 and 127.0.0.1:3000 but keep getting:
ERR_CONNECTION_REFUSED
On the previous version of this project on a different repository loaded it was accessible via these URL's. This project has been updated to Rails 5 but dont know why it is listening on TCP rather than HTTP. Any suggestions?
As it has been already suggested, make sure that the server is bounden to 0.0.0.0 so that all interfaces can access it.
You might try:
RAILS_ENV=development bundle exec rails s -b 0.0.0.0

Resources