how to retry for both sending msgs to /rmb-remote and /rmb-reply will be handled.

[sameh-farouk]

how to retry for both sending msgs to /rmb-remote and /rmb-reply will be handled by RMB. this wasn't handled well in the current version, see here.

we need to agree on a flow to deal with that, you suggest dropping the retry queue from the RMB previous logic, and retrying synchronously when sending the message? and keep in mind that we would need to wait a bit between retires, for handling temporary network issues.

[muhamadazmy]

Yes, it might not be clear from the specs, the http workers once they pick up a job (either to send to /rmb-remote, or /rmb-reply) will need to retry with small waits between the retires max or ($ret) number. Then if failed log or report to the caller (depends)

It will not be an issue when we have multiple (can be many) workers if some of them get blocked waiting others can handle traffic. I think it's way cleaner and easier to implement than a retry queue.

We can discuss pros/cons and see which approach is better.