From jano at dimaion.com  Fri Apr  6 21:49:34 2012
From: jano at dimaion.com (Damian Janowski)
Date: Fri, 6 Apr 2012 18:49:34 -0300
Subject: Out of band stuff?
Message-ID: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>

Hello everyone,

I'm needing to perform a couple of tasks outside of the request cycle.
For instance, I want to ping a web service every X minutes so that I
can maintain a persistent connection to it and have better response
times for some requests that I have to do *inside* the request cycle.

What would be the reasonable way of doing this?

I'm thinking the OOB GC is just another example. But the current way
the OOB GC is written makes one think it's a very specific case and
not something one should use for other purposes.

Thoughts?

Thanks in advance.

D.

From normalperson at yhbt.net  Mon Apr  9 03:05:52 2012
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 9 Apr 2012 03:05:52 +0000
Subject: Out of band stuff?
In-Reply-To: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
Message-ID: <20120409030552.GA24089@dcvr.yhbt.net>

Damian Janowski <jano at dimaion.com> wrote:
> Hello everyone,
> 
> I'm needing to perform a couple of tasks outside of the request cycle.
> For instance, I want to ping a web service every X minutes so that I
> can maintain a persistent connection to it and have better response
> times for some requests that I have to do *inside* the request cycle.
> 
> What would be the reasonable way of doing this?

For Raindrops::Watcher, I start a background thread on the first request:

	git clone git://bogomips.org/raindrops.git
	$EDITOR lib/raindrops/watcher.rb

If you look at the `call' method in raindrops/watcher.rb, the important
line is this:

	# @start is a Mutex and @thr is nil in the initialize method.

	@start.synchronize { @thr ||= aggregator_thread(env["rack.logger"]) }

I avoid starting the background thread at initialization because it'll
die on fork (meaning I'd have to recheck it all the time, anyways).

The overhead of Mutex#synchronize and @thr||= assignment is negligible
in most apps.

> I'm thinking the OOB GC is just another example. But the current way
> the OOB GC is written makes one think it's a very specific case and
> not something one should use for other purposes.

Yes, Unicorn::OobGC is very specific to how Unicorn works and the way it
works wouldn't translate well to Rainbows! (as Rainbows! does persistent
connections and unicorn does not).

From jano at dimaion.com  Mon Apr  9 13:04:26 2012
From: jano at dimaion.com (Damian Janowski)
Date: Mon, 9 Apr 2012 10:04:26 -0300
Subject: Out of band stuff?
In-Reply-To: <20120409030552.GA24089@dcvr.yhbt.net>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
	<20120409030552.GA24089@dcvr.yhbt.net>
Message-ID: <CABAijKEa3Z9ZBFS-jX8wcvqjZ14sxKsPMbuESRvZOeLhRNBiCQ@mail.gmail.com>

On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson at yhbt.net> wrote:
> For Raindrops::Watcher, I start a background thread on the first request:
>
> ? ? ? ?git clone git://bogomips.org/raindrops.git
> ? ? ? ?$EDITOR lib/raindrops/watcher.rb

Great, that should get me started!

> If you look at the `call' method in raindrops/watcher.rb, the important
> line is this:
>
> ? ? ? ?# @start is a Mutex and @thr is nil in the initialize method.
>
> ? ? ? ?@start.synchronize { @thr ||= aggregator_thread(env["rack.logger"]) }

By the way, why does #aggregator_thread call #wait_snapshot before
returning the thread? (I'm no expert in threading, but my guess is to
wait for the first loop to run correctly?)

From normalperson at yhbt.net  Tue Apr 10 20:16:38 2012
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 10 Apr 2012 20:16:38 +0000
Subject: Out of band stuff?
In-Reply-To: <CABAijKEa3Z9ZBFS-jX8wcvqjZ14sxKsPMbuESRvZOeLhRNBiCQ@mail.gmail.com>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
	<20120409030552.GA24089@dcvr.yhbt.net>
	<CABAijKEa3Z9ZBFS-jX8wcvqjZ14sxKsPMbuESRvZOeLhRNBiCQ@mail.gmail.com>
Message-ID: <20120410201638.GD25426@dcvr.yhbt.net>

Damian Janowski <jano at dimaion.com> wrote:
> By the way, why does #aggregator_thread call #wait_snapshot before
> returning the thread? (I'm no expert in threading, but my guess is to
> wait for the first loop to run correctly?)

