Inside a test environment I am using the wash_out GEM within a Ruby on Rails server to run a SOAP service that serves as a Proxy between two different transfer protocols.
At the end of the test run, I would like to quit the Rails server with a dedicated SOAP request.
So I implemented such a request and called inside the request exit(0). But it seems to me that exit and abort functions are hooked away because of security or other reasons.
One might argue that terminating the service within a request is a little bit harsh, but at that point I do not care how the service gets terminated. Since it does not hold any state.
I would like to avoid to patch the Rails sources so that it is later easier to update the GEMSs.
Edit:
The server is running (unfortunately) on Windows.
You could execute shell script and kill running rails process. For example if you running service on unicorn you could do something like
def exit_app
%x(kill -9 $(cat tmp/pids/unicorn.pid))
end
Related
An application can start the Thin web server
rails s
However, launching the console
rails c
hangs and never returns to a prompt.
Obviously, I need it to run!
note 1: I believe this is a consequence of an external disk that houses the application, that lost its connection to the main computer
note 2: I had read incidentally that the spring gem has some un-robust behaviours. Could this be a motive?
run following command & it should be fix
spring stop
I was wondering if there was a way to use the Puma server (Rails default) JUST on the new Rails 5.1 system tests?
Right now on all our projects we use tiny_tds, but I was trying to experiment with 5.1 system tests with Capybara/Selenium but it fails of course because I do not have Puma installed/running.
I took a look through the documentation and didn't see anything about declaring what type of server you want to use. Were connecting to a SQL Server database so I don't know if Puma is able to do that (And that's probably why were using tiny_tds in the first place).
You're confusing database adapters and rack web servers which are very different things.
Puma (like Webrick, Thin, Unicorn etc) is a general purpose Rack web server. It sits and waits for incoming requests from vistors and dispatches them to an application (like a Rails app) by calling it with a hash containing the environment and request. The application returns an array containing the response. The server sends it back to the visitor.
tiny_tds on the other hand is a database adapter. Its used to connect the application to the database. The web server is almost completly oblivious to how the application creates a response from the request. This includes whatever databases are used.
In Rails 5 most servers don't require configuration. You just add the gem to the gemfile and run bundle install and they plug themselves in. There in no seperate installation step.
That was not the case earlier which is why Webrick - a server with the only real merit being that it does not require configuration was the default. It is now Puma which unlike Webrick is suited for production.
Using different servers in different environments is not a good idea since it violates the idea of dev/prod parity. Your dev & test environment should be as close as possible to what you are deploying to so that you can catch bugs before they end up in production. This means you should be running the same server, same database etc.
Running a seperate test server for different parts of your test suite sounds like a true fools errand - if its even possible without hacking the framework to bits.
For SQL Server there is activerecord-sqlserver-adapter which can use tiny_tds as a backend.
My webapp consits of a HTTP server and a WebSocket server, both running on Rails. For Websockets I am using em-websocket which I start in the initializers, like this:
Thread.new do
EventMachine.run do
EventMachine::WebSocket.run(EVENTCHAT_CONFIG) do |socket|
[...]
end
end
end if Rails.const_defined?(:Server)
This works fine when I start the server with 'rails s', but it doesn't work in detached mode ('rails s -d'). When I try to connect to the Websocket server via JS it tells me, that it is still in connecting state, so I guess something is blocking it.
I also think this might be related to the threading.
I also tried starting the server with thin and unicorn, but both fail to start the Websocket Server.
Am I going against the convention here?
I just made the switch to foreman, which enables me to start multiple ruby processes with one command. You just have to add a Procfile. For deployments you can export this to various init systems, like in my case upstart.
It doesn't work for me yet, though I do think this is the way to go.
I'd like for a ruby server script that lives in my rails app root folder to accept connections from clients (the clients are not browsers--not that this really matters i guess) and update the db of my rails app while my rails app is running. Therefore, I'd like for it to be told somehow to start running whenever my web server starts serving up my rails app and stop running whenever my web server stops serving my rails app. How can I do this? Is this as simple as putting the name/path of my ruby server script somewhere?
You should look into Foreman, a gem specifically for launching multiple processes in your server environment.
I have a Rails (2.3.8) application that will need to start and maintain a SSH tunnel whenever the application is started using 'script/server' or when started using Passenger. When script/server is ^C'd or the Passenger instance is shut down the SSH tunnel should be destroyed.
I do not want the tunnel to be started when I run 'script/console' - so using config/environment.rb doesn't look like a good option.
As such, I don't want the tunnel to be backgrounded - I want it to be attached and owned by the ruby process, and I only want one tunnel per server.
The tunnel itself will most likely be started by running SSH directly, but if there's a simple way to do it using the SSH libraries I'll use that instead.
Is there a way to do this in Rails? I can think of a way to do it using config/environment.rb using a series of lock files and other bits of messing around, but I was hoping for some sort of :on_server_start and :on_server_exit hook.
--
For the curious, I need to do this as the Rails application is running in location A and will receive updates from a series of services in location B. Location B, however, does not have a direct route to location A. I will be starting a SSH tunnel from the application to a machine in location B and the services in location B will send updates to that machine instead.
Managed to solve this one using config/environments/*.rb and a quick fork hack. See gist: http://gist.github.com/466267
So, it'll be run if you use RAILS_ENV=production but not for test/development.