From john201012 at mail2.delphinusworld.com  Tue Nov  2 14:35:06 2010
From: john201012 at mail2.delphinusworld.com (impulse Stanford)
Date: Tue,  2 Nov 2010 13:35:06 -0500 (CDT)
Subject: Contact info including email and phone for businesses, medical,
	professionals and more
Message-ID: <20101102183506.C2D742EDF0@mail.delphinusworld.com>

Pricing for this week only: ANY 1 list $99 or 3 for $249. Choose from the lists below:

( 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 


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

  




to get off please email purgefile at gmx.com
  





From eodbat at gmail.com  Wed Nov  3 06:40:24 2010
From: eodbat at gmail.com (Edoardo Batini)
Date: Wed, 3 Nov 2010 11:40:24 +0100
Subject: Unicorn Bug tracking?
Message-ID: <20101103104024.GA2831@krtek>

Hi,
is there a bug tracking system for unicorn? And if not why?

:)
edoardo

From normalperson at yhbt.net  Wed Nov  3 22:31:32 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 3 Nov 2010 19:31:32 -0700
Subject: Unicorn Bug tracking?
In-Reply-To: <20101103104024.GA2831@krtek>
References: <20101103104024.GA2831@krtek>
Message-ID: <20101104023132.GA30783@dcvr.yhbt.net>

Edoardo Batini <eodbat at gmail.com> wrote:
> Hi,
> is there a bug tracking system for unicorn? And if not why?

Hi Edoardo,

The mailing list is the bug tracking system for this project.  Feel free
to report/ask anything via email (respecting traditional technical
mailing list rules: text-only, no top-posting, quote only what you reply
to).

Despite this being a web server project, I (the project leader) strongly
dislike dealing with HTML <form> elements and interactive web interfaces
in general.

-- 
Eric Wong

From stoves-bounces at listserv.repp.org  Sun Nov  7 19:17:03 2010
From: stoves-bounces at listserv.repp.org (stoves-bounces at listserv.repp.org)
Date: Sun, 07 Nov 2010 16:17:03 -0800
Subject: Auto-response for your message to the "Stoves" mailing list
Message-ID: <mailman.1611.1289175423.19680.stoves_listserv.repp.org@listserv.repp.org>

The Stoves list has moved to stoves at lists.bioenerglists.org - please
update your email contacts to reflect the change. 

Please visit BioEnergy Discussion Lists
http://info.bioenergylists.org/ Thank you, Stoves Administrator

From fullofcaffeine at gmail.com  Tue Nov  9 12:57:26 2010
From: fullofcaffeine at gmail.com (Marcelo de Moraes Serpa)
Date: Tue, 9 Nov 2010 17:57:26 +0000 (UTC)
Subject: AMQP and Unicorn (mq gem)
Message-ID: <loom.20101109T184430-639@post.gmane.org>

Hi all,

I'm having issues with Unicorn and connecting to 
RabbitMQ using the tmm1-amqp gem.

 I've tried lots of  approaches.

