Hi
I asked on the slack channel but didn't get any feedback there so I thought I would ask again here.
Looking for some guidance on consuming messages from rabbit. We have clients that are connected to us via TCP sockets. We are essentially receiving the message from rabbit MQ, performing a little bit of translation and metrics on it and the forwarding it on via TCP sockets. The protocol between us and the clients caters for messages inflight (window sizes) and timeouts and retries, which is similar to rabbit's protocols with prefetch counts and acks and nacks.At the moment we were just receiving the message to consumers with auto ack and internally buffering the message for the client. When the client disconnects we were taking whatever was left in the internal buffer and pushing it back to the same rabbitMQ via basic publish (using a different channel and connection to avoid threading issues) before disposing of the buffer.My question is, seeing that there are many parallels between RabbitMQ server to consumer protocol and between us and our clients, could we leverage off rabbitMQ more and do less ourselves. Instead of auto acking the messages we only ack once the client down stream acks a message from us. And if they don't ack the message after 30 seconds we Nack the message back to rabbit MQ. We could also use the retry header in the rabbit package and stop after 3 attempts. My only concern is that we have no control over our clients and the quality of their implementations. Also they are not within our infrastructure so we have to deal with the internet and it is rockiness. Often the time between us and an a client that is not performing well can be up to 30 secs. A well performing client we usually expect an ack within a few 100 ms.Can we use the idea of manual ack to rabbit when we have an ack from the client even with the consideration of possible 30s delays? Are there any performance/reliability or correctness issues we should consider? Is this against best practices in anyway?
Regards,