[PATCH] test/unit/test_response.rb: compatibility with older test-unit
- by Eric Wong @ 07/05 00:31 UTC - next

assert_predicate really isn't that useful even if it seems
preferred in another project I work on.  Avoid having folks
download the latest test-unit if they're on an old version of
Ruby (e.g. 1.9.3) which bundled it.

more... raw reply threadlink

Unicorn returns blank page after no use
- by Farjad Adamjee @ 07/01 16:08 UTC - next/prev

Hello,

I am not sure if this is the correct place for this, I have googled 
around to see if anyone else has encountered such an issue, but I did 
not find anything.

I am having this issue where after a period of time of no use (on beta 
[production] environment), maybe 12 hours or so, the unicorn process 
sleeps. When I go and re-request the page, it returns blank.

I am using Apache proxy to Unicorn.

My unicorn.stderr.log states:
I, [2015-07-01T03:07:05.168511 #13258]  INFO -- : master done reopening logs
I, [2015-07-01T03:07:05.232546 #16222]  INFO -- : worker=2 done 
reopening logs
I, [2015-07-01T03:07:05.239934 #13308]  INFO -- : worker=0 done 
reopening logs
I, [2015-07-01T03:07:05.307616 #13311]  INFO -- : worker=1 done 
reopening logs


When I request the page again, it loads fine. It is only during the 
process of "reopening logs" when it returns a blank page.

My unicorn.rb file:

worker_processes 3

# Load app into the master before forking workers
# for super-fast worker spawn times
preload_app true

# Listen on
listen "127.0.0.1:8550", :backlog => 1024

# Restart any workers that haven't responded in 180 seconds
timeout 600

# PID for the Unicorn master
pid "/var/www/r/shared/pids/unicorn.pid"

# Unicorn Log paths
stderr_path "/var/www/r/shared/log/unicorn.stderr.log"
stdout_path "/var/www/r/shared/log/unicorn.stdout.log"

before_fork do |server, worker|
   ##
   # When sent a USR2, Unicorn will suffix its pidfile with .oldbin and
   # immediately start loading up a new version of itself (loaded with a new
   # version of our app). When this new Unicorn is completely loaded
   # it will begin spawning workers. The first worker spawned will check to
   # see if an .oldbin pidfile exists. If so, this means we've just 
booted up
   # a new Unicorn and need to tell the old one that it can now die. To 
do so
   # we send it a QUIT.
   #
   # Using this method we get 0 downtime deploys.
   defined?(ActiveRecord::Base) and 
ActiveRecord::Base.connection.disconnect!
   defined?(OathKeeper) and OathKeeper.disconnect!

   old_pid = '/var/www/r/shared/pids/unicorn.pid.oldbin'
   if File.exists?(old_pid) && server.pid != old_pid
     begin
       Process.kill("QUIT", File.read(old_pid).to_i)
     rescue Errno::ENOENT, Errno::ESRCH
       # someone else did our job for us
     end
   end
end

after_fork do |server, worker|
   ##
   #  # Unicorn master loads the app then forks off workers - because of 
the way
   #    # Unix forking works, we need to make sure we aren't using any 
of the parent's
   #      # sockets, e.g. db connection
   #
   defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection
   defined?(OathKeeper) and OathKeeper.reconnect
end

Any help would be appreciated!
Thank you!

Farjad

more... raw reply threadlink

  Re: Unicorn returns blank page after no use
  - by Eric Wong @ 07/01 17:30 UTC - next/prev

  Farjad Adamjee <fadamjee@vailsys.com> wrote:
  > Hello,
  > 
  > I am not sure if this is the correct place for this, I have googled
  > around to see if anyone else has encountered such an issue, but I
  > did not find anything.
  
  This is the correct place :)  Plain-text email is the only way I
  handle support for ease-of-archival and distribution.
  
  > I am having this issue where after a period of time of no use (on
  > beta [production] environment), maybe 12 hours or so, the unicorn
  > process sleeps. When I go and re-request the page, it returns blank.
  
  This sounds like a database (or any other persistent connection
  backend) connection expiring due to an idle timeout.
  
  This could also be a firewall/router timeout problem between the
  server running unicorn and the database host.
  
  Tony experienced this last year:
  http://bogomips.org/unicorn-public/m/CAKM1sPNRsES6H6ByK6bO9Djwa8WvYV6HJ-rEaHopRUYBVFfuhg@mail.gmail.com
  
  You can confirm by running lsof on a worker processes to look for
  open sockets.  In case the connection loss isn't noticed by the
  OS, use strace (or any other similar syscall tracer for your OS)
  instead and watch connection activity.
  
  With strace (or similar) knock yourself down to one worker
  process via SIGTTOU to the master to ensure you're always tracing
  the correct one.
  
  > I am using Apache proxy to Unicorn.
  
  By the way, this is not recommended for slow clients.
  nginx (Open Source edition) is currently the only supported proxy.
  
  >   # Using this method we get 0 downtime deploys.
  >   defined?(ActiveRecord::Base) and
  > ActiveRecord::Base.connection.disconnect!
  >   defined?(OathKeeper) and OathKeeper.disconnect!
  
  I suggest disabling any idle timeout you might have, enabling TCP
  keepalive and enabling reconnects (see AR and your database driver
  documentation).  Worst case (firewall/router problem you can't
  fix via configuration), is to send a request to unicorn every
  few minutes/hours to keep things going.
  
  Perhaps OathKeeper has the same problem, too...
  I've never heard of it until now.

  message raw reply parent threadlink

[PATCH 0/3] reflect changes to Rack::Utils::HTTP_STATUS_CODES
- by Eric Wong @ 06/30 22:51 UTC - next/prev

A user privately reported (to unicorn@bogomips.org) that they wanted
status text reflected in their responses for an HTTP status code not
included with Rack::Utils::HTTP_STATUS_CODES.

They tried to modify Rack::Utils::HTTP_STATUS_CODES hash directly in
their app, but unicorn loads before their app and already memoized the
status codes internally in the CODES hash to reduce GC pressure, thus
their change was never reflected.

With the first change, users can change Rack::Utils::HTTP_STATUS_CODES
as many times as they want (perhaps even based on time-of-day, weather,
server load, whatever) and the changes will be reflected
instantaneously in responses.

Of course, this slows unicorn down slightly due to increased GC
pressure, but I doubt anybody would notice in Real World usage.
In case they do, patch 2/3 will recover the lost performance
if they're using Ruby 2.2+

I figure anybody who cares about micro-benchmark performance with
unicorn would be using the latest Rubies anyways...

That user is Bcc:-ed for these patches, and can follow any public
discussion at: http://bogomips.org/unicorn-public/
(including the Atom feed at http://bogomips.org/unicorn-public/atom.xml )

* [PATCH 1/3] reflect changes in Rack::Utils::HTTP_STATUS_CODES
  introduces a performance regression

* [PATCH 2/3] reduce constants and optimize for Ruby 2.2
  recover lost performance from [PATCH 1/3] (on Ruby 2.2+),
  further regressions for 2.1+

* [PATCH 3/3] http_response: reduce size of multi-line header path
  bonus reduce code size for common cases, should

 lib/unicorn/http_request.rb  | 19 +++++++------------
 lib/unicorn/http_response.rb | 23 ++++++++++-------------
 test/unit/test_response.rb   | 20 ++++++++++++++++++++
 3 files changed, 37 insertions(+), 25 deletions(-)

message raw reply threadlink

  [PATCH 1/3] reflect changes in Rack::Utils::HTTP_STATUS_CODES
  - by Eric Wong @ 06/30 22:51 UTC - next/prev

  Applications may want to alter the message associated with HTTP
  status codes in Rack::Utils::HTTP_STATUS_CODES.  Avoid memoizing
  status lines ahead-of-time
  
  Note: this introduces a minor performance regression, but ought to
  be unnoticeable unless you're running "Hello world"-type apps.

  more... raw reply parent threadlink

  [PATCH 2/3] reduce constants and optimize for Ruby 2.2
  - by Eric Wong @ 06/30 22:51 UTC - next/prev

  Ruby (MRI) 2.1 optimizes allocations away on String#freeze with
  literal strings.
  
  Furthermore, Ruby 2.2 optimizes away literal string allocations
  when they are used as arguments to Hash#[] and Hash#[]=
  
  Thus we can avoid expensive constant lookups and cache overhead
  by taking advantage of advancements in Ruby.
  
  Since Ruby 2.2 has been out for 7 months, now; it ought to be safe
  to introduce minor performance regressions for folks using older
  Rubies (1.9.3+ remains supported) to benefit folks on the latest
  Ruby.
  
  This should recover the performance lost in the
  "reflect changes in Rack::Utils::HTTP_STATUS_CODES" change
  in synthetic benchmarks.

  more... raw reply parent threadlink

  [PATCH 3/3] http_response: reduce size of multi-line header path
  - by Eric Wong @ 06/30 22:51 UTC - next/prev

  This should save over 100 bytes of bytecode overhead due to
  reduced method dispatch points.  The performance difference
  when this is actually hit could go either way depending on
  how String#<< and realloc(3) interact, but it's uncommon
  enough that nobody is expected to notice either way.

  more... raw reply parent threadlink

[PATCH] apply TCP socket options on inherited sockets
- by Eric Wong @ 06/27 02:57 UTC - next/prev

TCP socket options are now set when inheriting existing sockets from
a parent process.  I'm fairly certain all the TCP setsockopt knobs
we use are idempotent and harmless to change.

If anything, the only directive I'd be uncomfortable changing is
shortening the listen(2) (aka :backlog) size, but we've always
changed that anyways since it also applies to UNIX sockets.

Note: removing a configuration knob in a unicorn config file can not
reset the value to the OS-provided default setting.  Inherited
sockets must use a new setting to override existing ones.
(or the socket needs to be closed and re-created in the process
 launcher before unicorn inherits it).

Noticed-by: Christos Trochalakis <yatiohi@ideopolis.gr>
  <20150626114129.GA25883@luke.ws.skroutz.gr>

more... raw reply threadlink

Does the the environment is preserved on USR2?
- by Bráulio Bhavamitra @ 06/26 22:18 UTC - next/prev

Hello,

I use the ruby environment variable RUBY_GC_MALLOC_LIMIT='90000000' to
start unicorn inside a init.d service and I get the impression that
when I run kill -USR2 `cat tmp/pids/unicorn.pid` in another shell this
variable is no longer used.

So the new master started by USR2 preserve the environment from the
old master or the environment variables need be set on the shell it is
invoked?

cheers,
bráulio

more... raw reply threadlink

  Re: Does the the environment is preserved on USR2?
  - by Eric Wong @ 06/26 22:31 UTC - next/prev

  USR2 should not change environment variables besides UNICORN_FD
  and PWD (if working_directory is used).
  
  On most Linux versions, you can check the initial environment of a
  running process by inspecting the environ file for the process:
  
  	tr '\0' '\n' < /proc/$PID/environ
  
  This may not reflect environment changes after the process is started.
  
  However, you can use ENV inside Ruby code to check that.  Maybe add a
  private Rack endpoint to show ENV.inspect output to your app to check
  this...

  message raw reply parent threadlink

    Re: Does the the environment is preserved on USR2?
    - by Eric Wong @ 06/26 23:14 UTC - next/prev

    Eric Wong <e@80x24.org> wrote:
    > USR2 should not change environment variables besides UNICORN_FD
    > and PWD (if working_directory is used).
    > 
    > On most Linux versions, you can check the initial environment of a
    > running process by inspecting the environ file for the process:
    > 
    > 	tr '\0' '\n' < /proc/$PID/environ
    > 
    > This may not reflect environment changes after the process is started.
    
    Actually, I noticed this doesn't even reflect ENV changes on
    fork from Ruby (but system("env") displays the correct result
    from a forked process) using Linux 4.0.6
    
    > However, you can use ENV inside Ruby code to check that.  Maybe add a
    > private Rack endpoint to show ENV.inspect output to your app to check
    > this...
    
    So use ENV from Ruby instead :)

    message raw reply parent threadlink

      Re: Does the the environment is preserved on USR2?
      - by Bráulio Bhavamitra @ 06/26 23:38 UTC - next/prev

      On Fri, Jun 26, 2015 at 8:14 PM, Eric Wong <e@80x24.org> wrote:
      > <Eric Wong <e@80x24.org> wrote: >> USR2 should not change ...>
      
      Thanks Eric, will try this!

      message raw reply parent threadlink

TAN: Ragel now maintained by Colm networks
- by Eric Wong @ 06/26 19:46 UTC - next/prev

As most of you know, unicorn has always used Ragel for HTTP
parsing (inherited from Mongrel).

For the most part, Ragel works great and does not need much
maintenance.  I made some changes to work with the Ragel 5-to-6
transition for Mongrel (pre-unicorn) and that was it.

Since I mainly use Ragel from the Debian package nowadays,
I missed this bit of news when it was posted 2014-10-24.

http://www.colm.net/ragel-now-maintained-by-colm-networks/

| As of October 2014, Ragel will be maintained by Colm Networks. 
| This is a new consulting company founded by Dr. Adrian D.
| Thurston.

(ed: Adrian Thurston is the original author of Ragel)

| Since we cannot operate in the open, the git repository for
| Ragel  will no longer be available. The project will be
| published as release (and pre-release) tarballs only. On the
| upside, Ragel will get much more attention.

*Sigh* I guess we'll need to diff release tarballs from now on...

I'm not very knowledgeable in C++, so any extra help auditing Ragel
changes would be greatly appreciated.

| The license will remain the same: GPLv2 with an exception for
| the generated code derived from Ragel source.

OK, at least that is good to hear.

Fwiw, the ragel-users mailing list (where I lurked) closed in
July 2014, too.

Anyways, I still love Ragel as a tool/language and have used it
in other projects.  For now, it seems to work, but I'm hesitant
to start new projects using it.

message raw reply threadlink

  Re: TAN: Ragel now maintained by Colm networks
  - by Bráulio Bhavamitra @ 06/26 21:03 UTC - next/prev

  Sad news to hear companies that don't understand free software taking
  maintainership of good free software :(
  
  Maybe the best would be to maintain a fork of it...
  
  cheers,
  bráulio
  
  On Fri, Jun 26, 2015 at 4:46 PM, Eric Wong <e@80x24.org> wrote:
  > <As most of you know, unicorn has always used Ragel for HTTP > parsing ...>

  message raw reply parent threadlink

Re: [DRE-maint] unicorn: native systemd service
- by Christos Trochalakis @ 06/26 11:41 UTC - next/prev

On Thu, Jun 25, 2015 at 11:26:26PM +0000, Eric Wong wrote:
> <+Cc unicorn-public list >Christos Trochalakis ...>

Yes, you are right socket activation is also an option! I have made some
experiments with a simple rack app to test it.

systemd uses the LISTEN_FDS env variable that is an integer indicating the
number of inherited file descriptors. Those FDs have consecutive numbers
starting from `SD_LISTEN_FDS_START` which is `3` (man sd_listen_fds).

So for example if LISTEN_FDS="2", UNICORN_FD should be "3,4". I used a
simple wrapper script for that. Here is the full configuration:

$ tail -n+1 /srv/uni/* /etc/systemd/system/uni.*

==> /srv/uni/config.ru <==
app = proc do |env|
  sleep 5
  [
    200,
    { 'Content-Type' => 'text/plain' },
    ["Socket Activated!\n", "pid:#{$$}\n", "ppid:#{Process.ppid}\n"]
  ]
end

run app

==> /srv/uni/unicorn.conf.rb <==
worker_processes 2
working_directory "/srv/uni"

# Keep in sync with uni.socket
listen 9000, :tcp_nopush => true
listen 9001, :tcp_nopush => true

==> /srv/uni/wrapper <==
#!/bin/bash

[ -z "$LISTEN_FDS" ] && exec $@

UNICORN_FD=""
for fd in `seq 3 $(($LISTEN_FDS+2))`; do
	UNICORN_FD="${UNICORN_FD}${fd},"
done
export UNICORN_FD

echo "wrapped fds: ${UNICORN_FD}"

exec $@

==> /etc/systemd/system/uni.service <==
[Unit]
Description=Unicorn Server

[Service]
ExecStart=/srv/uni/wrapper /usr/bin/unicorn -c /srv/uni/unicorn.conf.rb -d
KillSignal=SIGQUIT
KillMode=mixed

==> /etc/systemd/system/uni.socket <==
[Unit]
Description=Unicorn Socket

[Socket]
ListenStream=0.0.0.0:9000
ListenStream=0.0.0.0:9001

[Install]
WantedBy=sockets.target

Make sure to activate the systemd units:
chmod +x /srv/uni/wrapper
systemdctl daemon-reload
systemctl enable uni.socket
systemctl start  uni.socket

The application sleeps for 5secs before replying.

I run the following commands from 3 different terminals:

$ curl localhost:9000 [blocked for 5sec]
# systemctl stop uni.service [issues sigquit on the running unicorn, killing
                              the 2nd worker and waiting the 1st to finish]
$ curl localhost:9000 [blocked since there are no more workers to accept right now]

After the first request is served, unicorn dies and systemd respawns a new master.
The second request is accepted by the new master (notice the different ppid).

Some notes:

TCP socket options are not applied by unicorn on inherited sockets (TCPSocket
=== sock is false). systemd socket files have support for most options now but
we might want unicorn to `setsockopt` them as well. For example,
'DeferAcceptSec', 'KeepAliveIntervalSec', 'NoDelay' are supported since v216, so
they are not available in jessie (v215).

socket activation is a really interesting setup, but personally I would not run
it with a large application. Clients would have to wait for the new master to
be up and running before a reply is returned, and that could take tenths of
seconds. The USR2 rexec solves that problem since both old and new workers are
accepting on the socket and we can kill the old ones when we are ready. In that
case the PIDFile trick is handy to support zero downtime restarts with no
latency.

message raw reply parent threadlink

  Re: [DRE-maint] unicorn: native systemd service
  - by Eric Wong @ 06/27 03:05 UTC - next/prev

  Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
  > <On Thu, Jun 25, 2015 at 11:26:26PM +0000, Eric Wong wrote: > >With ...>
  
  OK, I'll probably add LISTEN_FDS and LISTEN_PID support to unicorn
  directly so the wrapper is unnecessary.
  
  <snip>
  
  > KillMode=mixed
  
  I don't think KillMode=mixed is necessary, here.  systemd can send
  SIGQUIT to workers.
  
  <snip>
  
  > TCP socket options are not applied by unicorn on inherited sockets (TCPSocket
  > === sock is false). systemd socket files have support for most options now but
  > we might want unicorn to `setsockopt` them as well. For example,
  > 'DeferAcceptSec', 'KeepAliveIntervalSec', 'NoDelay' are supported since v216, so
  > they are not available in jessie (v215).
  
  They are now :)
  
  http://bogomips.org/unicorn-public/m/1435373879-4299-1-git-send-email-e@80x24.org.txt
  
  We don't have KeepAliveIntervalSec
  (aka TCP_KEEPINTVL) since it's not-portable and probably over
  Are you sure about that?
  
  > socket activation is a really interesting setup, but personally I would not run
  > it with a large application. Clients would have to wait for the new master to
  > be up and running before a reply is returned, and that could take tenths of
  > seconds. The USR2 rexec solves that problem since both old and new workers are
  > accepting on the socket and we can kill the old ones when we are ready. In that
  > case the PIDFile trick is handy to support zero downtime restarts with no
  > latency.
  
  Is it possible to make systemd fire up two unicorn masters?
  That would be a nice feature to have with socket activation.

  message raw reply parent threadlink

    [RFC] emulate sd_listen_fds for systemd support
    - by Eric Wong @ 06/27 04:01 UTC - next/prev

    Unfortunately, testing this is tricky because FD=3
    (SD_LISTEN_FDS_START) tends to be grabbed by (MRI) Ruby 1.9.3
    and onwards for the internal self-pipe.
    
    So for now, I've manually tested this with a systemd installation
    
    Disclaimer: this is also my first experience using systemd

    more... raw reply parent threadlink

      Re: [RFC] emulate sd_listen_fds for systemd support
      - by Christos Trochalakis @ 06/30 08:47 UTC - next/prev

      On Sat, Jun 27, 2015 at 04:01:36AM +0000, Eric Wong wrote:
      >Unfortunately, testing this is tricky because FD=3
      >(SD_LISTEN_FDS_START) tends to be grabbed by (MRI) Ruby 1.9.3
      >and onwards for the internal self-pipe.
      >
      >So for now, I've manually tested this with a systemd installation
      >
      >Disclaimer: this is also my first experience using systemd
      >
      
      I have also tested it and works as expected. Also, hardcoding
      SD_LISTEN_FDS_START seems like the best option. I 'd like to see that
      applied to master.

      message raw reply parent threadlink

        [PATCH v2] emulate sd_listen_fds for systemd support
        - by Eric Wong @ 07/05 00:27 UTC - next/prev

        systemd socket emulation shares FDs across execve, just like
        the built-in SIGUSR2 upgrade process in unicorn.  Thus it is
        easy to support inheriting sockets from systemd.
        
        Tested-by: Christos Trochalakis <yatiohi@ideopolis.gr>

        more... raw reply parent threadlink

    Re: [DRE-maint] unicorn: native systemd service
    - by Christos Trochalakis @ 06/30 09:20 UTC - next/prev

    On Sat, Jun 27, 2015 at 03:05:01AM +0000, Eric Wong wrote:
    > <Christos Trochalakis <yatiohi@ideopolis.gr> wrote: >> On ...>
    
    Perhaps there is a race here, if a worker receives SIGQUIT first, and the
    master respawns a new worker before receiving/handling its own SIGQUIT.
    This is definitely a longshot, and will probably never happen, but
    even then every process will eventually quit gracefully.
    
    > <<snip> > >> TCP socket options are not applied by unicorn ...>
    
    I added 'KeepAliveIntervalSec' by mistake. `KeepAlive`, a supported
    option by unicorn, is included in jessie (systemd v215). Either way with
    your last patch those options are enforced by unicorn.
    
    >
    >> socket activation is a really interesting setup, but personally I would not run
    >> it with a large application. Clients would have to wait for the new master to
    >> be up and running before a reply is returned, and that could take tenths of
    >> seconds. The USR2 rexec solves that problem since both old and new workers are
    >> accepting on the socket and we can kill the old ones when we are ready. In that
    >> case the PIDFile trick is handy to support zero downtime restarts with no
    >> latency.
    >
    >Is it possible to make systemd fire up two unicorn masters?
    >That would be a nice feature to have with socket activation.
    
    That would be great! I am a bit surprised that specifying multiple
    services ('Service=' option) is not supported.

    message raw reply parent threadlink

      Re: [DRE-maint] unicorn: native systemd service
      - by Eric Wong @ 06/30 17:30 UTC - next/prev

      Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
      > On Sat, Jun 27, 2015 at 03:05:01AM +0000, Eric Wong wrote:
      > >Christos Trochalakis <yatiohi@ideopolis.gr> wrote:
      > >>KillMode=mixed
      > >
      > >I don't think KillMode=mixed is necessary, here.  systemd can send
      > >SIGQUIT to workers.
      > >
      > 
      > Perhaps there is a race here, if a worker receives SIGQUIT first, and the
      > master respawns a new worker before receiving/handling its own SIGQUIT.
      > This is definitely a longshot, and will probably never happen, but
      > even then every process will eventually quit gracefully.
      
      Right. This race is possible, but workers will automatically die if
      they don't have a master.
      Easier just to kill the master, of course.
      
      > >Is it possible to make systemd fire up two unicorn masters?
      > >That would be a nice feature to have with socket activation.
      > 
      > That would be great! I am a bit surprised that specifying multiple
      > services ('Service=' option) is not supported.
      
      Can you get this feature added to systemd?

      message raw reply parent threadlink

[PATCH] doc: update some invalid URLs
- by Eric Wong @ 06/26 00:47 UTC - next/prev

Most of these were found by the `linkchecker' package
in Debian.

more... raw reply threadlink

  TAN: Coquelicot
  - by Eric Wong @ 06/30 23:19 UTC - next/prev

  Lunar <lunar@anargeek.net> wrote:
  > Rainbows! is used by Coquelicot:
  > https://coquelicot.potager.org/
  > 
  > The project needs some love, but I know about several installations that
  > are used on a daily basis.
  
  Interesting!  I'm honestly a bit disappointed it's not a generic Rack
  app and depends on certain server features, but the project seems mostly
  inline with my interests.
  
  But if I were to run it, I'd remove all CSS+images+JS and might
  contribute a patch to disable that all, too :)
  
  Anyways, subscribed to the mailing list :>

  message raw reply parent threadlink

    Re: TAN: Coquelicot
    - by Lunar @ 07/01 11:54 UTC - next/prev

    Eric Wong:
    > Lunar <lunar@anargeek.net> wrote:
    > > Rainbows! is used by Coquelicot:
    > > https://coquelicot.potager.org/
    > > 
    > > The project needs some love, but I know about several installations that
    > > are used on a daily basis.
    > 
    > Interesting!  I'm honestly a bit disappointed it's not a generic Rack
    > app and depends on certain server features, but the project seems mostly
    > inline with my interests.
    
    In the very first versions, it was a generic Rack app. And then I
    discovered that the file that was transmitted was saved in clear before
    being given to the handler (where it would get encrypted)…
    Finding that Rainbows! could be made to process the incoming bytes
    directly really helped in fixing this issue.
    
    The choice of tying it to a single HTTP server is also a conscious
    decision to make it easy to install. On Debian, it only requires
    `apt-get install coquelicot` and then 3 lines in Apache configuration.
    
    > But if I were to run it, I'd remove all CSS+images+JS and might
    > contribute a patch to disable that all, too :)
    
    Why not. :)

    more... raw reply parent threadlink

  [ANN] unicorn 5.0.0.pre2 - another prerelease!
  - by Eric Wong @ 21:41 UTC - next/prev

  There is a minor TCP socket options are now applied to inherited
  sockets, and we have native support for inheriting sockets from
  systemd (by emulating the sd_listen_fds(3) function).
  
  Dynamic changes in the application to Rack::Utils::HTTP_STATUS
  codes is now supported, so you can use your own custom status
  lines.
  
  Ruby 2.2 and later is now favored for performance.
  Optimizations by using constants which made sense in earlier
  versions of Ruby are gone: so users of old Ruby versions
  will see performance regressions.  Ruby 2.2 users should
  see the same or better performance, and we have less code
  as a result.
  
  * doc: update some invalid URLs
  * apply TCP socket options on inherited sockets
  * reflect changes in Rack::Utils::HTTP_STATUS_CODES
  * reduce constants and optimize for Ruby 2.2
  * http_response: reduce size of multi-line header path
  * emulate sd_listen_fds for systemd support
  * test/unit/test_response.rb: compatibility with older test-unit
  
  This also includes all changes in unicorn 5.0.0.pre1:
  
  http://bogomips.org/unicorn-public/m/20150615225652.GA16164@dcvr.yhbt.net.html

  more... raw reply parent threadlink


page: next      atom permalink
- unicorn Rack HTTP server user/dev discussion
A public-inbox, anybody may post in plain-text (not HTML):
unicorn-public@bogomips.org
git URL for ssoma: git://bogomips.org/unicorn-public.git
homepage: http://unicorn.bogomips.org/
subscription optional: unicorn-public+subscribe@bogomips.org