The classic initializer with Thread.new { EM.run } 
for the Rails app and even tried using 
the Qusion library. 

 (https://github.com/danielsdeleo/qusion)

I've made a simple mod to Qusion for it to monkey patch 
unicorn too. 

The code looks like:

/vendor/plugins/qusion/lib/amqp.rb

module AMQP
  def self.start_web_dispatcher(amqp_settings={})
    @settings = settings.merge(amqp_settings)
    case Qusion::ServerSpy.server_type
    when :passenger
      PhusionPassenger.on_event(:starting_worker_process) do |forked| 
        if forked
          EM.kill_reactor
          Thread.current[:mq], @conn = nil, nil
        end 
        Thread.new { start }
        die_gracefully_on_signal
      end
    when :standard
      Thread.new { start }
      die_gracefully_on_signal
    when :evented
      die_gracefully_on_signal
    when :none # << HERE
      Thread.new { start }
      die_gracefully_on_signal
    else
      raise ArgumentError, "AMQP#start_web_dispatcher
 requires an argument of 
[:standard|:evented|:passenger|:none]"
    end
  end
  
  def self.die_gracefully_on_signal
    Signal.trap("INT")  { AMQP.stop { EM.stop } }
    Signal.trap("TERM") { AMQP.stop { EM.stop } }
  end
end

See the :none case? It used to be empty and return nil. 

Now it has the same behavior as the non-
evented :standard server. 

The problem is that the "server_spy" wasn't 
recognizing Unicorn. So far so 
good.

Originally, the AMQP/Qusion conf goes into config/environment.rb

   config.after_initialize do
      
      Qusion.start(:user => 'guest',:pass => 'mypass') 
 end


However, when I publish messages to the queue,
 it just isn't posted. It silently fails. 

I've then tried to put this on config/unicorn.rb:

before_fork do |server,worker|
 Qusion.start(:user => 'guest',:pass => 'mypass')
 MQ.new.queue('jobs').publish('hey!')
end

And the hey! message is posted. 

However, it only works from here, the MQ.new.queue on the app code 
fails silently.

Any ideas on what might be happenig?





From normalperson at yhbt.net  Tue Nov  9 19:55:06 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Wed, 10 Nov 2010 08:55:06 +0800
Subject: AMQP and Unicorn (mq gem)
In-Reply-To: <loom.20101109T184430-639@post.gmane.org>
References: <loom.20101109T184430-639@post.gmane.org>
Message-ID: <20101110005506.GA25886@dcvr.yhbt.net>

Marcelo de Moraes Serpa <fullofcaffeine at gmail.com> wrote:
> Hi all,
> 
> I'm having issues with Unicorn and connecting to 
> RabbitMQ using the tmm1-amqp gem.
> 
>  I've tried lots of  approaches.
> 
> The classic initializer with Thread.new { EM.run } 
> for the Rails app and even tried using 
> the Qusion library. 
> 
>  (https://github.com/danielsdeleo/qusion)
> 
> I've made a simple mod to Qusion for it to monkey patch 
> unicorn too. 
> 
> The code looks like:
> 
> /vendor/plugins/qusion/lib/amqp.rb
> 
> module AMQP
>   def self.start_web_dispatcher(amqp_settings={})
>     @settings = settings.merge(amqp_settings)
>     case Qusion::ServerSpy.server_type
>     when :passenger
>       PhusionPassenger.on_event(:starting_worker_process) do |forked| 

<side note>maybe adding a similar hook to Unicorn for library/app authors
to use would be a good idea.</side note>

>         if forked
>           EM.kill_reactor
>           Thread.current[:mq], @conn = nil, nil
>         end 
>         Thread.new { start }
>         die_gracefully_on_signal
>       end
>     when :standard
>       Thread.new { start }
>       die_gracefully_on_signal
>     when :evented
>       die_gracefully_on_signal
>     when :none # << HERE
>       Thread.new { start }
>       die_gracefully_on_signal
>     else
>       raise ArgumentError, "AMQP#start_web_dispatcher
>  requires an argument of 
> [:standard|:evented|:passenger|:none]"
>     end
>   end
>   
>   def self.die_gracefully_on_signal
>     Signal.trap("INT")  { AMQP.stop { EM.stop } }
>     Signal.trap("TERM") { AMQP.stop { EM.stop } }
>   end

Registering a standard at_exit {} block in the Unicorn
after_fork hook would be a good idea than trapping INT
and TERM, which Unicorn uses.

> end
> 
> See the :none case? It used to be empty and return nil. 
> 
> Now it has the same behavior as the non-
> evented :standard server. 
> 
> The problem is that the "server_spy" wasn't 
> recognizing Unicorn. So far so 
> good.
> 
> Originally, the AMQP/Qusion conf goes into config/environment.rb
> 
>    config.after_initialize do
>       
>       Qusion.start(:user => 'guest',:pass => 'mypass') 
>  end
> 
> 
> However, when I publish messages to the queue,
>  it just isn't posted. It silently fails. 
> 
> I've then tried to put this on config/unicorn.rb:
> 
> before_fork do |server,worker|
>  Qusion.start(:user => 'guest',:pass => 'mypass')
>  MQ.new.queue('jobs').publish('hey!')
> end
> 
> And the hey! message is posted. 
> 
> However, it only works from here, the MQ.new.queue on the app code 
> fails silently.
> 
> Any ideas on what might be happenig?

Is preload_app true?  Then you're probably trying to share sockets
across processes and confusing EM or AMQP.

Instead of using before_fork above, you should probably
be using after_fork:

  before_fork do |server,worker|
    Qusion.start(:user => 'guest',:pass => 'mypass')
    MQ.new.queue('jobs').publish('hey!')
  end

I'm not very familiar with AMQP, but the Unicorn process is strictly an
AMQP sender/client and doesn't listen as a server on a port, right?
If so, the above before_fork config *should* work for you.

Let us know how it goes!

-- 
Eric Wong

From jpr5 at darkridge.com  Tue Nov  9 21:11:22 2010
From: jpr5 at darkridge.com (Jordan Ritter)
Date: Tue, 9 Nov 2010 18:11:22 -0800
Subject: AMQP and Unicorn (mq gem)
In-Reply-To: <20101110005506.GA25886@dcvr.yhbt.net>
References: <loom.20101109T184430-639@post.gmane.org>
	<20101110005506.GA25886@dcvr.yhbt.net>
Message-ID: <107ABCC5-565C-4C8D-9116-C7EF7D4E2AD0@darkridge.com>

We use unicorn + sinatra + tmm1/amqp, and I can say for a fact that you must initialize the AMQP connection in after_fork.  Eric is probably right about the fd sharing from before_fork.

In the rails-specific context, if preload_app is true, it's possible that using config.after_initialize {} will still result in the AMQP initialization occurring before the fork.

cheers,
--jordan


On Nov 9, 2010, at 4:55 PM, Eric Wong wrote:

> Marcelo de Moraes Serpa <fullofcaffeine at gmail.com> wrote:
>> Hi all,
>> 
>> I'm having issues with Unicorn and connecting to 
>> RabbitMQ using the tmm1-amqp gem.
>> 
>> I've tried lots of  approaches.
>> 
>> The classic initializer with Thread.new { EM.run } 
>> for the Rails app and even tried using 
>> the Qusion library. 
>> 
>> (https://github.com/danielsdeleo/qusion)
>> 
>> I've made a simple mod to Qusion for it to monkey patch 
>> unicorn too. 
>> 
>> The code looks like:
>> 
>> /vendor/plugins/qusion/lib/amqp.rb
>> 
>> module AMQP
>>  def self.start_web_dispatcher(amqp_settings={})
>>    @settings = settings.merge(amqp_settings)
>>    case Qusion::ServerSpy.server_type
>>    when :passenger
>>      PhusionPassenger.on_event(:starting_worker_process) do |forked| 
> 
> <side note>maybe adding a similar hook to Unicorn for library/app authors
> to use would be a good idea.</side note>
> 
>>        if forked
>>          EM.kill_reactor
>>          Thread.current[:mq], @conn = nil, nil
>>        end 
>>        Thread.new { start }
>>        die_gracefully_on_signal
>>      end
>>    when :standard
>>      Thread.new { start }
>>      die_gracefully_on_signal
>>    when :evented
>>      die_gracefully_on_signal
>>    when :none # << HERE
>>      Thread.new { start }
>>      die_gracefully_on_signal
>>    else
>>      raise ArgumentError, "AMQP#start_web_dispatcher
>> requires an argument of 
>> [:standard|:evented|:passenger|:none]"
>>    end
>>  end
>> 
>>  def self.die_gracefully_on_signal
>>    Signal.trap("INT")  { AMQP.stop { EM.stop } }
>>    Signal.trap("TERM") { AMQP.stop { EM.stop } }
>>  end
> 
> Registering a standard at_exit {} block in the Unicorn
> after_fork hook would be a good idea than trapping INT
> and TERM, which Unicorn uses.
> 
>> end
>> 
>> See the :none case? It used to be empty and return nil. 
>> 
>> Now it has the same behavior as the non-
>> evented :standard server. 
>> 
>> The problem is that the "server_spy" wasn't 
>> recognizing Unicorn. So far so 
>> good.
>> 
>> Originally, the AMQP/Qusion conf goes into config/environment.rb
>> 
>>   config.after_initialize do
>> 
>>      Qusion.start(:user => 'guest',:pass => 'mypass') 
>> end
>> 
>> 
>> However, when I publish messages to the queue,
>> it just isn't posted. It silently fails. 
>> 
>> I've then tried to put this on config/unicorn.rb:
>> 
>> before_fork do |server,worker|
>> Qusion.start(:user => 'guest',:pass => 'mypass')
>> MQ.new.queue('jobs').publish('hey!')
>> end
>> 
>> And the hey! message is posted. 
>> 
>> However, it only works from here, the MQ.new.queue on the app code 
>> fails silently.
>> 
>> Any ideas on what might be happenig?
> 
> Is preload_app true?  Then you're probably trying to share sockets
> across processes and confusing EM or AMQP.
> 
> Instead of using before_fork above, you should probably
> be using after_fork:
> 
>  before_fork do |server,worker|
>    Qusion.start(:user => 'guest',:pass => 'mypass')
>    MQ.new.queue('jobs').publish('hey!')
>  end
> 
> I'm not very familiar with AMQP, but the Unicorn process is strictly an
> AMQP sender/client and doesn't listen as a server on a port, right?
> If so, the above before_fork config *should* work for you.
> 
> Let us know how it goes!


From heffergm at me.com  Fri Nov 12 15:51:04 2010
From: heffergm at me.com (Grant Heffernan)
Date: Fri, 12 Nov 2010 15:51:04 -0500
Subject: error when HUP'ing unicorn
Message-ID: <1113C85A-16C6-4197-B0C3-29F89B506E17@me.com>

Anyone come across this one before?

Refreshing Gem list
error reloading config_file=/data/servers/patch-fe-apache/conf/unicorn.rb: TypeError can't convert Hash into Integer /opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:89:in `read'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:89:in `load_specification'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:153:in `load_gems_in'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:152:in `each'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:152:in `load_gems_in'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:149:in `reverse_each'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:149:in `load_gems_in'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:345:in `refresh!'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/rails-2.3.4/lib/rails/vendor_gem_source_index.rb:34:in `refresh!'/opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems.rb:746:in `refresh'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/unicorn-2.0.0/lib/unicorn/http_server.rb:673:in `build_app!'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/unicorn-2.0.0/lib/unicorn/http_server.rb:656:in `load_config!'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/unicorn-2.0.0/lib/unicorn/http_server.rb:330:in `join'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/unicorn-2.0.0/lib/unicorn.rb:13:in `run'/opt/bcs/packages/ruby-1.8.6/lib/ruby/gems/1.8/gems/unicorn-2.0.0/bin/unicorn_rails:208/opt/bcs/packages/ruby/bin/unicorn_rails:19:in `load'/opt/bcs/packages/ruby/bin/unicorn_rails:19


It appears our app isn't restarting when issuing a HUP, and I'm suspecting the above as the culprit. Unicorn restarts all workers without issue (other than the above error).


This is our basic config:

# Sample verbose configuration file for Unicorn (not Rack)
#
# This configuration file documents many features of Unicorn
# that may not be needed for some applications. See
# http://unicorn.bogomips.org/examples/unicorn.conf.minimal.rb
# for a much simpler configuration file.
#
# See http://unicorn.bogomips.org/Unicorn/Configurator.html for complete
# documentation.

# Use at least one worker per core if you're on a dedicated server,
# more will usually help for _short_ waits on databases/caches.
worker_processes 30

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/data/servers/app/current"

# listen on both a Unix domain socket and a TCP port,
# we use a shorter backlog for quicker failover when busy
#listen "/data/servers/patch-fe-apache/logs/.unicorn_sock", :backlog => 64
listen 8080

# nuke workers after 30 seconds instead of 60 seconds (the default)
timeout 30

# feel free to point this anywhere accessible on the filesystem
pid "/data/servers/app/logs/unicorn.pid"

# By default, the Unicorn logger will write to stderr.
# Additionally, ome applications/frameworks log to stderr or stdout,
# so prevent them from going to /dev/null when daemonized here:
stderr_path "/data/servers/app/logs/unicorn_error.log"
stdout_path "/data/servers/app/logs/unicorn_out.log"

# combine REE with "preload_app true" for memory savings
# http://rubyenterpriseedition.com/faq.html#adapt_apps_for_cow
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
  GC.copy_on_write_friendly = true

before_fork do |server, worker|
  # the following is highly recomended for Rails + "preload_app true"
  # as there's no need for the master process to hold a connection
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!

  # The following is only recommended for memory/DB-constrained
  # installations.  It is not needed if your system can house
  # twice as many worker_processes as you have configured.
  #
  # # This allows a new master process to incrementally
  # # phase out the old master process with SIGTTOU to avoid a
  # # thundering herd (especially in the "preload_app false" case)
  # # when doing a transparent upgrade.  The last worker spawned
  # # will then kill off the old master process with a SIGQUIT.
  # old_pid = "#{server.config[:pid]}.oldbin"
  # if old_pid != server.pid
  #   begin
  #     sig = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
  #     Process.kill(sig, File.read(old_pid).to_i)
  #   rescue Errno::ENOENT, Errno::ESRCH
  #   end
  # end
  #
  # Throttle the master from forking too quickly by sleeping.  Due
  # to the implementation of standard Unix signal handlers, this
  # helps (but does not completely) prevent identical, repeated signals
  # from being lost when the receiving process is busy.
  # sleep 1
end

after_fork do |server, worker|
  # per-process listener ports for debugging/admin/migrations
  # addr = "127.0.0.1:#{9293 + worker.nr}"
  # server.listen(addr, :tries => -1, :delay => 5, :tcp_nopush => true)

  # the following is *required* for Rails + "preload_app true",
  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection

  # if preload_app is true, then you may also want to check and
  # restart any other shared sockets/descriptors such as Memcached,
  # and Redis.  TokyoCabinet file handles are safe to reuse
  # between any number of forked children (assuming your kernel
  # correctly implements pread()/pwrite() system calls)
end


--
Grant Heffernan


From normalperson at yhbt.net  Fri Nov 12 17:56:34 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 12 Nov 2010 14:56:34 -0800
Subject: error when HUP'ing unicorn
In-Reply-To: <1113C85A-16C6-4197-B0C3-29F89B506E17@me.com>
References: <1113C85A-16C6-4197-B0C3-29F89B506E17@me.com>
Message-ID: <20101112225634.GA16277@dcvr.yhbt.net>

Grant Heffernan <heffergm at me.com> wrote:
> Anyone come across this one before?
> 
> Refreshing Gem list

> error reloading config_file=/data/servers/patch-fe-apache/conf/unicorn.rb: TypeError can't convert Hash into Integer /opt/bcs/packages/ruby-gems-1.8/lib/site_ruby/1.8/rubygems/source_index.rb:89:in `read'

Which version of RubyGems are you using?  Looking at my RubyGems 1.3.7 install,
I see this:

  88      spec_code = if defined? Encoding then
  89                    File.read file_name, :encoding => 'UTF-8'
  90                  else
  91                    File.read file_name
  92                  end.untaint

I bet you have an "Encoding" constant defined by your application, and
that's tricking RubyGems into thinking you're running Ruby 1.9, which
you're not.  You don't get this error the first time you load your code
because it hasn't loaded your Encoding constant, yet, but HUP will cause
RubyGems to refresh its list of gems.

So rename whatever you're calling "Encoding" since it confuses RubyGems
and will break under Ruby 1.9

-- 
Eric Wong

From normalperson at yhbt.net  Mon Nov 15 13:41:02 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 15 Nov 2010 10:41:02 -0800
Subject: [ANN] kgio library / RubyGem
In-Reply-To: <20100928030302.GA3452@dcvr.yhbt.net>
References: <20100928030302.GA3452@dcvr.yhbt.net>
Message-ID: <20101115184102.GB765@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> 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!

OK, it's got a separate mailing list at kgio at librelist.com, now.

Apparently it's garnered some attention and dalli[1] is one of the first
projects to start using it.

Homepage and git repository locations remain the same:

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

[1] - git://github.com/mperham/dalli

-- 
Eric Wong

From georgedooley4491 at static-66-15-179-18.bdsl.verizon.net  Tue Nov 16 04:04:17 2010
From: georgedooley4491 at static-66-15-179-18.bdsl.verizon.net (scanty)
Date: Tue, 16 Nov 2010 09:04:17 -0000
Subject: [QC-5]b2b marketing lists
Message-ID: <mailman.0.1289898265.7494.mongrel-unicorn@rubyforge.org>

Below is a catalog of all our lists and the corresponding prices:

note: all lists are optin and sold with unlimited use rights

HEALTH RELATED LISTS
Any Individual list below $109 ea OR 2 for $179 (Only until Friday)

-> Complete US Physicians Database
-> Chiropractic Doctors in the USA
-> American Holistic Medicine Providers/Clinics
-> General Dentists in the USA
-> Dentists with Specialties 
-> American Veterinarians & Veterinary Clinics
-> US Hospitals 
-> Nursing Homes int the US 
-> Pharmaceutical Company Employees
-> Physical/Occupational Therapy Clinics and Therapists in the US
-> Oncology Physicians in the US
-> US Surgery Centers
-> Massage Therapists/Therapy Clinics in America
-> Acupuncturists/clinics in the US
-> Medical Equipment Suppliers(USA)
-> Mental Health Counselors (USA)
-> Optometrists/Clinics (USA)
-> Psychologists (USA)

BUSINESS RELATED LISTS
Take any individual list below for just $137 each (Only until Friday)

-> Hotels in the USA
-> Realtors in the USA 
-> USA Business Database 
-> Manufacturer Database (USA)
-> Financial Planner Database (USA)
-> Finance & Professionals Database (USA)
-> Insurance Agents (USA)
-> Canadian Businesses
-> United Kingdom Business Database
-> Media Outlet Contacts (USA)

CONSUMER RELATED LISTS
$97 each (only until Fri)

-> USA Consumer Database 
-> Credit Inquiries Database (USA)
-> American Homeowners

[ PROFESSIONALS LISTS ]
$112 each (Expires Friday)

-> USA Lawyers Database 
-> Criminal Attorneys in the US


Reply to this address for details and samples: diverselists at gmx.com

  




Send email to purgefile at gmx.com for deleted status
  





From normalperson at yhbt.net  Tue Nov 16 19:26:43 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 16 Nov 2010 16:26:43 -0800
Subject: [ANN] unicorn 3.0.0pre1 - disable rewindable input!
Message-ID: <20101117002643.GA13307@dcvr.yhbt.net>

Rewindable "rack.input" may be disabled via the
"rewindable_input false" directive in the configuration file.
This will violate Rack::Lint for Rack 1.x applications, but
can reduce I/O for applications that do not need it.

There are also internal cleanups and enhancements for future
versions of Rainbows!

Eric Wong (11):
      t0012: fix race condition in reload
      enable HTTP keepalive support for all methods
      http_parser: add HttpParser#next? method
      tee_input: switch to simpler API for parsing trailers
      switch versions to 3.0.0pre
      add stream_input class and build tee_input on it
      configurator: enable "rewindable_input" directive
      http_parser: ensure keepalive is disabled when reset
      *_input: make life easier for subclasses/modules
      tee_input: restore read position after #size
      preread_input: no-op for non-rewindable "rack.input"

See "git log" output for all the gory details.

* http://unicorn.bogomips.org/
* mongrel-unicorn at rubyforge.org
* git://git.bogomips.org/unicorn.git

-- 
Eric Wong

From gut4rt at gmail.com  Thu Nov 18 04:21:25 2010
From: gut4rt at gmail.com (gut)
Date: Thu, 18 Nov 2010 12:21:25 +0300
Subject: Errors in unicorn 2.0.0 and 2.0.1
Message-ID: <AANLkTi=Z41ZVYWPucp6Epg6YEuuMAe7BmoP4tQ-eVhmk@mail.gmail.com>

I have this error in unicorn.stderr.log:

Unhandled listen loop exception #<Errno::ENOSYS: Function not
implemented - accept>.

And the crazy size of unicorn.stderr.log.

In version 1.1.3 all ok.

From normalperson at yhbt.net  Thu Nov 18 04:51:55 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 18 Nov 2010 09:51:55 +0000
Subject: Errors in unicorn 2.0.0 and 2.0.1
In-Reply-To: <AANLkTi=Z41ZVYWPucp6Epg6YEuuMAe7BmoP4tQ-eVhmk@mail.gmail.com>
References: <AANLkTi=Z41ZVYWPucp6Epg6YEuuMAe7BmoP4tQ-eVhmk@mail.gmail.com>
Message-ID: <20101118095155.GA4543@dcvr.yhbt.net>

gut <gut4rt at gmail.com> wrote:
> I have this error in unicorn.stderr.log:
> 
> Unhandled listen loop exception #<Errno::ENOSYS: Function not
> implemented - accept>.

Which OS do you run?

We switched to kgio in Unicorn 2.x.x, so there may be some unresolved
portability issues.

> In version 1.1.3 all ok.

1.1.x will continue to be supported indefinitely, so feel free to
continue using it as we improve portability of 2.x.x.

-- 
Eric Wong

From normalperson at yhbt.net  Thu Nov 18 19:14:17 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 19 Nov 2010 00:14:17 +0000
Subject: [ANN] unicorn 3.0.0pre2 - bugfixes, final coming soon
In-Reply-To: <20101117002643.GA13307@dcvr.yhbt.net>
References: <20101117002643.GA13307@dcvr.yhbt.net>
Message-ID: <20101119001417.GA20444@dcvr.yhbt.net>

This release updates us to the Kgio 2.x series which should play more
nicely with other applications and libraries which also use Kgio.  There
are also bugfixes from the 2.0.1 release and a small bugfix to the new
StreamInput class.

The Unicorn 3.x series will supercede the 2.x series
while the 1.x series will remain supported indefinitely.

* http://unicorn.bogomips.org/
* mongrel-unicorn at rubyforge.org
* git://git.bogomips.org/unicorn.git

-- 
Eric Wong

From normalperson at yhbt.net  Fri Nov 19 21:19:56 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 19 Nov 2010 18:19:56 -0800
Subject: Errors in unicorn 2.0.0 and 2.0.1
In-Reply-To: <20101118095155.GA4543@dcvr.yhbt.net>
References: <AANLkTi=Z41ZVYWPucp6Epg6YEuuMAe7BmoP4tQ-eVhmk@mail.gmail.com>
	<20101118095155.GA4543@dcvr.yhbt.net>
Message-ID: <20101120021956.GA16331@dcvr.yhbt.net>

Eric Wong <normalperson at yhbt.net> wrote:
> gut <gut4rt at gmail.com> wrote:
> > I have this error in unicorn.stderr.log:
> > 
> > Unhandled listen loop exception #<Errno::ENOSYS: Function not
> > implemented - accept>.
> 
> Which OS do you run?

The discussion went offlist and the original poster hasn't confirmed
it, but I'm thinking the kgio library was built on 2.6.28+ and
deployed on 2.6.26, so the accept4() syscall was enabled but
wouldn't work on the older kernel.

-- 
Eric Wong

From normalperson at yhbt.net  Fri Nov 19 21:47:53 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 20 Nov 2010 02:47:53 +0000
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
Message-ID: <20101120024753.GA24901@dcvr.yhbt.net>

Changes:

Rewindable "rack.input" may be disabled via the
"rewindable_input false" directive in the configuration file.
This will violate Rack::Lint for Rack 1.x applications, but can
reduce I/O for applications that do not need a rewindable
input.

This release updates us to the Kgio 2.x series which should play
more nicely with other libraries and applications.  There are
also internal cleanups and improvements for future versions of
Rainbows!

The Unicorn 3.x series supercedes the 2.x series
while the 1.x series will remain supported indefinitely.

* http://unicorn.bogomips.org/
* mongrel-unicorn at rubyforge.org
* git://git.bogomips.org/unicorn.git

-- 
Eric Wong

From mguterl at gmail.com  Sat Nov 20 12:50:50 2010
From: mguterl at gmail.com (Michael Guterl)
Date: Sat, 20 Nov 2010 12:50:50 -0500
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <20101120024753.GA24901@dcvr.yhbt.net>
References: <20101120024753.GA24901@dcvr.yhbt.net>
Message-ID: <AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>

On Fri, Nov 19, 2010 at 9:47 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Changes:
>
> Rewindable "rack.input" may be disabled via the
> "rewindable_input false" directive in the configuration file.
> This will violate Rack::Lint for Rack 1.x applications, but can
> reduce I/O for applications that do not need a rewindable
> input.
>
> This release updates us to the Kgio 2.x series which should play
> more nicely with other libraries and applications. ?There are
> also internal cleanups and improvements for future versions of
> Rainbows!
>
> The Unicorn 3.x series supercedes the 2.x series
> while the 1.x series will remain supported indefinitely.
>
We've been using Unicorn 1.x very successfully for some time with a
Rails 2.3 application.  Would you recommend upgrading to Unicorn 3.x?

Best,
Michael Guterl

From normalperson at yhbt.net  Sat Nov 20 23:05:45 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 21 Nov 2010 04:05:45 +0000
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
References: <20101120024753.GA24901@dcvr.yhbt.net>
	<AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
Message-ID: <20101121040544.GA11490@dcvr.yhbt.net>

Michael Guterl <mguterl at gmail.com> wrote:
> We've been using Unicorn 1.x very successfully for some time with a
> Rails 2.3 application.  Would you recommend upgrading to Unicorn 3.x?

Yes if you're running a recent Linux (>= 2.6.28), it might help somewhat
with performance (but may not be noticeable with a particular app).
I haven't done extensive benchmarking, but the reduction of syscalls
should help a bit, and newer versions will exploit some of that more.

I don't expect (m)any regressions on recent Linux, and any will be found
and fixed quickly (usually within 24-48 hours).

If you're willing to help iron out portability bugs to other kernels,
then please upgrade and report back :)


On the other hand, if you're going to be losing a lot of
money/users/lives in case of failure, stick to what works for you :)

-- 
Eric Wong

From jeremyevans0 at gmail.com  Sun Nov 21 11:29:24 2010
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Sun, 21 Nov 2010 08:29:24 -0800
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <20101121040544.GA11490@dcvr.yhbt.net>
References: <20101120024753.GA24901@dcvr.yhbt.net>
	<AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
	<20101121040544.GA11490@dcvr.yhbt.net>
Message-ID: <AANLkTik-c4dJ82FzBNTvNWQtd-Z9-1==Wp_uLBdsPgoA@mail.gmail.com>

On Sat, Nov 20, 2010 at 8:05 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Michael Guterl <mguterl at gmail.com> wrote:
>> We've been using Unicorn 1.x very successfully for some time with a
>> Rails 2.3 application. ?Would you recommend upgrading to Unicorn 3.x?
>
> Yes if you're running a recent Linux (>= 2.6.28), it might help somewhat
> with performance (but may not be noticeable with a particular app).
> I haven't done extensive benchmarking, but the reduction of syscalls
> should help a bit, and newer versions will exploit some of that more.
>
> I don't expect (m)any regressions on recent Linux, and any will be found
> and fixed quickly (usually within 24-48 hours).
>
> If you're willing to help iron out portability bugs to other kernels,
> then please upgrade and report back :)
>
>
> On the other hand, if you're going to be losing a lot of
> money/users/lives in case of failure, stick to what works for you :)

