Synchronous producer - Handle acknowledgements of sent PUB/MPUB/DPUB messages #52
Conversation
|
The first step has been to gather read/write operations in a single thread in order to share information between both operations in an easier way. |
|
Second step, not sure it's the best implementation but a |
…and specs are good
|
I think the PR is ready, the API hasn't changed, the behavior either, but the internals have slightly been updated as there is only one read/write loop based on a select. The code is ready for review. All the old specs are passing correctly. |
Soulou
force-pushed
the
feature/51/acknowledgement
branch
from
35dd4b2
to
f371fea
Compare
Soulou
changed the title
|
@bschwartz a small follow up to get your input on this. |
Soulou
force-pushed
the
feature/51/acknowledgement
branch
from
1e2530f
to
69a5a48
Compare
…onous producers, asynchronous never return exception
Soulou
force-pushed
the
feature/51/acknowledgement
branch
from
69a5a48
to
fe8f9e9
Compare
Soulou
force-pushed
the
feature/51/acknowledgement
branch
from
db2bb92
to
d869114
Compare
This commit has been inspired greatly by what is done in the official golang driver. To follow the recommandations of the NSQ team, the producer is not able to get initialized with nsqlookupd URL, a producer is connecting to only one NSQd instance, not several. - The producer is keeping a list of transactions to wait for the return value of NSQd. - A new class `NsqdsProducer` can be initialized with multiple NSQds addresses and will apply a strategy to write messages: - `Nsq::NsqdsProducer::STRATEGY_FAILOVER` Always send on the same nsqd except if not available, then get to the next one - `Nsq::NsqdsProducer::STRATEGY_ROUND_ROBIN` Apply round robin over the different available nsqds
Soulou
force-pushed
the
feature/51/acknowledgement
branch
from
2571e34
to
198ddd5
Compare
|
There is a race condition on the failing tests. if The bug exists on |
|
This is looking good @Soulou. I should have time Friday for a more in depth review. In the meantime, do you think you could also update the README to explain the new functionality? Also, if you have some ideas of how to fix the spec issue that you mentioned also exists on master, that would be great! |
|
Thanks @bschwartz I'll update the README and try to fix the spec, |
Soulou
changed the title
|
For info, this PR is already running in our production environment, so far so good. |
… received by SUB before sending RDY commands
|
@bschwartz done :) |
The goal of this PR is to update the library to ensure that an exception is raised if an error happens when a message is sent to NSQd.
This is a work in progress, all the inputs are welcomed.
Related #51