From mperham at gmail.com  Sun May  1 00:26:32 2011
From: mperham at gmail.com (Mike Perham)
Date: Sat, 30 Apr 2011 21:26:32 -0700
Subject: problem with rainbows 3.2.0 and rbx
In-Reply-To: <20110501014703.GA16332@dcvr.yhbt.net>
References: <BANLkTimE7vo2_pRDdcVNN5vNA2fphP4-4Q@mail.gmail.com>
	<20110427175523.GA31654@dcvr.yhbt.net>
	<BANLkTikTugt46DfKVJtt3_fTm+X-j9U2Rw@mail.gmail.com>
	<20110430011926.GA15387@dcvr.yhbt.net>
	<BANLkTi=itrufRkdQsp7M5jaBS2trnm5dMQ@mail.gmail.com>
	<20110430171428.GB29282@dcvr.yhbt.net>
	<BANLkTi=t6z_5psK6AJy=XrOZmXjX0GW-pg@mail.gmail.com>
	<20110501014703.GA16332@dcvr.yhbt.net>
Message-ID: <BANLkTinReZFusAimFSF=RcPkm-1N-=Y1Sg@mail.gmail.com>

Ok, just as a note, I didn't need to use bundle exec, "rainbows"
worked just fine once it was in the Gemfile.

On Sat, Apr 30, 2011 at 6:47 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Mike Perham <mperham at gmail.com> wrote:
>> That was it. ?I added rainbows to my Gemfile and it started working.
>>
>> My app is Rails 3 and therefore uses Bundler. ?Thanks for your help!
>
> Thanks for bringing this up! ?I've added a Sandbox document to
> rainbows.git and website: http://rainbows.rubyforge.org/Sandbox.html
>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>

From normalperson at yhbt.net  Sun May  1 02:38:54 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 1 May 2011 06:38:54 +0000
Subject: problem with rainbows 3.2.0 and rbx
In-Reply-To: <BANLkTinReZFusAimFSF=RcPkm-1N-=Y1Sg@mail.gmail.com>
References: <BANLkTimE7vo2_pRDdcVNN5vNA2fphP4-4Q@mail.gmail.com>
	<20110427175523.GA31654@dcvr.yhbt.net>
	<BANLkTikTugt46DfKVJtt3_fTm+X-j9U2Rw@mail.gmail.com>
	<20110430011926.GA15387@dcvr.yhbt.net>
	<BANLkTi=itrufRkdQsp7M5jaBS2trnm5dMQ@mail.gmail.com>
	<20110430171428.GB29282@dcvr.yhbt.net>
	<BANLkTi=t6z_5psK6AJy=XrOZmXjX0GW-pg@mail.gmail.com>
	<20110501014703.GA16332@dcvr.yhbt.net>
	<BANLkTinReZFusAimFSF=RcPkm-1N-=Y1Sg@mail.gmail.com>
Message-ID: <20110501063854.GA32109@dcvr.yhbt.net>

Mike Perham <mperham at gmail.com> wrote:
> Ok, just as a note, I didn't need to use bundle exec, "rainbows"
> worked just fine once it was in the Gemfile.

That's dangerous if the bundled Rainbows! install is a different version
than your non-bundled one.  You could end up in a situation where you
have loaded files across both versions of Rainbows!, definitely not
supported :)

-- 
Eric Wong

From mperham at gmail.com  Sun May  1 16:52:04 2011
From: mperham at gmail.com (Mike Perham)
Date: Sun, 1 May 2011 13:52:04 -0700
Subject: graceful shutdown
Message-ID: <BANLkTimZtpKWjyRa0M9habiw1npXdMkUBQ@mail.gmail.com>

I've got a multithreaded system, some threads are responding to web
requests, others are performing background/async tasks.  Is there any
way to implement graceful shutdown with Rainbows?  Currently I have a
blocking SIGQUIT shutdown hook for my async task library:

https://github.com/mperham/girl_friday/blob/master/lib/girl_friday.rb#L55

Will this work? Is this all that's really needed?

From normalperson at yhbt.net  Sun May  1 17:51:36 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 1 May 2011 21:51:36 +0000
Subject: graceful shutdown
In-Reply-To: <BANLkTimZtpKWjyRa0M9habiw1npXdMkUBQ@mail.gmail.com>
References: <BANLkTimZtpKWjyRa0M9habiw1npXdMkUBQ@mail.gmail.com>
Message-ID: <20110501215136.GC13274@dcvr.yhbt.net>

Mike Perham <mperham at gmail.com> wrote:
> I've got a multithreaded system, some threads are responding to web
> requests, others are performing background/async tasks.  Is there any
> way to implement graceful shutdown with Rainbows?  Currently I have a
> blocking SIGQUIT shutdown hook for my async task library:
> 
> https://github.com/mperham/girl_friday/blob/master/lib/girl_friday.rb#L55
> 
> Will this work? Is this all that's really needed?

No, install an at_exit block instead.

Rainbows! itself relies on SIGQUIT for graceful shutdown, so your trap
would conflict with that.

There are some caveats since Rainbows! won't wait forever for graceful
shutdowns, either.

The Unicorn/Rainbows! master process defaults the "timeout"[1] parameter
to 60s.  If an at_exit handler takes a long time, increase the "timeout"
directive.

The "timeout" directive affects how long the master process will wait
for a worker process to gracefully exit after a SIQQUIT is sent.  If the
timeout expires after SIGQUIT, the master will assume the worker is
non-responsive/stuck and send a SIGKILL to finish the worker off.

By definition of a graceful shutdown, Rainbows! will also try to wait
until all currently running requests are complete, too[2].  Having a
long keepalive_timeout (default is only 5s) also affects the time it
takes to shutdown[3].


[1] http://unicorn.bogomips.org/Unicorn/Configurator.html#method-i-timeout
[2] this is a huge pain for infinite endpoints like
    http://raindrops-demo.bogomips.org/tail/0.0.0.0%3A80.txt :<
[3] It's not consistent across concurrency options right now and
    not easy to fix consistently.

-- 
Eric Wong

From normalperson at yhbt.net  Mon May  2 21:47:22 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 3 May 2011 01:47:22 +0000
Subject: client_header_buffer_size tuning in rainbows.git
Message-ID: <20110503014722.GA21232@dcvr.yhbt.net>

This will be in the next release.

It mainly affects Thread/Actor/Fiber-based concurrency models since
those have an independent (userspace) buffer for client headers.

The default is now only 1K (matching nginx) whereas the previous
hardcoded value was 16K.  If it can't fit in 1K, it'll read again
and append to the previous 1K buffer, and so on...[1]

Lowering header buffer sizes lowers memory usage for sites with many
idle connections.  With only 1000 clients, header buffers alone would be
16M in memory usage, 10K clients => 160M.  If new clients frequently
connect, this will put more pressure on GC to run.

Typical HTTP header sizes[2] are smaller than 1K.  Most Rails sites use
larger headers because the sessions are stored in a cookie, so they end
up being in the 1K - 2K range from some quick investigations I did.


== Rails cookie sessions users:

This may cause more recv(2)/read(2) syscalls per request.  If this
syscall is measurable overhead (I doubt it is), increase
client_header_buffer_size to what your expected session cookie payload
to be.

== Unicorn

Unicorn is much simpler since it only has one client to worry about.
Unicorn allocates one 16K buffer and never releases/shrinks it for
the duration of the process (though it can grow up to 112K)[1].



Thanks for reading!

[1] There's a hard-coded limit of 112K to prevent DoS in the
    Mongrel/Unicorn parser.

[2] search the web, some sites have done research on them

-- 
Eric Wong

From normalperson at yhbt.net  Thu May  5 15:48:33 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 5 May 2011 12:48:33 -0700
Subject: kgio 2.4.0 coming soon
Message-ID: <20110505194833.GB29336@dcvr.yhbt.net>