You are correct :)

From jano at dimaion.com  Tue Apr 10 20:24:56 2012
From: jano at dimaion.com (Damian Janowski)
Date: Tue, 10 Apr 2012 17:24:56 -0300
Subject: Out of band stuff?
In-Reply-To: <20120409030552.GA24089@dcvr.yhbt.net>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
	<20120409030552.GA24089@dcvr.yhbt.net>
Message-ID: <CABAijKG0srUSc4VEk35yd9jj1NAz9VJMqLZ3Uh_xeiObgTmXvw@mail.gmail.com>

On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson at yhbt.net> wrote:
> If you look at the `call' method in raindrops/watcher.rb, the important
> line is this:
>
> ? ? ? ?# @start is a Mutex and @thr is nil in the initialize method.
>
> ? ? ? ?@start.synchronize { @thr ||= aggregator_thread(env["rack.logger"]) }
>
> I avoid starting the background thread at initialization because it'll
> die on fork (meaning I'd have to recheck it all the time, anyways).
>
> The overhead of Mutex#synchronize and @thr||= assignment is negligible
> in most apps.

One more question. Can you confirm that this technique doesn't work as
expected using Rainbows/ThreadPool? I've found that Rack::Builder
creates a new instance of each middleware on every request, so you'd
end up spawning infinite aggregator threads.

From normalperson at yhbt.net  Tue Apr 10 20:37:43 2012
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 10 Apr 2012 20:37:43 +0000
Subject: Out of band stuff?
In-Reply-To: <CABAijKG0srUSc4VEk35yd9jj1NAz9VJMqLZ3Uh_xeiObgTmXvw@mail.gmail.com>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
	<20120409030552.GA24089@dcvr.yhbt.net>
	<CABAijKG0srUSc4VEk35yd9jj1NAz9VJMqLZ3Uh_xeiObgTmXvw@mail.gmail.com>
Message-ID: <20120410203743.GF25426@dcvr.yhbt.net>

Damian Janowski <jano at dimaion.com> wrote:
> On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson at yhbt.net> wrote:
> > ? ? ? ?# @start is a Mutex and @thr is nil in the initialize method.
> >
> > ? ? ? ?@start.synchronize { @thr ||= aggregator_thread(env["rack.logger"]) }
> >
> > I avoid starting the background thread at initialization because it'll
> > die on fork (meaning I'd have to recheck it all the time, anyways).
> >
> > The overhead of Mutex#synchronize and @thr||= assignment is negligible
> > in most apps.
> 
> One more question. Can you confirm that this technique doesn't work as
> expected using Rainbows/ThreadPool? I've found that Rack::Builder
> creates a new instance of each middleware on every request, so you'd
> end up spawning infinite aggregator threads.

Huh? How are you using Rack::Builder?  unicorn/Rainbows! should always be
using Rack::Builder#to_app instead of regenerating the Rack stack every
single request.

I've been using Raindrops::Watcher for months now, mainly with
ThreadSpawn, but ThreadPool seems to work just fine and I can confirm
neither spawns infinite aggregator threads.

From jano at dimaion.com  Wed Apr 11 01:20:12 2012
From: jano at dimaion.com (Damian Janowski)
Date: Tue, 10 Apr 2012 22:20:12 -0300
Subject: Out of band stuff?
In-Reply-To: <20120410203743.GF25426@dcvr.yhbt.net>
References: <CABAijKERMfjWzz9d8RxneV9eRJYLY6uSfEb9DEbhJh3jKLJ__w@mail.gmail.com>
	<20120409030552.GA24089@dcvr.yhbt.net>
	<CABAijKG0srUSc4VEk35yd9jj1NAz9VJMqLZ3Uh_xeiObgTmXvw@mail.gmail.com>
	<20120410203743.GF25426@dcvr.yhbt.net>
Message-ID: <CABAijKHgRTbyehYv=djzbf9H5-R6WByYz=wsuq55Z=cFxmfwUw@mail.gmail.com>

On Tue, Apr 10, 2012 at 5:37 PM, Eric Wong <normalperson at yhbt.net> wrote:
> Huh? How are you using Rack::Builder? ?unicorn/Rainbows! should always be
> using Rack::Builder#to_app instead of regenerating the Rack stack every
> single request.

Clearly?the wrong way :)

I'm composing apps and I was doing something like:

run Rack::Builder.new { ... }

instead of:

run Rack::Builder.new { ... }.to_app

By using the latter I get consistent object_ids across requests.

Thank you and sorry for the false alarm.

From lion.vollnhals at googlemail.com  Thu Apr 12 08:59:55 2012
From: lion.vollnhals at googlemail.com (Lion Vollnhals)
Date: Thu, 12 Apr 2012 10:59:55 +0200
Subject: 100% cpu with faye-websocket
Message-ID: <5722BD9D-C9FD-441E-A37C-7FFA686742A8@gmail.com>

Hi,

please CC me as i am not on the list.

i am using rainbows (configured with eventmachine) to serve faye websocket connections.
see https://github.com/faye/faye-websocket-ruby.

when the first user connects (using websocket protocol), cpu usage goes to 100% and stays there.
even when the user is idle or disconnects.

is this normal behavior?

i inspected the process using dtrace under mac os x and saw that the process is doing a lot of read and write system calls all the time.
i can observe the same 100% cpu behavior on linux. so this is not a mac os x issue.

here is my config file and command line:

# rainbows.conf
Rainbows! do
  use :EventMachine
end

rainbows config.ru -c path/to/rainbows.conf -E production -p 9292


regards,
Lion Vollnhals

From normalperson at yhbt.net  Thu Apr 12 09:06:44 2012
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 12 Apr 2012 02:06:44 -0700
Subject: 100% cpu with faye-websocket
In-Reply-To: <5722BD9D-C9FD-441E-A37C-7FFA686742A8@gmail.com>
References: <5722BD9D-C9FD-441E-A37C-7FFA686742A8@gmail.com>
Message-ID: <20120412090644.GA4345@dcvr.yhbt.net>

Lion Vollnhals <lion.vollnhals at googlemail.com> wrote:
> Hi,
> 
> please CC me as i am not on the list.
> 
> i am using rainbows (configured with eventmachine) to serve faye websocket connections.
> see https://github.com/faye/faye-websocket-ruby.
> 
> when the first user connects (using websocket protocol), cpu usage goes to 100% and stays there.
> even when the user is idle or disconnects.
> 
> is this normal behavior?

Have you contacted other faye users/developers on this issue?
Hopefully somebody else can help you sooner.

I'm not familiar with faye at all (this is the first I've heard of it,
even), so it'll take me some time to get up to speed.  It's been a
long while since I've looked at websockets, too.

From sales at internetsolutions.lt  Thu Apr 12 06:29:22 2012
From: sales at internetsolutions.lt (Sveiki)
Date: Thu, 12 Apr 2012 09:29:22 +0300
Subject: Sveiki.
Message-ID: <fc6a8b28a6e634eb18d16ac545328e20@naujienlaiskiai.eu>

Sveiki,

Prie? kelet? savai?i? ra??me Jums d?l interneto svetaini? k?rimo
ir atnaujinimo.  Taigi nor?tume dar kart? pasidom?ti, galb?t
persigalvojote?
?mon?s gimtadienio proga visiems u?sisakantiems 24 m?nesi? svetain?s
talpinimo paslaug?, taikome 3 m?nesi? talpinimo nuolaid?, o visoms
kitoms paslaugoms suteikiame 10% nuolaid?  (SEO paslaugoms, reklamai
internete, naujienlai?ki? siuntimui).

Nuolaidos taikomos iki 2012 m. gegu??s 01 d.

Visi m?s? svetaini? darb? pvz:
http://internetsolutions.lt/tinklapiu-kurimas/keletas-paskutiniu-darbu

Talpinimo ?kainius rasite ?ia:
http://internetsolutions.lt/tinklapiu-kurimas

Naujienlai?ki? darb? pvz:
http://internetsolutions.lt/e-marketingas/keletas-naujienlaiskiu-pavydziu




--
Evelina Navickait?
UAB ?Internet Solutions?
verslo klient? vadybinink?
+370 662 35133
sales at internetsolutions.lt
www.internetsolutions.lt
Reg. adresas: Tvenkini? g. 8A, ?aki? k., Kauno r. sav.
Biuro - korespondencijos adresas: Lyros g. 5, ?iauliai