Out of band stuff?

Out of band stuff?

[Damian Janowski]

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.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Eric Wong]

Damian Janowski <jano-eWlILCNyKRBBDgjK7y7TUQ@public.gmane.org> 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).
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Damian Janowski]

On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> 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.
>
>        -d7HPF+t6YlILr15SpQP/1rNAH6kLmebB@public.gmane.org { @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?)
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Eric Wong]

Damian Janowski <jano-eWlILCNyKRBBDgjK7y7TUQ@public.gmane.org> 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 :)
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Damian Janowski]

On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> 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.
>
>        -d7HPF+t6YlILr15SpQP/1rNAH6kLmebB@public.gmane.org { @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.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Eric Wong]

Damian Janowski <jano@dimaion.com> wrote:
> On Mon, Apr 9, 2012 at 12:05 AM, Eric Wong <normalperson@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.
_______________________________________________
Rainbows! mailing list - rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

[Damian Janowski]

On Tue, Apr 10, 2012 at 5:37 PM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> 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.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying