It hasn't been reported before.. The use cases I have seen were not as deep as you had.
We didn't have a burst considered when developing... as fast as you had. I've made this improved some time ago... it had been improved already..
Do you have any ideas on how to improve it?
Our thought is to keep the scheduledReferences list sorted by scheduled delivery time (ascending). This would allow terminating the traversal in run() as soon as you see an element that has a scheduled delivery time greater than the current message. Of course keeping the list sorted would require cycles during the scheduling phase, but the critical point is that keeping it sorted will greatly increase the performance at the time the events are consumed.
Does this seem like a good approach? Is there something we are missing?
Yeah, makes sense... can you open a JIRA?
I actually thought that this scanning would be giving up...
I thought about something like append after the right place on the linked List. I would have to spend some time...
If you can provide a patch it would be great as well.
Yes, I'll open a JIRA. We are currently testing our own version of 2.2.24 with this fix. Once we have a solid fix I'll let you know.
A simple fix would be to compare top and bottom of the list.. if it doesn't fit any it would then either do some sort of Btree or a scan.. most of the times I think you would schedule at a fixed rate.. so that would always go to the end of the list.
With that then you could stop iterating instead of the whole list on delivery.
thanks for the JIRA