Re: EventMachine.defer and ActiveRecord connection pool?
- From: Artūras Šlajus <x11@xxxxxxxxxxx>
- Date: Wed, 9 Sep 2009 16:14:01 -0500
Chuck Remes wrote:
I have a guess. I guess that your CONFIG['resources_manager.period']Nop, it's 1 second for testing. It happens even if you set it to 1
is set to 0 or quite close to it. If so, the PeriodicTimer is probably
firing on every "crank" of the EM reactor which is deferring more and
more of your singleton blocks. There isn't any time left over to clean
up connections to the ActiveRecord connection pool and you are running
out.
minute. Loads of time to clean up and still...
BTW, EM#defer uses a threadpool (size of 20). It enqueues each #deferThe whole purpose of @@running hash is to ensure that same task won't be
request to a Queue (thread safe). As each thread in the pool completes
its task it pops the next one off the queue.
If you flood the queue (which I suspect) then the newest tasks are
going to starve while waiting for the previous ones to complete. As
each task completes, try outputting the number of tasks in your
@@running hash and see if it is a large number.
running in parallel. I don't need two resource managers messing up
values with database, so it skips that block completely if same task is
still running.
--
Posted via http://www.ruby-forum.com/.
.
- Follow-Ups:
- Re: EventMachine.defer and ActiveRecord connection pool?
- From: Chuck Remes
- Re: EventMachine.defer and ActiveRecord connection pool?
- References:
- EventMachine.defer and ActiveRecord connection pool?
- From: Artūras Šlajus
- Re: EventMachine.defer and ActiveRecord connection pool?
- From: Chuck Remes
- EventMachine.defer and ActiveRecord connection pool?
- Prev by Date: Re: EventMachine.defer and ActiveRecord connection pool?
- Next by Date: [ANN] First release of Automations: au3
- Previous by thread: Re: EventMachine.defer and ActiveRecord connection pool?
- Next by thread: Re: EventMachine.defer and ActiveRecord connection pool?
- Index(es):
Relevant Pages
|