Just an anecdotal data point here, using OpenBSD-current.  Moving from
Unicorn 1.0 to 2.0 sped up the scaffolding_extensions integration test
suite by a factor of 3 (~10 seconds to ~3 seconds).  I'm guessing this
is due mainly to the use of kgio.  Hoping to upgrade to Unicorn 3.0
today.

Jeremy

From normalperson at yhbt.net  Sun Nov 21 18:49:53 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sun, 21 Nov 2010 23:49:53 +0000
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <AANLkTik-c4dJ82FzBNTvNWQtd-Z9-1==Wp_uLBdsPgoA@mail.gmail.com>
References: <20101120024753.GA24901@dcvr.yhbt.net>
	<AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
	<20101121040544.GA11490@dcvr.yhbt.net>
	<AANLkTik-c4dJ82FzBNTvNWQtd-Z9-1==Wp_uLBdsPgoA@mail.gmail.com>
Message-ID: <20101121234953.GA14970@dcvr.yhbt.net>

Jeremy Evans <jeremyevans0 at gmail.com> wrote:
> On Sat, Nov 20, 2010 at 8:05 PM, Eric Wong <normalperson at yhbt.net> wrote:
> > Michael Guterl <mguterl at gmail.com> wrote:
> >> We've been using Unicorn 1.x very successfully for some time with a
> >> Rails 2.3 application. ?Would you recommend upgrading to Unicorn 3.x?
> >
> > Yes if you're running a recent Linux (>= 2.6.28), it might help somewhat
> > with performance (but may not be noticeable with a particular app).
> > I haven't done extensive benchmarking, but the reduction of syscalls
> > should help a bit, and newer versions will exploit some of that more.
<snip>
> > If you're willing to help iron out portability bugs to other kernels,
> > then please upgrade and report back :)
> 
> Just an anecdotal data point here, using OpenBSD-current.  Moving from
> Unicorn 1.0 to 2.0 sped up the scaffolding_extensions integration test
> suite by a factor of 3 (~10 seconds to ~3 seconds).  I'm guessing this
> is due mainly to the use of kgio.  Hoping to upgrade to Unicorn 3.0
> today.

Wow!  I didn't expect that kind of performance improvement![1]  What
is this test doing?  I'm actually suspicious there could be a bug
somewhere in Unicorn or kgio causing wrong results :)

Let us know how 3.0 goes, thanks!

[1] - dalli reported 10-20%, which is closer to what I expected
      (1-10%).

-- 
Eric Wong

From jeremyevans0 at gmail.com  Sun Nov 21 20:21:29 2010
From: jeremyevans0 at gmail.com (Jeremy Evans)
Date: Sun, 21 Nov 2010 17:21:29 -0800
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <20101121234953.GA14970@dcvr.yhbt.net>
References: <20101120024753.GA24901@dcvr.yhbt.net>
	<AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
	<20101121040544.GA11490@dcvr.yhbt.net>
	<AANLkTik-c4dJ82FzBNTvNWQtd-Z9-1==Wp_uLBdsPgoA@mail.gmail.com>
	<20101121234953.GA14970@dcvr.yhbt.net>
Message-ID: <AANLkTikj+5HNbhBiiR2wUth=L6MCiky0xy6jY3wxANcN@mail.gmail.com>

On Sun, Nov 21, 2010 at 3:49 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Jeremy Evans <jeremyevans0 at gmail.com> wrote:
>> On Sat, Nov 20, 2010 at 8:05 PM, Eric Wong <normalperson at yhbt.net> wrote:
>> > Michael Guterl <mguterl at gmail.com> wrote:
>> >> We've been using Unicorn 1.x very successfully for some time with a
>> >> Rails 2.3 application. ?Would you recommend upgrading to Unicorn 3.x?
>> >
>> > Yes if you're running a recent Linux (>= 2.6.28), it might help somewhat
>> > with performance (but may not be noticeable with a particular app).
>> > I haven't done extensive benchmarking, but the reduction of syscalls
>> > should help a bit, and newer versions will exploit some of that more.
> <snip>
>> > If you're willing to help iron out portability bugs to other kernels,
>> > then please upgrade and report back :)
>>
>> Just an anecdotal data point here, using OpenBSD-current. ?Moving from
>> Unicorn 1.0 to 2.0 sped up the scaffolding_extensions integration test
>> suite by a factor of 3 (~10 seconds to ~3 seconds). ?I'm guessing this
>> is due mainly to the use of kgio. ?Hoping to upgrade to Unicorn 3.0
>> today.
>
> Wow! ?I didn't expect that kind of performance improvement![1] ?What
> is this test doing? ?I'm actually suspicious there could be a bug
> somewhere in Unicorn or kgio causing wrong results :)
>
> Let us know how 3.0 goes, thanks!
>
> [1] - dalli reported 10-20%, which is closer to what I expected
> ? ? ?(1-10%).