The I/O library used by the latest version Unicorn/Rainbows! got some
OpenBSD portability fixes thanks to Jeremy Evans.  Users of the latest
Rainbows!/Unicorn versions should just be able to update kgio
independently and be on their way if they need OpenBSD fixes.

Summary of changes and reasoning here:

  http://mid.gmane.org/20110505194305.GA29336 at dcvr.yhbt.net

Feel free to comment on kgio at librelist.com[1], reply here, or email me
privately if you're shy.

[1] subscription is required there unfortunately, send a message and
    follow directions to subscribe

-- 
Eric Wong

From normalperson at yhbt.net  Thu May  5 19:34:21 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 5 May 2011 23:34:21 +0000
Subject: [ANN] kgio 2.4.0 released
In-Reply-To: <20110505194833.GB29336@dcvr.yhbt.net>
References: <20110505194833.GB29336@dcvr.yhbt.net>
Message-ID: <20110505233421.GA4358@dcvr.yhbt.net>

http://mid.gmane.org/20110505231506.GA3810 at dcvr.yhbt.net

OpenBSD (and other *BSD) users should upgrade if you haven't
been able to use the latest releases.

-- 
Eric Wong

From normalperson at yhbt.net  Tue May 10 18:07:15 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 10 May 2011 15:07:15 -0700
Subject: adding GPLv3 to license
Message-ID: <20110510220715.GA8949@dcvr.yhbt.net>

I'm going to add GPLv3 to the Rainbows! license so it'll be changed
from: Ruby terms + GPLv2
  to: Ruby terms + GPLv2 + GPLv3

This will eventually allow Rainbows! to be combined and distributed with
GPLv3-only and AGPLv3 packages without a potential license conflict.

I'm also reserving the ability to add future versions of the GPL (as
published by the Free Software Foundation) to the license.  I will not
be have a "GPLv2 or later" clause since I don't want the FSF to upgrade
the license without my review.  Even though I like the AGPL for web
/applications/, I don't think it's appropriate for infrastructure such
as Rainbows!.

Graham (Cc-ed) is the only contributor to Rainbows! other than myself,
and his patch[1] was only trivial bugfix which shouldn't prevent me
from making a minor change to the license.

Rainbows! depends on Unicorn, and Unicorn (and Mongrel) has more
contributors and thus harder to add the GPLv3 to...

[1] bogomips.org/rainbows.git/patch?id=a34b1048d05397f72ad579fcef72cbb1a9e9d8bc

-- 
Eric Wong

From vcledera at rot.ch  Sun May 15 18:02:47 2011
From: vcledera at rot.ch (Win)
Date: Mon, 16 May 2011 00:02:47 +0200
Subject: Only most excellent blue-wondermeds here!
Message-ID: <002801cc1344$39b4b5f0$48c9713b@atplfs1ivzs0uoftxbuf>

Dream to act like a porndirector? Take a blue pil! 
http://shaunlawrence.com/xsuehwkb.html


From normalperson at yhbt.net  Mon May 16 18:14:31 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 16 May 2011 22:14:31 +0000
Subject: [ANN] Rainbows! 3.3.0 - doc improvements and more
Message-ID: <20110516221431.GA25625@dcvr.yhbt.net>

Changes:

* improved documentation all around, suggestions/comments to further
  improve documentation is greatly welcome at: rainbows-talk at rubyforge.org

* added GPLv3 option to the license (now (Ruby|GPLv2|GPLv3), though
  Unicorn is still (Ruby|GPLv2) for now)

* added client_header_buffer_size config directive (default 1K)

* small default header buffer size (16K => 1K) to reduce memory usage,
  Rails apps with cookie sessions may want to increase this (~2K)

* all concurrency models default to 50 connections per process

* all concurrency models with a secondary :pool_size parameter also
  default to 50 (threads/fibers/whatever)

