Hey Ole,

> > since we have a similar issues (you with Timeouts, me with 
> TimerTasks), I
> > would like to go more in deep, if you don't mind.
> 
> Not at all. Very interesting discussion.

Indeed !

> The only problem I see with this is that most transactions are a lot
> shorter than the timeout value so the queue could become quite big.
> Consider a system doing 20 transactions per second, and almost all
> transactions being very short but a few being long. Oleg Nitz would
> like to set a 10-30 minute timeout as he has some long running
> transactions. In case of a 30 minute timeout we would have
> 20*30*60=36000 entries in the queue, most of whom would be cancelled
> and waiting to reach the queue head. And we cannot start reusing
> Timeout instances until they are out of the queue.

I see.
Is the following idea valuable in your opinion ? 
Say you have to wait 15 minutes for the first timeout to expire; you remove
it from the queue and reinsert it immediately; in the meanwhile many
timeouts created after it have been canceled (and when you cancel a timeout
you put its expiration time to be less than now so that it is "expired"), so
that the reinserted 15 minutes timeout will be now not on top of the queue
(because all canceled ones "expires" before it) but in the middle. Then the
normal doWork() will extract all canceled timeouts until it gets again on
the 15 minutes one. You can decide to remove and reinsert it depending on
the time left for it before expiring.

Anyway, this discussion is to clarify to myself the timeout mechanism for
transactions, and to have a comparison for the TimerTasks. But if you can
avoid log(n) complexity when canceling a task (given the performance
constraints for the tm package) from the ideas of this discussion thread,
I'm glad share those ideas. 
Maybe will help adding a remove method on the Heap class I'll check in (now
it is not present). 
Maybe better leave timeouts as they are. 
Maybe better settle this thoughts, take a pause and rethink again.
Anyway thanks for your time.

Bests,

Simon

Reply via email to