From russm at slofith.org  Thu Sep  2 22:26:03 2010
From: russm at slofith.org (russell muetzelfeldt)
Date: Fri, 3 Sep 2010 12:26:03 +1000
Subject: access to Rainbows! config from within the application
Message-ID: <72D036D6-8B60-4CC4-A311-C6F3F56424CA@slofith.org>

Hi All,

Is there any way to read the server configuration from within the application that's being hosted?

I'm about to add a Rainbows!-hosted file upload component to an existing application. At the moment I've got duplication between the app ("Note: maximum attachment size is 200MB") and rainbows.rb ("client_max_body_size 200*1024*1024") and am wondering if there's any way for the app to know what client_max_body_size the server is configured for so I can display a human-friendly version of that on the attachment page.

(please cc: replies as I'm not subscribed to the list)


cheers

Russell


From normalperson at yhbt.net  Fri Sep  3 02:28:26 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 2 Sep 2010 23:28:26 -0700
Subject: access to Rainbows! config from within the application
In-Reply-To: <72D036D6-8B60-4CC4-A311-C6F3F56424CA@slofith.org>
References: <72D036D6-8B60-4CC4-A311-C6F3F56424CA@slofith.org>
Message-ID: <20100903062826.GA28607@dcvr.yhbt.net>

russell muetzelfeldt <russm at slofith.org> wrote:
> Hi All,
> 
> Is there any way to read the server configuration from within the
> application that's being hosted?

Hi russell,

There's no stable/official internal API, and there probably won't be.
We try not to encourage propagating new, ad-hoc standards that other
Rack servers do not support.  Sometimes it's not easy to avoid (e.g.
async.callback + EventMachine stuff), but we try.

However, since the config file is Ruby, you can always use a global
variable in your config file.

> I'm about to add a Rainbows!-hosted file upload component to an
> existing application. At the moment I've got duplication between the
> app ("Note: maximum attachment size is 200MB") and rainbows.rb
> ("client_max_body_size 200*1024*1024") and am wondering if there's any
> way for the app to know what client_max_body_size the server is
> configured for so I can display a human-friendly version of that on
> the attachment page.

So something like this:

  Rainbows! do
    client_max_body_size($client_max_body_size = 200*1024*1024)
  end

If you have more variables you want to set, I know some folks
that use a global hash object or Struct, too.