Looks like it must have been some other change that caused this speed
up, as after testing again with 1.x, I'm getting about the same in
terms of performance.  Sorry for the misinformation.

Jeremy

From favourmabou12 at ymail.com  Mon Nov 22 08:14:07 2010
From: favourmabou12 at ymail.com (favourmabou12 at ymail.com)
Date: Mon, 22 Nov 2010 05:14:07 -0800
Subject: Hello dear.It is my pleasure to meet you.From Favour has sent you a
	free game
Message-ID: <E1PKWDf-0004VW-7y@co195.reliablehosting.com>

Hello dear.It is my pleasure to meet you.From Favour found this free online game at GameFools.com and thought you would like it.

Game: Super Pop and Drop
Details: Use power pieces and avoid getting crushed by the balls dropping from above.

Visit the following web page to play this free game now!
http://www.gamefools.com/onlinegames/game/SuperPopandDrop.html

Hello dear.It is my pleasure to meet you.From Favour also included this message for you:
&#1047;&#1076;&#1088;&#1072;&#1074;&#1089;&#1090;&#1074;&#1091;&#1081;&#1090;&#1077; &#1059;&#1074;&#1072;&#1078;&#1072;&#1077;&#1084;&#1099;&#1077;

&#1054;&#1095;&#1077;&#1085;&#1100; &#1087;&#1088;&#1080;&#1103;&#1090;&#1085;&#1086;.

