I'm about to create an application that will spawn tasks of about 100,000 requests expecting responses. I'm wondering whether to use a static reply queue or temporary queues. There is only one client requesting and only one server replying. The use case for the client will be to spawn a task about once a day.
I'm thinking I want to use temporary queues for the responses but I'm wondering if there is a reasonable limit to the amount of temporary queues or how long I would want to keep them open.
Some replies make take days to come back or never come back so I would time out the temporary queues after about 3 days.
My immediate thoughts are that 3 days stretches the definition of temporary. In that time you want to survive both requester (producer, who also consumes the response) and broker outages. Temporary queues are a contract between the subscriber and the broker - if one of them goes down, the temporary queue disappears and the responder will get an error when they attempt to reply on that queue.
I would use static queues in this instance - you will need to implement a layer for correlating responses back to requests in your requester, but you would need to do that anyway if you want to survive the outage of that process (probably by storing additional state in a database).