It is a gem that receives an email on localhost when sending an email in the development environment and provides a WEB interface for reading the received email. In other words, until now, "when I sent an email in the development environment, I picked up the text that was output to the log" can now be "viewed on the WEB mailer".
It is a kind of gem called rack server, and there are webrick, unicon, puma, passenger, falcon etc. in the same box. Each rack server has its own characteristics, but rails5 has been bundled with puma, and it has been steadily accumulating usage records in production environments, so the de facto standard is becoming puma. I think.
To be honest, thin seems to be down lately. So why does mailcatcher use thin instead of puma?
The reason I use thin is to run websocket on sinatra. (mailcatcher is designed to update the screen in real time when receiving an email using websocket on the WEB interface using sinatra.)
Websocket does not work with the combination of sinatra and puma. The reason why websocket works with thin is that it is an event loop type using EventMathine. https://github.com/sinatra/sinatra/issues/1035
From here, my imagination and impression is that in the case of a worker thread model like puma, it is not possible to secure a place to hold a websocket connection in order to secure resources for each worker, so a websocket connection Even if you put up, it is discarded when you finish the request. On the other hand, in the case of thin, since it is an event loop type, I thought that it was possible to maintain the connection until it was disconnected. I think the same thing happens with sinatra and unicorn.
Oh, isn't Rails' Action Cable using puma? Doesn't puma and websocket work? I thought, so I looked it up. ActionCable implements a mechanism equivalent to EventMathine that uses Redis pubsub to connect the front and backends and keeps the websocket connection in the rails layer.
Looking at the fact that rails incorporates functions that assume the use of worker thread type, I think that worker thread type servers will continue to be used. I also think that GVL is involved in this decision-making, and I feel that it is difficult to use up the server resources because the event loop type server is a single process.
end
Recommended Posts