&#1082;&#1072;&#1082; &#1090;&#1099;? &#1103; &#1085;&#1072;&#1076;&#1077;&#1102;&#1089;&#1100;, &#1095;&#1090;&#1086; &#1074;&#1099; &#1074; &#1087;&#1086;&#1088;&#1103;&#1076;&#1082;&#1077;, &#1101;&#1090;&#1086; &#1103; &#1089; &#1091;&#1076;&#1086;&#1074;&#1086;&#1083;&#1100;&#1089;&#1090;&#1074;&#1080;&#1077;&#1084; ConAct &#1074;&#1072;&#1084;&#1080; &#1087;&#1086;&#1089;&#1083;&#1077; &#1087;&#1088;&#1086;&#1089;&#1084;&#1086;&#1090;&#1088;&#1072; &#1074;&#1072;&#1096;&#1077;&#1075;&#1086; &#1101;&#1083;&#1077;&#1082;&#1090;&#1088;&#1086;&#1085;&#1085;&#1086;&#1081; &#1087;&#1086;&#1095;&#1090;&#1077; &#1089;&#1077;&#1075;&#1086;&#1076;&#1085;&#1103; &#1074; [www.radikal.ru], &#1074; &#1082;&#1086;&#1090;&#1086;&#1088;&#1099;&#1093; &#1076;&#1077;&#1081;&#1089;&#1090;&#1074;&#1080;&#1090;&#1077;&#1083;&#1100;&#1085;&#1086; &#1080;&#1085;&#1090;&#1077;&#1088;&#1077;&#1089;&#1091;&#1077;&#1090; &#1084;&#1077;&#1085;&#1103; &#1057;&#1054;&#1054;&#1041;&#1065;&#1045;&#1053;&#1048;&#1045; &#1089; &#1074;&#1072;&#1084;&#1080;, &#1077;&#1089;&#1083;&#1080; &#1091; &#1074;&#1072;&#1089; &#1077;&#1089;&#1090;&#1100; &#1078;&#1077;&#1083;&#1072;&#1085;&#1080;&#1077; &#1089;&#1086; &#1084;&#1085;&#1086;&#1081;, &#1095;&#1090;&#1086;&#1073;&#1099; &#1085;&#1072;&#1087;&#1080;&#1089;&#1072;&#1090;&#1100; &#1084;&#1085;&#1077; &#1086;&#1073;&#1088;&#1072;&#1090;&#1085;&#1086; &#1042; &#1084;&#1086;&#1081; &#1072;&#1076;&#1088;&#1077;&#1089; &#1101;&#1083;&#1077;&#1082;&#1090;&#1088;&#1086;&#1085;&#1085;&#1086;&#1081; &#1087;&#1086;&#1095;&#1090;&#1099; [favourmabou12 at ymail.com], &#1087;&#1086;&#1101;&#1090;&#1086;&#1084;&#1091; &#1103; &#1084;&#1086;&#1075;&#1091; &#1086;&#1090;&#1087;&#1088;&#1072;&#1074;&#1080;&#1090;&#1100; &#1074;&#1072;&#1084; &#1084;&#1086;&#1102; &#1092;&#1086;&#1090;&#1086;&#1075;&#1088;&#1072;&#1092;&#1080;&#1102;, &#1080; &#1074;&#1099; &#1090;&#1086;&#1078;&#1077; &#1087;&#1088;&#1080;&#1096;&#1083;&#1080; &#1084;&#1085;&#1077; &#1089;&#1074;&#1086;&#1080; &#1055;&#1054;&#1057; &#1080; &#1095;&#1090;&#1086;&#1073;&#1099; &#1084;&#1099; &#1084;&#1086;&#1075;&#1083;&#1080; &#1083;&#1091;&#1095;&#1096;&#1077; &#1091;&#1079;&#1085;&#1072;&#1090;&#1100; &#1076;&#1088;&#1091;&#1075; &#1076;&#1088;&#1091;&#1075;&#1072; &#1080; &#1079;&#1085;&#1072;&#1077;&#1084;, &#1095;&#1090;&#1086; &#1087;&#1088;&#1086;&#1080;&#1079;&#1086;&#1081;&#1076;&#1077;&#1090; &#1074; fueture, &#1103; &#1073;&#1091;&#1076;&#1091; &#1078;&#1076;&#1072;&#1090;&#1100;, &#1095;&#1090;&#1086;&#1073;&#1099; &#1091;&#1089;&#1083;&#1099;&#1096;&#1072;&#1090;&#1100; &#1086;&#1090; &#1042;&#1099;, &#1082;&#1072;&#1082; &#1103; &#1078;&#1077;&#1083;&#1072;&#1102; &#1074;&#1072;&#1084; &#1074;&#1089;&#1077;&#1075;&#1086; &#1085;&#1072;&#1080;&#1083;&#1091;&#1095;&#1096;&#1077;&#1075;&#1086; &#1074; &#1076;&#1077;&#1085;&#1100;.
&#1042;&#1072;&#1096; &#1085;&#1086;&#1074;&#1099;&#1081; &#1087;&#1086;&#1083;&#1100;&#1079;&#1091; &#1076;&#1088;&#1091;&#1075;&#1072;.

