You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Peter M. Goldstein" <pe...@yahoo.com> on 2002/10/15 03:42:12 UTC
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Harmeet,
> this
> > latest change. It appeared to fix the known problem, right up until
the
> > point when his system died. Don't know what the cause was. IF this
> code
> is
> > OK, it improves upon the DefaultAvalonScheduler for James' needs.
>
> I am planning to checkin Scheduler implementation in the next few
hours,
> but
> keep it disabled. i.e I won't swap scheduler impl in assembly.xml yet.
> Hopefully as others test and there is more validation/improvements in
the
> next couple of days this will be enabled.
>
> Noel's testing and my own testing indicates a significant improvement
> before
> and after fix and it fits easily with current structure.
-1
Noel's test makes it clear that even with the change, your code crashes.
Period. He has not reported a successful run through of your code.
Your server crashes. Always. And there are obvious flaws (which Noel
expanded on) in your posted code.
> The beauty of using the same abstraction is that there is a simple
backoff
> or switch strategy available.
> Once we are over this release let us talk about switching
abstractions. I
> have nothing against changing to WatchDog or another scheduler
> abstraction,
> but I would like to see a demonstrable benefit. i.e performance,
> scalability. I think sharing code with commons is good esp. if there
is
> also
> yields a system wide benefit.
>
Harmeet, I'm not going to go over this again. There are fundamental
flaws with the scheduler idea. We've gone over this. There are
literally dozens of pages on the web that discuss the problems with high
contention in systems like the one you're proposing. For example,
http://www-106.ibm.com/developerworks/java/library/j-threads2.html
To quote:
"Contended synchronization can have a serious impact on the scalability
of your programs. Even worse, unless you perform realistic load testing,
contention-related performance problems do not always present themselves
during the development and testing process"
The specific issue is that the scaling is non-linear. Contention causes
scaling like k! when you have k contending threads. Since the code
you've posted has a double lock acquisition, and does expensive
operations inside the synchronized area, it can be expected to occupy
uncontended at least 2-3% of the request time (that's an extremely
conservative estimate). Do the math. For 20 connections, or
potentially 80 shared over multiple servers, that's disastrous.
The contention made that 2 threads per connection doesn't scale I can
only attribute to ignorance of standard server architectures. Most of
the standard web servers (IPlanet, Apache) allow or require the use of
multiple threads per connection in different configurations. One of the
somewhat dated but standard texts on Java server development
(Server-based Java Programming by Ted Neward) discusses the use of
futures and other techniques that involve multiple threads per
connection. They all scale. This is how you write a server in Java.
Aside from all of this, it still doesn't address the issues I brought up
in my first email. That is, centralized logging and fail on start
behavior in the servers.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> And, of course, there are still those
> synchronization and the delays it causes on ALL OTHER waiting threads.
Believe it or not, I have a fix mitigate sycnronization issue.
It is really simple and implicit in your messsage. :-)
Harmeet
PS: good email.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Peter, take a look at Danny's email. Maybe there is a message for both of
us
> there.
Depending upon which e-mail you're refering to, absolutely. Let's please
chill the rhetoric and focus on the code. There are code defects in the
various implementations. Tell you what. The first person to submit
completely bug free code on the first effort, let me know.
> there was talk a year or more back about getting rid of Servers [and]
> only have handlers.
Each has a specific role. If anything, Server's weren't being used for the
job that they ought to play, and handlers were doing too much. Servers
should be responsible for per service issues. Don't suggest class data on
handlers, because I still want to be able to instantiate more than one
instance of a particular server, e.g., on different binding addresses.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
> We've been working on this code for months, and it has been stated over
> and over again that this change was coming. Harmeet has simply jumped
> in at the end of the release and started playing obstructionist games.
> And quite honestly, that's what I find wearisome.
Peter, take a look at Danny's email. Maybe there is a message for both of us
there. If you think I am being obstructionist, please think some more. I
don't know you and haven't obstructed you before.
Sorry if you feel that way.
Yes, it is true I came in late. If you had concrete proposal and voting was
already done on this, it would not have been a issue. Also, I told you
earlier that there was talk a year or more back about getting rid of Servers
(as they did very little) and only have handlers. Should I say based on that
that you have came in late, wasted time and have gone in the wrong
direction. Think about what you would think about such a statement. That is
probably my response to your statement. :-)
There is no automatic end to a bad loop.
regards,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
As Noel points out, a number of emails from this morning are coming
through now. Yahoo and I had a bit of a disagreement - I wanted them to
send my email and they didn't feel like it. I apologize for the
multiple postings and whatnot.
--Peter
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Tuesday, October 15, 2002 6:19 PM
> To: James Developers List
> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring
service
> code-P
>
> I see that all of your old e-mails from 12 hours ago are finally
coming
> through??
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
I see that all of your old e-mails from 12 hours ago are finally coming
through??
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> > > This is actually incorrect. Danny's issues were due to
> > > misconfiguration, not code errors. There was one errant notify(),
but
> > > it did not cause the problem Danny observed.
> >
> > This is not what Danny said in his last mail on testing. Did he
retest ?
>
>
> Woah, hey.. I'll test patches, but I'm *not* going to re-configure by
> myself to make them work, in case the effore I put in biases me to one
or
> other solution.
> If a patch nees a certain configuration to perform correctly, patch
config
> as well.
As explained previously, the config was patched. You didn't pick up the
patch from the CVS head. For the same reason you didn't pick up the
assembly.xml patch. Phoenix doesn't overwrite either the assembly.xml
or config.xml in a running system when you deploy a new .sar.
As far as the configuration change biasing thing to make it work, that's
not a fair statement. It would be like me arguing that the fetchpop
code obviously didn't work being I didn't adjust either my assembly.xml
or config.xml to take account for it. Some patches require
configuration changes. That's just how it is. You want to run the old
code (or Harmeet's scheduler) with a 100 thread max you'll see the exact
same problem you would at 40 (old code will crash from OutOfMemory,
Harmeet's most recent scheduler still won't actually do anything)
> And guys.. frankly, why the hell can't we have a watchdog replacement
for
> the scheduler , and leave out the refactoring?
Frankly, what refactoring? The changes are minimal. We're eliminating
a superfluous class and replacing a Cornerstone dependency
(AbstractService) with a better, more James specific solution
(AbstractJamesService). We've made much greater changes in the code
with far less of a fuss.
We've been working on this code for months, and it has been stated over
and over again that this change was coming. Harmeet has simply jumped
in at the end of the release and started playing obstructionist games.
And quite honestly, that's what I find wearisome.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'll test patches, but I'm *not* going to re-configure by myself to make
> them work
Don't sweat it. I'm running the code on a linux server, with a separate
linux server hammering it. There definitely appear to be issues that
wouldn't show up on a connection limited Win2k workstation. I'll stick with
it until everything is resolved.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> Waiting for Harmeet to send me a version with his code fixed.
Here you are.
Thanks for pointing out the mistake. Should have been
!Thread.currentThread().isInterruped()
instead of
Thread.currentThread().isInterruped()
If you wan to run a faster comparison and simulate artifical heavy load on
server you can
- reduce the James mx heap.
- reduce thread pools.
A simple test would be to send 75% of max thread pool size for a handler.
Also the patched James distribution is at
http://www.kodemuse.com/pub/harmeet/james.zip
Danny would you be able to try this too.
thanks,
Harmeet
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> simply this, I'll run identical tests on the same
> hardware using "clean room" builds created exactly
> according to this process.
That is pretty much what I'm doing, except for now I am working from a
binary that I've asked them to send me, rather than doing a build. It is a
tradeoff, but this means much less work for me.
I've already gone a few iterations with Peter's code today. Peter and I
have identified a problem that the interaction with the thread is causing
monotonically increasing pool size. Not isolated or fixed just yet, but
identified. Waiting for Harmeet to send me a version with his code fixed.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Danny Angus <da...@apache.org>.
> Danny, how do you propose testing on your end? I don't think that
> reconfiguring "by yourself" is called for, but Peter believes that he DID
> patch config. Are you willing to post your XML files either to the list or
> perhaps to Peter? If there is a problem to be fixed, it first starts with
> properly identifying the problem, and then correcting it.
simply this, I'll run identical tests on the same hardware using "clean room" builds created exactly according to this process..
1/ delete local copy of James
2/ check out HEAD
3/ apply patch(es) or un-zip archive onto checked out HEAD
4/ build dist-lite
5/ run built james
6/ run test
..without my hacking anything, thus if a potential solution is incomplete or requires additional config changes it may fail my simple criteria because of that.
This because it makes the test conditions easy to duplicate.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'll test patches, but I'm *not* going to re-configure by myself to make
them work
> If a patch nees a certain configuration to perform correctly, patch config
as well.
Danny, how do you propose testing on your end? I don't think that
reconfiguring "by yourself" is called for, but Peter believes that he DID
patch config. Are you willing to post your XML files either to the list or
perhaps to Peter? If there is a problem to be fixed, it first starts with
properly identifying the problem, and then correcting it.
> why the hell can't we have a watchdog replacement for the scheduler,
> and leave out the refactoring?
Shooting from the hip, putting Andrei's and Peter's implementation under the
Scheduler interface means writing a set of adapter classes, and then doing a
hashmap lookup each time you want to reset the timer (because the Scheduler
interface specifies that you don't interact with a timer, you interact with
a manager of timers). If the issue is about implementation, I don't see
that this buys us anything.
My argument is the opposite: put both of them under the Watchdog interface,
for reasons I've stated before.
For example, the vital issue of testing. We need to test both the
non-timeout and timeout cases work, as I've done when writing the same type
of code in the past, and would consider normative for any such class.
For example, the run method for Harmeet's scheduler is:
public void run() {
while ( Thread.currentThread().isInterrupted() ) {
...
}
}
Hello! While IS interrupted? For those not familar with this method:
* Tests whether the current thread has been interrupted.
* @return true if the current thread has been interrupted;
* false otherwise.
In other words, this code exits immediately upon startup. Even if we don't
spot errors like this desk checking, this is why we need to unit test as
much as possible, and test BOTH sides of conditions.
We can more easliy unit test the Watchdog interface because we can easily
code a standalone driver than anyone can run on any implementation of it.
Andrei and Peter's Watchdog code is standalone. Harmeet's code could also
be standalone, at the core. His core implementation doesn't really need
Avalon Frameworks.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Danny Angus <da...@apache.org>.
> > This is actually incorrect. Danny's issues were due to
> > misconfiguration, not code errors. There was one errant notify(), but
> > it did not cause the problem Danny observed.
>
> This is not what Danny said in his last mail on testing. Did he retest ?
Woah, hey.. I'll test patches, but I'm *not* going to re-configure by myself to make them work, in case the effore I put in biases me to one or other solution.
If a patch nees a certain configuration to perform correctly, patch config as well.
And guys.. frankly, why the hell can't we have a watchdog replacement for the scheduler , and leave out the refactoring?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [Contention] can be fixed in impl. Will post code.
Will review when you post it. Is this holding up your test build?
> This is not what Danny said in his last mail on testing. Did he retest?
I have no idea what the problem was with Danny's test, but I have tested
Peter's code for hours and hours with 100s of 1000s of messages, whereas
something in Danny's configuration apparently prevented it from starting. I
am about to start another test of Peter's server running on one of my local
systems. Still waiting for your test build.
And, mind you, your code consistently broke within three minutes until I
helped you to fix it, so it is disingenuous to denigrate Peter's code
because of one report.
> I want a formal proposal and voting to change the abstraction. Please make
a
> proposal
I have done so. And you are making the scope (as opposed to the
oppportunity) of this change to be much heavier than it is.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
And, of course, there are still those
> > synchronization and the delays it causes on ALL OTHER waiting threads.
>
> Noel is entirely correct here.
Not completly . Can be fixed in impl. Will post code.
> This is actually incorrect. Danny's issues were due to
> misconfiguration, not code errors. There was one errant notify(), but
> it did not cause the problem Danny observed.
This is not what Danny said in his last mail on testing. Did he retest ?
>
> As I noted in my original patch submission, testing was still underway.
> I caught the errant notify() in the load test, and corrected it. Piece
> of cake. And that's exactly why one does testing.
Please post the fix. Would be nice to send patch fixes esp. for this change
to dev list.
>
> Of course.
>
> > > 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.
>
> I'm fine with the compromise. I've already written a factory class to
> provide this functionality and altered the handlers as necessary. I
> can't imagine why anyone would use the centralized Scheduler, but
> whatever. As long as I can run a proper timeout mechanism off the code
> base, I'm happy.
I want a formal proposal and voting to change the abstraction. Please make a
proposal and if others committers are comfortable changing abstractions in
this release I will not say nay. My preference is to delay refactoring, but
as I said I'll go along.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> 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.
Noel is entirely correct here.
> > (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 dl@cs.oswego.edu. 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.
Indeed. As Noel pointed out to me, the most similar class can be found
at
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Tim
edCallable.java
The major difference in purpose from the Watchdog idea is that the
TimedCallable is not intended to be reset. So Watchdog is a little more
complex. But note the similarities - multiple threads (2) in each
implementation, no centralized map to cause contention. Doug Lea is one
of the world's experts on Java threading. Personally, I trust that he
knows what he's talking about.
> > If we had release with your patch and Danny had not tested,
> > there would have been a significant regression and no easy
> > implementation swap.
This is actually incorrect. Danny's issues were due to
misconfiguration, not code errors. There was one errant notify(), but
it did not cause the problem Danny observed.
As I noted in my original patch submission, testing was still underway.
I caught the errant notify() in the load test, and corrected it. Piece
of cake. And that's exactly why one does testing.
> 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.*
Of course.
> > 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.
I'm fine with the compromise. I've already written a factory class to
provide this functionality and altered the handlers as necessary. I
can't imagine why anyone would use the centralized Scheduler, but
whatever. As long as I can run a proper timeout mechanism off the code
base, I'm happy.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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 dl@cs.oswego.edu. 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message ----- Peter,
Here is a snippet from Noel's email
> > > latest change. It appeared to fix the known problem, right up until
> the
> > > point when his system died. Don't know what the cause was. IF this
> > code
> > is
> > > OK, it improves upon the DefaultAvalonScheduler for James' needs.
My machine crashed that is why system died. Not sure why but it does that
once in while.
Before and after test here was the change
Danny test with 20 concurrent threads and no upper limit on the number of
connections crashed james within a few mins.
After the fix, it did not crash for several hours. Noel did note a
significant improvement too in his mail.
>
> Harmeet, I'm not going to go over this again. There are fundamental
> flaws with the scheduler idea. We've gone over this. There are
> They all scale. This is how you write a server in Java.
Test for scale and performance with your fix and with mine and see the
difference.
As far as I can tell from mails there is a independent system improvement
verification with my fix and a negetive improvement verification with your
fix.
Maybe you should do a test run or two.
Regarding changing and your patch, For now
-1
Reasons.
> Once we are over this release let us talk about switching abstractions. I
> have nothing against changing to WatchDog or another scheduler
abstraction,
> but I would like to see a demonstrable benefit. i.e performance,
> scalability. I think sharing code with commons is good esp. if there is
also
> yields a system wide benefit.
Regarding contention and exepensive synchronized methods.
(a) I am improving those to some extent.
(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.
regarding
> And there are obvious flaws (which Noel
> expanded on) in your posted code.
In my last email I have said that I am fixing flaws Noel has found and would
appreciate more feedback.
Please note Noel said 'IF this code is
OK, it improves upon the DefaultAvalonScheduler for James' needs.' So far
no one has mentioned correctness problems. His suggestions are performance
improvements on a fix that improves James.
BTW. I am not planning on fixing James handlers till there is more
independent verification. This is again from my last email.
What is your -1 is for ?
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Noel's test makes it clear that even with the change, your code crashes.
Not entirely true. I was never able to successfully test his code because
his server crashed and he wasn't willing to let me test further. I've asked
him to send me distribution tree of his code so that I can run the tests
locally, as I'll be doing with yours.
> And there are obvious flaws (which Noel expanded on) in your posted code.
Some of them are the natural consequences of managing a priority queue.
Others are just bugs that he can fix. There is a limit to what he can do
about the contention issues.
The real issues are those that we've explained regarding the approach
(algorithm). We've both explained the issues, quoted sources, shown the
math. I suspect that I can't put enough load on a socket limited Win2K
system to demonstrate the resource contention, especially through my cable
modem, but that doesn't change the math. Frankly, I don't want to keep
going over this territory. Let's just put both implementations under the
Watchdog interface, so that we can resolve this issue by allowing him to use
the implementation that he wants to use.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>