> (please cc: replies as I'm not subscribed to the list)

-- 
Eric Wong

From russm at slofith.org  Fri Sep  3 02:55:50 2010
From: russm at slofith.org (russell muetzelfeldt)
Date: Fri, 3 Sep 2010 16:55:50 +1000
Subject: access to Rainbows! config from within the application
In-Reply-To: <20100903062826.GA28607@dcvr.yhbt.net>
References: <72D036D6-8B60-4CC4-A311-C6F3F56424CA@slofith.org>
	<20100903062826.GA28607@dcvr.yhbt.net>
Message-ID: <2E490C28-2499-482B-8897-CC93DC3F3802@slofith.org>

On 03/09/2010, at 4:28 PM, Eric Wong wrote:
> russell muetzelfeldt <russm at slofith.org> wrote:
>> 
>> Is there any way to read the server configuration from within the
>> application that's being hosted?
> 
> There's no stable/official internal API, and there probably won't be.
> We try not to encourage propagating new, ad-hoc standards that other
> Rack servers do not support.

absolutely fair enough...


> So something like this:
> 
>  Rainbows! do
>    client_max_body_size($client_max_body_size = 200*1024*1024)
>  end
> 
> If you have more variables you want to set, I know some folks
> that use a global hash object or Struct, too.

ah, OK. I wasn't sure what context the Rainbows! config was evaluated in and tried

MAX_UPLOAD = 200*1024*1024
Rainbows! do
  client_max_body_size MAX_UPLOAD
end

and then referencing MAX_UPLOAD in my config.ru where app-wide stuff gets stuffed into Rack::Config but couldn't resolve that constant - rather than wading into looking at the scopes used for config evaluation I thought I'd just ask...

rather than using global vars I've packed some constants into a Config module in my app and it's all good.

thanks for the pointer!

cheers

Russell


>> (please cc: replies as I'm not subscribed to the list)

(now subscribed)


From russm at slofith.org  Thu Sep  2 23:26:52 2010
From: russm at slofith.org (russell muetzelfeldt)
Date: Fri, 3 Sep 2010 13:26:52 +1000
Subject: range requests and multipart responses
Message-ID: <DAF56675-78C6-4160-A7DD-30BD4C2ACE27@slofith.org>

On 20/07/2010, at 02:18:03 EDT, Eric Wong wrote:

> Does anybody have real-world use cases of clients using Range: requests
> with multiple comma-delimited byte ranges (and thus expecting multipart
> responses)?  If not, I'm not going to bloat Rainbows! with it for now[1].

I don't have evidence to hand, but I'm pretty sure I've seen the remote (http-served) disk image support in OSX's hdid(8) do this. Whether that's a use case you care about is another question entirely.

cheers

Russell


From me at christophsturm.com  Wed Sep 15 09:46:05 2010
From: me at christophsturm.com (Christoph Sturm)
Date: Wed, 15 Sep 2010 15:46:05 +0200
Subject: synchronous controllers taking 6 seconds in Eventmachine config
Message-ID: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>

hello rainbows friends!

we use rainbows in eventmachine mode, and it seems there's a bug in handling of synchronous responses.

this controller takes 6 seconds:

def call(env)
      Rack::Response.new.finish
end

this only occurs when i dont set a content length, for example this controller returns immedately:

def call
   [200, {'Content-Length' => 2}, ['OK']]
end

it also doesnt seem to be eventmachine specific, if i remove the use  :Eventmachine it also happens.

-chris

From normalperson at yhbt.net  Wed Sep 15 14:50:07 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 15 Sep 2010 11:50:07 -0700
Subject: synchronous controllers taking 6 seconds in Eventmachine config
In-Reply-To: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>
References: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>
Message-ID: <20100915185007.GA13709@dcvr.yhbt.net>

Christoph Sturm <me at christophsturm.com> wrote:
> hello rainbows friends!
> 
> we use rainbows in eventmachine mode, and it seems there's a bug in
> handling of synchronous responses.
> 
> this controller takes 6 seconds:
> 
> def call(env)
>       Rack::Response.new.finish
> end
> 
> this only occurs when i dont set a content length, for example this
> controller returns immedately:
> 
> def call
>    [200, {'Content-Length' => 2}, ['OK']]
> end
> 
> it also doesnt seem to be eventmachine specific, if i remove the use
> :Eventmachine it also happens.

Hi Chris, this is because the client doesn't know when to stop
reading the connection otherwise, and waits until the keepalive
timeout (5 seconds or so by default).

"Content-Length" (or "Transfer-Encoding") is required by the Rack spec,
so you need to include it in your app (or use
Rack::ContentLength and/or Rack::Chunked middlewares).

Starting with Rainbows! 0.97.0, you can set "keepalive_timeout 0" in
your Rainbows! config block to disable keepalive across all concurrency
models, which lets you violate the Rack spec and get immediate
responses.

-- 
Eric Wong

From jftucker at gmail.com  Wed Sep 15 15:30:28 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 15 Sep 2010 16:30:28 -0300
Subject: synchronous controllers taking 6 seconds in Eventmachine config
In-Reply-To: <20100915185007.GA13709@dcvr.yhbt.net>
References: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>
	<20100915185007.GA13709@dcvr.yhbt.net>
Message-ID: <97F7A036-4DA6-4CF3-B842-5870F7DE59E7@gmail.com>

Eric, you don't do actual keepalive do you, or am i thinking of unicorn?

If the request is sync, then you can close connection after body.each returns, else you need to use the deferrable api callback in deferrable bodies wiht the async api.

From normalperson at yhbt.net  Wed Sep 15 17:04:04 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 15 Sep 2010 14:04:04 -0700
Subject: synchronous controllers taking 6 seconds in Eventmachine config
In-Reply-To: <97F7A036-4DA6-4CF3-B842-5870F7DE59E7@gmail.com>
References: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>
	<20100915185007.GA13709@dcvr.yhbt.net>
	<97F7A036-4DA6-4CF3-B842-5870F7DE59E7@gmail.com>
Message-ID: <20100915210404.GA21719@dcvr.yhbt.net>

James Tucker <jftucker at gmail.com> wrote:
> Eric, you don't do actual keepalive do you, or am i thinking of
> unicorn?

Rainbows! has had keepalive and pipelining since the earliest releases
for simple GET/HEAD requests.  At least there are integration tests
using curl that do keepalive, so it should work :)  Keepalive for
proxying sockets/pipes (without async.callback) has improved with recent
releases, too.

Rainbows! will support keepalive for all other body-less requests, too,
and _maybe_ optionally supporting keepalive PUT/POST requests with a
body.  For requests with a body, the app must consume the entire body
(which intentionally does not happen for "synchronous" concurrency
models).

Unicorn doesn't do keepalive since nginx doesn't do keepalive to
backends, yet.   That will change if nginx (or another comparable
frontend emerges) supports keepalive to the backends.

> If the request is sync, then you can close connection after body.each
> returns, else you need to use the deferrable api callback in
> deferrable bodies wiht the async api.

The EM deferrable doesn't do keepalive right now, and may not ever
because (I assume) it's used for long-polling and such.

Setting "keepalive_timeout 0" for any app doing long-polling/Comet stuff
is probably a good idea anyways, the client can't reliably know which
requests take a long time.

-- 
Eric Wong

From donsmith at gmail.com  Thu Sep 16 19:12:47 2010
From: donsmith at gmail.com (Schneider ] Ben)
Date: Fri, 17 Sep 2010 07:12:47 +0800 (CST)
Subject: Healthcare, Business and Finance mailing/email lists
Message-ID: <20100916231247.BD3706D5B4@mail.stes.chc.edu.tw>

