Timeline for Retry Architecture
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2018 at 23:47 | comment | added | Max | I'm glad the answer helps. Feel free to accept it as the answer since it helped and there are no other answers! Thanks. | |
| Jan 16, 2018 at 23:44 | comment | added | Max | @Husain You can use the peek method in C# to get the next element in the queue without removing it. You could then remove the task from the queue only after it is cancelled or completes. But it is probably better to retry multiple tasks concurrently, in which case you can iterate through the queue. Then like before only remove the element from the queue once it finishes. Maybe you change the state of the notification to "pending" while it is being processed. | |
| Jan 16, 2018 at 23:20 | comment | added | Husain | Thanks you very much @max for the elaborate answer. It helps much than a small comment. But here is my problem which I want to solve. If I am following your reasoning here, once the retry instance takes the task from the queue, the task is poped from the queue. So, If I come and turn off the retry instance, the task from the queue is lost. Is there a feature on queue that keep the message until processed or something like that? Is there a way to make sure even the task in process is not lost? | |
| Jan 13, 2018 at 19:12 | history | edited | Max | CC BY-SA 3.0 | added 180 characters in body; added 1 character in body; added 51 characters in body; added 11 characters in body |
| Jan 13, 2018 at 19:02 | history | answered | Max | CC BY-SA 3.0 |