=========================================
Hello Dear

Nice to meet you.

how are you ?i hope you are OK,it is my pleasure to conact you after viewing your email today in [www.radikal.ru]in which really intrested me to communicat with you if you have the desire with me to write me back in my email adress[favourmabou12 at ymail.com]so i can send you my picture and you too send me your pic and so that we can get to know each other and  know what will happen in fueture, i will be waiting to hear from you, as i wish you all the best for your day.
yours new friend favour.


Kind regards,
GameFools.com


(Privacy notice: You have NOT been added to a mailing list.)

From mguterl at gmail.com  Tue Nov 23 12:34:19 2010
From: mguterl at gmail.com (Michael Guterl)
Date: Tue, 23 Nov 2010 12:34:19 -0500
Subject: [ANN] unicorn 3.0.0 - disable rewindable input!
In-Reply-To: <20101121040544.GA11490@dcvr.yhbt.net>
References: <20101120024753.GA24901@dcvr.yhbt.net>
	<AANLkTin0eURuYY3Hitz8SNgVDCWZeC8anXDbB_djMqwR@mail.gmail.com>
	<20101121040544.GA11490@dcvr.yhbt.net>
Message-ID: <AANLkTi=iyZDj9Lrsw74c-FUbAMdxbSRW=kdGJL48pd21@mail.gmail.com>