We have the following high-quality lists:

( HEALTHCARE )

- Doctors (34 different specialties)
- Chiropractors
- Alternative Medicine 
- Dentists 
- Veterinarians 
- Hospitals 
- National Health Service Corp Clinics 
- Nursing Homes 
- Pharmaceutical Companies
- Physical Therapists 
- Oncology Doctors
- US Surgery Centers
- Massage Therapists 
- Acupuncturists 
- Medical Equipment Suppliers
- Mental Health Counselors
- Visiting Nurses & RN's 
- Optometrists 
- Psychologists

( BUSINESS LISTS )

- Hotels
- Real Estate Agents 
- American Business Email List 
- US New Business Database 
- Manufacturers Database 
- Financial Planners Database 
- Finance and Money Professionals Database

( CONSUMER LISTS )

- American Consumer Database 
- Credit Inquiries Database 
- American Homeowners

( PROFESSIONALS LISTS )

- USA Lawyers Database 
- Police and Sheriff Services 
- Criminal Attorneys - 142,906 


email me here for counts & samples: qualitylists at gmx.com

  




email offthelist at gmx.com for delisting
  





From johnnyfranklin at gmail.com  Thu Sep 16 18:10:50 2010
From: johnnyfranklin at gmail.com (Shelia Mcclure)
Date: Fri, 17 Sep 2010 03:40:50 +0530 (IST)
Subject: Detailed data with many fields for businesses, healthcare and more
Message-ID: <20100916221050.5328C1D1EA5@mail.police.lk>

We have the following high-quality lists:

HEALTHCARE

> Doctors (34 different specialties)
> Chiropractors
> Alternative Medicine 
> Dentists 
> Veterinarians 
> Hospitals 
> Pharmaceutical Companies
> Physical Therapists 
> Oncology Doctors
> US Surgery Centers
> Massage Therapists 
> Acupuncturists 
> Medical Equipment Suppliers
> Mental Health Counselors
> Psychologists

BUSINESS LISTS

> Real Estate Agents 
> US New Business Database 
> Financial Planners Database 
> Finance and Money Professionals Database


PROFESSIONALS LISTS

> USA Lawyers Database 
> Criminal Attorneys - 142,906 


Send me an email here for samples and stats: qualitylists at gmx.com

  




Send us an email to offthelist at gmx.com we will discontinue from the list
  





From normalperson at yhbt.net  Fri Sep 17 05:00:27 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 17 Sep 2010 09:00:27 +0000
Subject: synchronous controllers taking 6 seconds in Eventmachine config
In-Reply-To: <20100915210404.GA21719@dcvr.yhbt.net>
References: <2B157204-E5C6-4F5D-98A9-E2A79F9F9765@christophsturm.com>
	<20100915185007.GA13709@dcvr.yhbt.net>
	<97F7A036-4DA6-4CF3-B842-5870F7DE59E7@gmail.com>
	<20100915210404.GA21719@dcvr.yhbt.net>
Message-ID: <20100917090027.GA6312@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> James Tucker <jftucker at gmail.com> wrote:
> > If the request is sync, then you can close connection after body.each
> > returns, else you need to use the deferrable api callback in
> > deferrable bodies wiht the async api.
> 
> The EM deferrable doesn't do keepalive right now, and may not ever
> because (I assume) it's used for long-polling and such.

Would supporting keepalive for people using "async.callback" help some
folks?   As of 0.97.0, it's possible to disable keepalive entirely
across all concurrency models, so perhaps allowing the app to specify
the "Connection" header is helpful, too...

