Steven Harman

@vanstee or @alindeman Do either of you have any feedback? Or any ideas how we might be able to get some integration tests around this? Threading is always a bit...

re: thread-safety vs. performance. Typically connection pools are about performance - they allow reusing connections rather than having to constantly establish and clean up connections, which can be quite expensive....

So the problem with synchronizing is that it too is slow when you have multiple threads each needing to push and establish those connections. It seems like this solution might...

@kbrock and @vanstee I know it's been a while, but is the consensus (for now) to **not** add connection pool support directly to Grocer, but instead wrap connections in a...

@vanstee @kbrock @kyledrake @aleph7 I want to try to clear some things up, get us all on the same page, and then propose a possible, not-waiting-after-every-write, solution. **TL;DR**: avoid waiting...

One thing to keep in mind - the producer/consumer model has a very nice, and desirable, side benefit of also being thread safe. The read-after-each-send-and-once-more-at-the-end is not, in and of...

I should have been more clear - I meant that from the consumer side, this would make `Grocer::Pusher` thread-safe. I am making the assumption that the `send` queue is thread-safe...

> We instantiate a separate Pusher for each thread, so the overall thread-safety of the class isn't a concern. Depending on how you're sending messages, you need to be careful...

There hasn't been any change to Grocer - I've become quite busy with other projects, as has @vanstee. I still believe an internal producer-consumer is the way to go, but...

You are correct - we have an `ErrorResponse` class, but don't currently use it. In #14 you'll find a lengthy discussion and several proposed solutions for not dropping messages and...