Poolboy - was: CB doesn't obey canceled requests

[David Welton]

Speaking of poolboy... I wonder if there's something better that we
could use for certain work loads.

Poolboy is fine if you have a pretty good idea of what kind of work
load you want to handle, but it looks like the authors are not
interested in making it handle more dynamic/complex situations:

https://github.com/devinus/poolboy/issues/30#issuecomment-26024042

If I read what he's writing correctly, he thinks something like CB
should somehow fetch a "connected" worker. Or randomly fetch workers
until it finds one that is connected? But then what's the point? To
me that all sounds more complicated than adding a bit of logic to more
gracefully handle extra workers over a certain limit.

Thoughts?
--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

[Cuong Thai]

Hi David Welton, Евгений,

Could you review my suggestion between boss_cache and boss_cache_adapter_{memcached_bin, redis, ets} ?

Regards,

Cuong Thai.

[David Welton]

Hi,

I'm not much of an expert in the cache stuff, unfortunately, so don't
have much to say. Is it something you can write some tests for, to
show how things should work?

> --
> You received this message because you are subscribed to the Google Groups
> "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chicagoboss...@googlegroups.com.
> Visit this group at http://groups.google.com/group/chicagoboss.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chicagoboss/a5248dc4-e454-41b1-bae4-167d59172fa3%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Cuong Thai]

Hi David,

Ok, I don't involve with source code.

Just say we have boss_cache process uses cache application. cache application has 1 gen_server, it handle GET/SET/DELETE message (gets key, returns value; set {key, value} entry; delete key).

There are 2 solutions:

1. boss_cache process send message to cache application directly.

2. boss_cache process creates poolboy supervisor, its children are poolboy workers.

boss_cache sends mesages to poolboy, it checks out worker. The worker sends message to cache application. Poolboy checks in the worker.

CB is using (2) solution. Is (2)  better than (1) ?

For asynchronous SET/DELETE message, obviously we don't need poolboy.

For synchronous GET message, we send message with timeout.

As Even mentioned in roadmap, he uses poolbooy to resolve bottleneck issue. Maybe I don't understand poolboy implementation ?

Regards,

Cuong Th.