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.
Related
I want to use server-side events with rails. It works locally without any problem. But it does not trigger on production with unicorn.
Is it possible to use SSE with unicorn?
You need a threaded web server such as Puma, as each connection requires a separate thread to keep the long running connection open.
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
I'm migrating my rails app (still in development) from Thin to Unicorn. My app uses config.force_ssl = true.
When using Thin I could just write:
thin start --ssl
My question is: What is the equivalent way to start Unicorn with ssl in development?
If I correctly understood your question, you're trying to run unicorn on port 443.
This is a bad idea.
Instead, to achieve the same goal, I would suggest, run unicorn on an unprivileged port (above 1024), or better on a unix socket, and switch Nginx before, passing all static stuff directly trough nginx, and the rails stuff, trough unicorn.
I know this doesn't answer your question, but for the user, it will work exactly the same, with some benefits when your app server (unicorn) crashes, for example a nice rendered 502 error page served via nginx instead of a plain network error message seen in the browser of your users.
You can with this solution run X different applications on the same port, with different subdomains. a must have for a development machine with many projects.
I've been struggling with this error for quite some time:
Redis::ProtocolError: Got 'i' as initial reply byte.
If you're running in a multi-threaded environment, make sure you pass the :thread_safe
option when initializing the connection. If you're in a forking environment, such as
Unicorn, you need to connect to Redis after forking.
It happens intermittently in apps that use Unicorn and Redis. From this redis-rb Github issue it looks the :thread_safe option is now enabled by default. I am using redis 2.2.2 because redis 3.0.1 is not compatible with the latest version of resque.
In my Unicorn config I'm using Redis.current.quit after the fork.
I'm also connecting to Redis with a gem called ruote-redis which is a storage implementation for the workflow engine Ruote.
How can I ensure that all of my Redis connections are stable and that I don't get this error anymore which is disrupting to the normal use of our app?
Unicorn is not multi-threaded. Are you using threads yourself?
As stated in the docs, the problem you're hitting is that multiple Unicorn workers are sharing the same connection (ie the same underlying file descriptor).
This change, included in version redis-rb 3.0, makes it even clearer.
If you're still hitting this error please post your Unicorn configuration.
I'm trying to make Resque work with my project, but unfortunately it seems that for some reasons Resque is not able to write on Redis.
Redis seems to be configured correctly, I'm able to connect with redis-cli and issue commands, runs on port 6379 as configured inside my Rails 3.0.5 app.
When I try to Resque enqueue something the job is queued, but it doesn't seem that something actually happens on Redis (0 clients connected inside my Redis logs).
When I restart the console, the queue is empty, with no workers running.
Everything fails silently, I have nothing in my rails logs, nothing on the console, nothing if I start a worker, it just (obviously) doesn't find any job to perform.
https://gist.github.com/867620
Any suggestions on how to fix or debug this ?
The problem was that I was including resque_spec in the bundle.
Obviously, resque_spec was stubbing Resque.enqueue, making my mistake very stupid and very difficult to spot.