QueueAdapters now does lazy lookup

[tamird]

@rafaelfranca @jeremy

[rafaelfranca]

Does we need to cache?

[tamird]

I think so - in particular, we may have an adapter that carries a connection object on it - we would not want to create multiple identical connections

[thedarkone]

Correct me, if I am mistaken: isn't QueueAdapter.interpret_adapter not a hot path? Why are we rolling out a custom caching mechanism, why not simply use a plain mutex around the whole #interpret_adapter method?

Also, does setting QueueAdapterClass.queue_adapter= need to be thread-safe? The general rule of thumb in Rails is that class-level configuration assignments are on only to done during a single-threaded boot sequence?

Is there a reason you're not using ThreadSafe::Cache (ie: cache = ThreadSafe::Cache.new; cache.compute_if_absent(some_key) {lookup(name).new(*adapter_args, &block)})?

[tamird]

Correct me, if I am mistaken: isn't QueueAdapter.interpret_adapter not a hot path? Why are we rolling out a custom caching mechanism, why not simply use a plain mutex around the whole #interpret_adapter method?

Probably true - just erring on the side of caution.

Also, does setting QueueAdapterClass.queue_adapter= need to be thread-safe? The general rule of thumb in Rails is that class-level configuration assignments are on only to done during a single-threaded boot sequence?

Again, probably true - just erring on the side of caution.

Is there a reason you're not using ThreadSafe::Cache (ie: cache = ThreadSafe::Cache.new; cache.compute_if_absent(some_key) {lookup(name).new(*adapter_args, &block)})?

Just plain ignorance. I'll switch to that.

[jeremy]

We can use a @cache ivar, no need for private reader/writer methods

[tamird]

changed

[tamird]

Removed the caching - I'll save it for a future PR.