Hi, unicorn unconditionally sets rack.multiprocess to true in the Rack environment. The Rack spec [0] says the following about the variable: "true if an equivalent application object may be simultaneously invoked by another process, false otherwise." When unicorn is running with a single worker this does not hold so what do you think about setting the variable to false when only a single worker is configured? I want to use the variable to check if I can do a HTTP call back to the application (long story) but currently with unicorn and single worker this is not possible. Regards, Petteri [0] http://rack.rubyforge.org/doc/files/SPEC.html
Petteri R?ty <betelgeuse at gentoo.org> wrote:> Hi, > unicorn unconditionally sets rack.multiprocess to true in the Rack > environment. The Rack spec [0] says the following about the variable: > > "true if an equivalent application object may be simultaneously invoked > by another process, false otherwise." > > When unicorn is running with a single worker this does not hold so what > do you think about setting the variable to false when only a single > worker is configured? I want to use the variable to check if I can do a > HTTP call back to the application (long story) but currently with > unicorn and single worker this is not possible.We cannot safely set rack.multiprocess=false. Even if unicorn is started with a single worker, it is possible to start more workers via SIGTTIN, and the first worker would never see the change. However, if you''re certain nobody on your server will use SIGTTIN, you can set the following anywhere in your unicorn config file: Unicorn::HttpRequest::DEFAULTS["rack.multiprocess"] = false Changing the DEFAULTS constant has been and will remain supported for as long as this project supports Rack 1.x (forever? :) Since a single process deployment is a corner-case in production deployments, I don''t think it''s worth the effort to jump through hoops and set rack.multiprocess=false automatically.
On 18.10.2012 10.53, Eric Wong wrote:> > Since a single process deployment is a corner-case in production > deployments, I don''t think it''s worth the effort to jump through hoops > and set rack.multiprocess=false automatically. >Do the workers currently know how many others there are? I am trying to understand if you are saying that writing a patch would not be trivial. If it''s relative straightforward I might take a stab. Regards, Petteri
Petteri R?ty <betelgeuse at gentoo.org> wrote:> On 18.10.2012 10.53, Eric Wong wrote: > > > > Since a single process deployment is a corner-case in production > > deployments, I don''t think it''s worth the effort to jump through hoops > > and set rack.multiprocess=false automatically. > > > > Do the workers currently know how many others there are? I am trying to > understand if you are saying that writing a patch would not be trivial. > If it''s relative straightforward I might take a stab.No, workers don''t keep track of other workers and it''s not easy to support this. The workaround with the DEFAULTS hash is your best option.
On 10/18/2012 10:38 AM, Eric Wong wrote:> Petteri R?ty <betelgeuse at gentoo.org> wrote: >> On 18.10.2012 10.53, Eric Wong wrote: >>> Since a single process deployment is a corner-case in production >>> deployments, I don''t think it''s worth the effort to jump through hoops >>> and set rack.multiprocess=false automatically. >> >> Do the workers currently know how many others there are? I am trying to >> understand if you are saying that writing a patch would not be trivial. >> If it''s relative straightforward I might take a stab. > > No, workers don''t keep track of other workers and it''s not easy to > support this. > > The workaround with the DEFAULTS hash is your best option.I think''s Eric''s suggested workaround is right, it is a bunch of work to make workers track other workers to little benefit; but one could cheat and use ps to find sibling processes (children of the worker''s parent which should be the unicorn master): def num_workers `ps -ef`. split("\n"). map{ |line| line.split('' '',4)[2].to_i }. select{ |ppid| ppid == Process.ppid }.size end