> Test for scale and performance with your fix and with mine and see the
> difference.
This isn't a competition. Let's drop the egos, compromise MY WAY <<grin*>>
and get back to the work we need to do to put out a release. :-)
> What would be an appropriate scheduler interface
> for James timeout monitoring ?
LOL That is like the old joke of "What color is Grant's White horse?" You
are already saying that it is a Scheduler interface. Those are two
DIFFERENT notions.
> I did think JDK folks would have a better implementation then they had
They have a fine implementation for the purpose intended.
> Regarding contention and exepensive synchronized methods.
> (a) I am improving those to some extent.
But you cannot eliminate them. That is simply the nature of the beast. I
haven't counted the bytecodes for the operations, but I believe that even if
there were no synchronization overhead issues, there would still be no way
to be within 1000 times the overhead of resetting the timer in the
dual-thread implementation. It simply takes a lot more time to manage the
shared data structures. And, of course, there are still those
synchronization and the delays it causes on ALL OTHER waiting threads.
> (b) There are ways of improving it more. Doug Lea has documented a few
ways
> and has a library to help eleviate problems you are mentioning.
I am familiar with his work, and I don't believe that you are correct. His
e-mail address is [EMAIL PROTECTED] Would it help if we pull a Woody Allen,
and ask Doug Lea to stop by? ;-)How's about if I point out that Doug Lea's
own watchdog code uses two threads per operation? Please read his
implementation, not just his interfaces.
> Please note Noel said 'IF this code is OK, it improves upon
> the DefaultAvalonScheduler for James' needs.'
Excuse me, but I said *IF*. I do not have an answer to that. And I said
that it would IMPROVE upon the DefaultAvalonScheduler for James' needs. I
did NOT say that it was the correct solution. I am WILLING to offer it as
an alternative for someone who wants to use it, rather than bog down further
on this issue.
> Peter, I have never said that we cannot change the interface, however I
want
> I want a backoff strategy if there are issues.
We have one.
> If we had release with your patch and Danny had not tested,
> there would have been a significant regression and no easy
> implementation swap.
We aren't supposed to put out code without testing. And YOUR code was even
worse than his until I tested it, and you improved it. Code is rarely
perfect as first written. Not even mine.*
> Let us talk code and results rather than take up mutually exclusive
> positions.
I have been. I have proposed a compromise that allows the choice of either
implementation. Peter is willing to do it. The code is already written to
allow this compromise. Please accept it.
--- Noel
*Yes, I am trying to be funny. We all have egos.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