-- 
Eric Wong

From normalperson at yhbt.net  Mon Sep 27 17:23:01 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 27 Sep 2010 14:23:01 -0700
Subject: [PATCH (socket_dontwait)] README: update with support status
In-Reply-To: <20100809224401.GA12996@dcvr.yhbt.net>
References: <20100803091847.GC3255@dcvr.yhbt.net>
	<20100809224401.GA12996@dcvr.yhbt.net>
Message-ID: <20100927212301.GA3531@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> Eric Wong <normalperson at yhbt.net> wrote:
> > This library is considered EXPERIMENTAL.  If successful, we'll see about
> > getting them integrated into the standard Ruby socket library.
> 
> I've been running socket_dontwait for a few days now with real traffic
> (and thus unreliable and slow clients) and haven't noticed anything
> wrong.  No crashes, corrupted data, nor fires :)

Everything is still good as long with this as long as penguins are
powering your apps :)  Maybe there are other OSes with complete
MSG_DONTWAIT support (and works with Ruby).  Let us know if there
are.

>From 53f39821dfc86c4ed4c1953249a142ae4d8ff65e Mon Sep 17 00:00:00 2001
From: Eric Wong <e at yhbt.net>
Date: Mon, 27 Sep 2010 14:16:55 -0700
Subject: [PATCH] README: update with support status

Well, the penguin rocks!
---
 README |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/README b/README
index 4dc2be9..5ba5739 100644
--- a/README
+++ b/README
@@ -10,11 +10,14 @@ from the IO class directly into BasicSocket with socket-specific system
 calls and flags.
 
 This library is only intended for Ruby 1.9 and will not build with other
-versions of Ruby.  This only supports operating systems with the
-non-POSIX MSG_DONTWAIT flag for send(2) and recv(2) syscalls.
-
-This library is considered EXPERIMENTAL.  If successful, we'll see about
-getting them integrated into the standard Ruby socket library.
+versions of Ruby.  This only supports operating systems with complete
+support of the non-POSIX MSG_DONTWAIT flag for send(2) and recv(2)
+syscalls on stream sockets.
+
+This library is fully-supported and stable on GNU/Linux 2.6+.  It is
+experimental and unsupported on other systems unless someone steps
+forward to support them.  Some operating systems have incomplete/broken
+support for the MSG_DONTWAIT flag on various types of stream sockets.
 
 == Features
 
-- 
Eric Wong

From normalperson at yhbt.net  Mon Sep 27 23:03:02 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 27 Sep 2010 20:03:02 -0700
Subject: [ANN] kgio library / RubyGem
Message-ID: <20100928030302.GA3452@dcvr.yhbt.net>

Hello all,

I've released kgio, a kinder, gentler I/O library for Ruby.  Some of its
features are useful for Unicorn, and all of it is useful for Rainbows!

I intend to make kgio a requirement for both Unicorn and
Rainbows!/Zbatery.  I'm comfortable with the code, but extra testers and
extra eyes to review it would be helpful (it's nearly all C).

There were several factors leading the creation of this library:

  1. The performance loss from Ruby 1.9.2 due to extending exceptions
     with IO::Wait{Read,Writ}able is annoying.  While it's partly
     fixed[1] and fixable[2] for 1.9.3, it could be a while before
     1.9.3 is available.  Unicorn currently does non-blocking accept
     very aggressively.

  2. (Rainbows! only) Slicing partially written strings for
     non-blocking I/O in gets painful with Ruby 1.9, it's much easier
     (at least for me) to do this in C and kgio_trywrite allows
     exactly that, returning the unwritten portion of a string.

  3. (Rainbows! only) It offers hooks for using alternative
     methods to switch execution contexts (experience taken from
     building the FiberSpawn/FiberPool modules).

  4. (philosophical) I've never considered EAGAIN/EINPROGRESS
     "exceptional" conditions when explicitly doing non-blocking
     I/O, and thus unworthy of raising exceptions.


kgio currently passes all tests on on Linux 2.6 (1.9.{1,2},
1.8.{6,7}, rbx 1.1) and FreeBSD 7.0 (1.8.7).

	http://unicorn.bogomips.org/kgio/
	git://git.bogomips.org/kgio.git
	http://git.bogomips.org/cgit/kgio.git

[1] - http://thread.gmane.org/gmane.comp.lang.ruby.core/30854
[2] - http://thread.gmane.org/gmane.comp.lang.ruby.core/31801

-- 
Eric Wong