* RLIMIT_NOFILE and RLIMIT_NPROC are automatically increased if needed

* Rainbows::ThreadTimeout middleware rewritten, still not recommended,
  lazy people should be using Unicorn anyways :)

* Several experimental Linux-only edge-triggered epoll options:
  XEpollThreadSpawn, XEpollThreadPool, XEpoll, and Epoll.
  The latter two were in previous releases but never announced.
  These require the "sleepy_penguin", "raindrops", and "sendfile" RubyGems

=== Deprecations

* Rainbows::Fiber::IO* APIs all deprecated, Rainbows! will avoid
  having any concurrency model-specific APIs in the future and
  also avoid introducing new APIs for applications.

* Fiber-based concurrency models are no longer recommended, they're
  too fragile for most apps, use at your own risk (they'll continue to
  be supported, however).  Linux NPTL + Ruby 1.9 is pretty lightweight
  and will be even lighter in Ruby 1.9.3 if you're careful with stack
  usage in your C extensions.

* http://rainbows.rubyforge.org/
* rainbows-talk at rubyforge.org
* git://bogomips.org/rainbows.git

-- 
Eric Wong

From normalperson at yhbt.net  Mon May 16 18:20:05 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 16 May 2011 22:20:05 +0000
Subject: [ANN] Zbatery 3.3.0 - Rainbows! 3.3.0 resync
In-Reply-To: <20110516221431.GA25625@dcvr.yhbt.net>
References: <20110516221431.GA25625@dcvr.yhbt.net>
Message-ID: <20110516222005.GB25855@dcvr.yhbt.net>

Changes:

Like Rainbows! 3.3.0, we've added the GPLv3 to our license
(in addition to GPLv2 and Ruby terms).  See Rainbows! 3.3.0
release notes and news for more infor on changes:

http://rainbows.rubyforge.org/NEWS.html

* http://zbatery.bogomip.org/
* rainbows-talk at rubyforge.org
* git://bogomips.org/zbatery.git

-- 
Eric Wong

From normalperson at yhbt.net  Tue May 17 20:43:59 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 17 May 2011 17:43:59 -0700
Subject: [PATCH] doc: recommend io_splice 4.1.1 or later
Message-ID: <20110518004359.GA21599@dcvr.yhbt.net>

I just pushed this out to rainbows.git and updated the website:

>From 5e4f790847198e1267b2fbd5decfa09e5cc3d618 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson at yhbt.net>
Date: Tue, 17 May 2011 17:38:12 -0700
Subject: [PATCH] doc: recommend io_splice 4.1.1 or later

io_splice 4.1.1 works around issues with socket
buffers filling up pipe buffers on blocking splice.

See http://lkml.org/lkml/2009/1/13/478 for a better
explanation.
---
 lib/rainbows/configurator.rb |    4 +++-
 t/test_isolate.rb            |    2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/rainbows/configurator.rb b/lib/rainbows/configurator.rb
index a1d90cb..1b93fc7 100644
--- a/lib/rainbows/configurator.rb
+++ b/lib/rainbows/configurator.rb
@@ -190,7 +190,9 @@ module Rainbows::Configurator
   #   end
   #
   # Keep in mind that splice(2) itself is a relatively new system call
-  # and has been buggy in many older Linux kernels.
+  # and has been buggy in many older Linux kernels.  If you're proxying
+  # the output of sockets to the client, be sure to use "io_splice"
+  # 4.1.1 or later to avoid stalling responses.
   #
   # Default: IO on Ruby 1.9+, false otherwise
   def copy_stream(klass)
diff --git a/t/test_isolate.rb b/t/test_isolate.rb
index fe2aebc..562f1b6 100644
--- a/t/test_isolate.rb
+++ b/t/test_isolate.rb
@@ -41,7 +41,7 @@ Isolate.now!(opts) do
     gem 'sleepy_penguin', '2.0.0'
 
     # is 2.6.32 new enough?
