Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements connection pooling by adding
HasFaktoryPool
which canbe used to acquire a
Producer
, which is just aClient
, which is justa
Connection
.I chose the name
FaktoryPool
(instead ofFaktoryProducerPool
) fortwo reasons, one conceptual and one practical:
Producer
wrapper overClient
isunnecessary. It adds nothing and a
Producer
could just as easily beused for any communication with Faktory, to produce, consume, batch,
track, etc. So I consider this a "pool for Faktory" and no
specifically "for Faktory producers". (Same reason we call it
SqlPool
and notSqlInserterPool
orSqlQuerierPool
.)FaktoryProducerPool
infreckle-app
, that thisis a generalization and upstreaming of. Changing the name along the
way makes the errors clearer and more easy to deal with when
converting downstream applications.
I have branch migrating backend from freckle-app to this and it's quite nice. There
are a few differences from freckle-app in my implementation here that led to that:
perform
andbuildJob
make conversion simplertakeProducer
made the necessary-evil of using the pool inConduitT
much nicer