3 ms·
You update the status of each message when it's acked. You show a live count of messages sent / total messages on the screen where the user sent it. 2000/5000
by mattcaldwell 7y ago
You update the status of each message when it's acked. You show a live count of messages sent / total messages on the screen where the user sent it. 2000/5000 sent... if those 3,000 never get sent, it will be obvious to the user.
If you want the user to be able to try re-sending, you can provide that functionality... you'd need to "cancel" the outgoing messages using a separate queue, re-sending when each cancellation is acked.
- sk5t 7y agoIt seems as though you might be describing a process with state stored in an RDBMS or the like. Which, while a perfectly reasonable approach, is not much like the initially-described case of firing a bunch of "send email to foo@example.com"-type messages into a queue, subsequently to be drained and acted upon by possibly-remote workers. What I am trying to uncover here is how one might expect to use a queue, on its own, to support a very-much-non-idempotent interruptible non-transactional process. Also, what does it mean to "cancel" an already-sent email?
- ww520 7y agoQueue is a component of the solution for this kind of non-transactional process, not the entire thing.
- floriol 7y agoI have yet to use it, but isn't Java EE's Batch API is used for things like this? It tracks the progress of long running tasks (e.g. the index of the current mail) and can continue from the last sent index in case of some error.