-    gem 'io_splice', '4.1.0' if `uname -r`.strip > '2.6.32'
+    gem 'io_splice', '4.1.1' if `uname -r`.strip > '2.6.32'
   end
 end
 
-- 
Eric Wong

From igor.zaoutined at qualton.com  Fri May 20 01:37:16 2011
From: igor.zaoutined at qualton.com (Sarah)
Date: Fri, 20 May 2011 05:37:16 -0000
Subject: Dream to act like a pornstar? Take a blue med!
Message-ID: <001a01cc0224$5348a610$22a27238@Brunolgtzx>

Best xxx-life booster. http://getmeeven.com/jajwngrf.html


From normalperson at yhbt.net  Fri May 20 15:16:55 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 20 May 2011 19:16:55 +0000
Subject: updates in git://bogomips.org/rainbows.git
Message-ID: <20110520191655.GA11860@dcvr.yhbt.net>

== dropping keepalive clients on SIGQUIT

For all concurrency models where we manage idle keepalive ourselves
(anything using Cool.io or sleepy_penguin[1] epoll), SIGQUIT should drop
idle clients immediately.  These are some of the concurrency models
where maintaining keepalive clients is cheapest.

It would require more time/effort to get this working with EventMachine
(since we just rely on set_comm_inactivity_timeout in EventMachine).
Anybody really care about it?

I noticed SIGQUIT was taking a long time to take effect with long
keepalives while testing XEpoll somewhere...


== Kgio.autopush support for Thread-based concurrency models

I forgot to switch from IO#write to Kgio::SocketMethods#kgio_write.  The
latter is is needed to push pending frames if :tcp_nopush is true on a
listen socket.  This wasn't an issue for other concurrency models that
already used kgio_write/kgio_trywrite.  Most people don't use
:tcp_nopush, so this doesn't concern them, but I was testing with
:ThreadPool.

Unconfirmed, but if you're serving HTTP/0.9 clients, this may still have
adverse affect if you use sendfile/IO.copy_stream.   I'll report back
since there are probably Rainbows! users that depend heavily on HTTP/0.9
support :)


I've not written tests for either of these improvements, but will
do so before the 3.4.0 release.

[1] http://bogomips.org/sleepy_penguin/

-- 
Eric Wong

From normalperson at yhbt.net  Fri May 20 17:04:37 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 20 May 2011 14:04:37 -0700
Subject: updates in git://bogomips.org/rainbows.git
In-Reply-To: <20110520191655.GA11860@dcvr.yhbt.net>
References: <20110520191655.GA11860@dcvr.yhbt.net>
Message-ID: <20110520210437.GA17040@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> == dropping keepalive clients on SIGQUIT
> 
> It would require more time/effort to get this working with EventMachine
> (since we just rely on set_comm_inactivity_timeout in EventMachine).
> Anybody really care about it?

Actually, it's quick for EM (within 1s) and now even quicker:

diff --git a/lib/rainbows/event_machine.rb b/lib/rainbows/event_machine.rb
index b136518..025b795 100644
--- a/lib/rainbows/event_machine.rb
+++ b/lib/rainbows/event_machine.rb
@@ -74,11 +74,11 @@ module Rainbows::EventMachine
       conns = EM.instance_variable_get(:@conns) or
         raise RuntimeError, "EM @conns instance variable not accessible!"
       Rainbows::EventMachine::Server.const_set(:CUR, conns)
+      Rainbows.at_quit do
+        EM.next_tick { conns.each_value { |c| client_class === c and c.quit } }
+      end
       EM.add_periodic_timer(1) do
-        unless Rainbows.tick
-          conns.each_value { |c| client_class === c and c.quit }
-          EM.stop if conns.empty? && EM.reactor_running?
-        end
+        EM.stop if ! Rainbows.tick && conns.empty? && EM.reactor_running?
       end
       LISTENERS.map! do |s|
         EM.watch(s, Rainbows::EventMachine::Server) do |c|

