boss_cache_adapter behaviour

[Cuong Thai]

Hi team,

According to boss_cache_controller, CB only calls 

init/1, get/3, set/5, delete/3 of boss_cache_adapter behaviour.

CB doesn't use start, stop functions of boss_cache_adapter behaviour, right ?

(My ets_cache is buggy, I'm fixing it)

Regards,

Cuong Th.

[Cuong Thai]

Hi team,

I found that in boss_cache:start/1

start/1 of boss_cache_adapter is called

start(Options) ->
    AdapterName = proplists:get_value(adapter, Options, memcached_bin),
    Adapter     = list_to_atom(lists:concat(["boss_cache_adapter_", AdapterName])),
    Adapter:start(Options),
    boss_cache_sup:start_link(Options).

then boss_cache_sup supervisor is started for using poolboy. Each worker is boss_cache_controller. boss_cache_controller is gen_server. My ets_cache is also a gen_server that provide (synchronous) get and (asynchronous) set, delete. After understood, I can fix my ets_cache.

But there is abuse of using poolboy here. While erlmc (memcached_bin adapter), redo (redis adapter) are gen_server, too. They also provide synchronous get, asynchronous set, delete, why we use more gen_server (boss_cache_controller) in the middle between boss_cache and (memcached, redis, ets) adapter ?

I suggest that boss_cache calls (get, set, delete) APIs of (memcached, redis, ets) adapter directly, no need boss_cache_sup (i.e. no need poolboy).

If there's something wrong or stupid, please correct me!

And I though poolboy abuse issue causes CB not obey canceled requests.

Regards,

Cuong Th.