Ian Cass wrote:
Luis Neves wrote:
If all else fails I will have to figure out a way of doing this at
the protocol level.
Surely all you need is sensible protocol level flow control?
It's the "sensible" part that I'm having trouble with :-)
Do this:-
Get your sender to send a small number of simultaneous requests (your flow
control window) - say 5. Then make the sender stop sending until it's got a
response, keeping 5 outstanding requests on the wire. You should then
implement a similar setup on the consumer just to handle badly behaving
clients, reading total <window size> number of msgs before you suspend reads
and resuming reads when you send a response.
Ok... but there is a big difference between:
- not delivering a message.
- delivering a message but for some reason don't receive the ack.
The reason I mention this is because I'm experimenting with something like you
suggest and I'm having doubts on how to deal with producers that send a batch of
messages and are terminated before receiving the ack... when the producer comes
up it tries to redeliver the messages and the result is duplicate messages in
the consumer end... how do you deal with this problem?
I've not been able to find a simple solution for this, it's getting complex and
I don't have a lot of confidence in the code.
It sounds much simpler just to block the producer if the consumer suspend the
reads... but maybe this isn't possible.
Thanks!
--
Luis Neves