On Sat, Nov 20, 2010 at 11:05 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Michael Guterl <mguterl at gmail.com> wrote:
>> We've been using Unicorn 1.x very successfully for some time with a
>> Rails 2.3 application. ?Would you recommend upgrading to Unicorn 3.x?
>
> Yes if you're running a recent Linux (>= 2.6.28), it might help somewhat
> with performance (but may not be noticeable with a particular app).
> I haven't done extensive benchmarking, but the reduction of syscalls
> should help a bit, and newer versions will exploit some of that more.
>
> I don't expect (m)any regressions on recent Linux, and any will be found
> and fixed quickly (usually within 24-48 hours).
>
> If you're willing to help iron out portability bugs to other kernels,
> then please upgrade and report back :)
>
>
> On the other hand, if you're going to be losing a lot of
> money/users/lives in case of failure, stick to what works for you :)

Thanks Eric, we'll probably stick with 1.x for the time being.

From adymo at pluron.com  Thu Nov 25 18:06:03 2010
From: adymo at pluron.com (Alexander Dymo)
Date: Fri, 26 Nov 2010 01:06:03 +0200
Subject: Dedicated queues for long-running requests with single unicorn
	master: question and a possible solution
Message-ID: <op.vmq04dqsaya692@macbook-air-borys-dymo.local>

Hey,
I have two major types of requests for my app:
- long-running (10 sec and more, I can differentiate them by url)
- normal (less than 1 sec)

Question is: I'd like to setup the server in a way that:
1) normal requests are served by 15 unicorn workers
2) long-running requests are served by additional 5 unicorn workers with  
their own queue

Separate queue for long-running requests is to prevent people who run long  
requests
consume all workers (for example: hit refresh 20 times or just do too many  
valid but long requests).

Here's the possible solution I came up with and it seems to work.
What do you think about it? Does it have problems I didn't think of?
Are there better ways to do the same thing?


My solution so far:
- in nginx:
   - create two upstream servers
   - configure nginx to pass long-running request to a long-running upstream

   upstream unicorn {
     server unix:/tmp/unicorn.sock;
   }
   upstream long_requests_unicorn {
     server unix:/tmp/long_requests_unicorn.sock;
   }
   server {
     location ~ ^/(long_request_url1|long_request_url2) {
       if (!-f $request_filename) {
         proxy_pass http://long_requests_unicorn;
         break;
       }
     }
     if (!-f $request_filename) {
       proxy_pass http://unicorn;
       break;
     }
   }

- in unicorn configuration file:
   - listen to both sockets in master
   - after forking a child, close the socket it doesn't need to listen to

   worker_processes 20
   listen File.join('/tmp/unicorn.sock')
   listen File.join('/tmp/long_requests_unicorn.sock')

   def assign_to_queue(server, worker)
     queue = case worker.nr
       when  0...15 then '/tmp/unicorn.sock'
       when 15...20 then '/tmp/long_requests_unicorn.sock'
       else raise "Can't find queue for the worker ##{worker.nr}"
     end

     server.listeners = Unicorn::HttpServer::LISTENERS.find_all do |io|
       server.send(:sock_name, io) == queue
     end
   end

   after_fork do |server, worker|
     assign_to_queue(server, worker)
   end

From normalperson at yhbt.net  Thu Nov 25 19:40:45 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 26 Nov 2010 00:40:45 +0000
Subject: Dedicated queues for long-running requests with single unicorn
	master: question and a possible solution
In-Reply-To: <op.vmq04dqsaya692@macbook-air-borys-dymo.local>
References: <op.vmq04dqsaya692@macbook-air-borys-dymo.local>
Message-ID: <20101126004045.GC25256@dcvr.yhbt.net>

Alexander Dymo <adymo at pluron.com> wrote:
> Hey,
> I have two major types of requests for my app:
> - long-running (10 sec and more, I can differentiate them by url)
> - normal (less than 1 sec)
<snip>
> Here's the possible solution I came up with and it seems to work.
> What do you think about it? Does it have problems I didn't think of?
> Are there better ways to do the same thing?

No chance of speeding up the long requests?  That's the best option.

It may make more sense to other people (non-Rubyists) who could inherit
the system to manage the Unicorn master instances separately and use
separate config files.  Otherwise, I suppose your approach is valid
(haven't tried nor seen it myself).

If the long request is blocking on something external (e.g. making an
HTTP request to an OpenID provider), then Rainbows![1] is worth looking
into.

[1] http://rainbows.rubyforge.org/
    The second section here is probably applicable to you:
    http://rainbows.rubyforge.org/DEPLOY.html

-- 
Eric Wong