---

Longer term, I'd like to lower the tick frequency to save power, but
it's not going to be useful for MRI 1.9.x as long as the timer thread is
waking up every 10ms
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/33456)

-- 
Eric Wong

From normalperson at yhbt.net  Fri May 20 18:25:59 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 20 May 2011 15:25:59 -0700
Subject: updates in git://bogomips.org/rainbows.git
In-Reply-To: <20110520191655.GA11860@dcvr.yhbt.net>
References: <20110520191655.GA11860@dcvr.yhbt.net>
Message-ID: <20110520222559.GA11952@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> == Kgio.autopush support for Thread-based concurrency models

<snip>

> Unconfirmed, but if you're serving HTTP/0.9 clients, this may still have
> adverse affect if you use sendfile/IO.copy_stream.   I'll report back
> since there are probably Rainbows! users that depend heavily on HTTP/0.9
> support :)

Of course Rainbows! will disconnect HTTP/0.9 (and 1.0) clients immediately
after writing the response, so they'll be uncorked + flushed then.

-- 
Eric Wong

From normalperson at yhbt.net  Fri May 20 23:23:58 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 21 May 2011 03:23:58 +0000
Subject: [ANN] Rainbows! 3.4.0 - minor updates and fixes
Message-ID: <20110521032358.GA23944@dcvr.yhbt.net>

Changes:

SIGQUIT (graceful shutdown) now drops idle keepalive clients for
the concurrency models where maintaining an idle client is
relatively inexpensive: Coolio, CoolioThreadPool,
CoolioThreadSpawn, Epoll, EventMachine, XEpoll,
XEpollThreadPool, XEpollThreadSpawn.

Kgio.autopush now works properly for all multi-threaded
concurrency models (if you're using :tcp_nopush).

* http://rainbows.rubyforge.org/
* rainbows-talk at rubyforge.org
* git://bogomips.org/rainbows.git

-- 
Eric Wong

From wantgapas38aashen at yahoo.com  Sun May 22 03:18:28 2011
From: wantgapas38aashen at yahoo.com (Rick)
Date: Sun, 22 May 2011 15:18:28 +0800
Subject: =?GB2312?B?RGlnaXRhbCBQaG90byBFZGl0aW5nIFNlcg==?=
	=?GB2312?B?dmljZXMgLSBQaG90byBDdXRvdXQgU2Vydg==?= =?GB2312?B?aWNl?=
Message-ID: <mailman.0.1306049314.1867.rainbows-talk@rubyforge.org>

You are receiving this email because we wish you to use our digital photo editing services.

Digital Photo Editing Services :

We are a China based Imaging Professionals. We offer basic and advanced digital photo Editing services and solutions like photo Cutout, morphological photo Editing, photoshop photo Editing, satellite photo Editing, color photo Editing and vector photo Editing using latest techniques. 

Our strength in providing Editing solutions for digital images like photo masking, photo re-touching, back ground cleaning & cloning, sharpening & restoration of color, all this derive from our vast experience. Our dedicated team of highly skilled and experienced professionals serves the photo Editing requirements of our clients. An in house quality checking mechanism assures value addition and delivers perfect job. Our team can deliver your job overnight or in time bounded fashion irrespective of job size. 

Our mainly services are: 

1. Photo Cutout
2. Photo Enhancement
3. Photo Retouching
4. Vector Conversion
5. Pop Art
6. Images Masking
7. Clipping Path
8. Photo Restoration 
9. Web Design

Photo Editing Services:

Our Photo Editing services includes advanced photo cutouts/clippings, balancing brightness / contrast in an image, repair of minor scratches, creases, minor dust, and spot removal to removal of major scratches, cracks, creases, and stains in all areas. We also repair seriously faded/damaged photographs and make it print ready.

Best regards,
Rick
Rickurason Imaging Professionals
Contact: rickcontact at yeah.net



























Send address to koremovrick at yeah.net for remove