> Noel's testing and my own testing indicates a significant improvement
before
> and after fix and it fits easily with current structure.
Excuse me, but this is a misrepresentation of what I said. It ran fine
right up until the time your server crashed. I do not know why, and you
were unwilling to allow me to test it again. In Peter's case, we ran over a
dozen tests, iteratively working on code. I've now sent 100s of 1000s of
messages over many many hours without any issues to his SMTPHandler.
Furthermore, both you and Peter are running on socket limited Win2k systems,
and I am trying to load test you over a cable modem. That is sufficient to
crash Avalon's scheduler, but that isn't saying much.
I am asking both of you to do the following. And please follow directions
because I really don't need this to be more work for me than necessary.
Please package up in a single ZIP file that I can unzip into a clean
directory on one of my servers, and I will test each one of them on our
Internal network. Make sure that sendMail is commented out in SMTPHandler,
and that you don't require any special code (you told me that you have
differences from standard James).
Peter just sent me his; I will expect yours. My plan is to up the
concurrent connnections, and hammer each one pretty hard for an extended
period of time. I'm willing to do this, but it my hope is that we can
accept my proposed solution and MOVE ON.
> The beauty of using the same abstraction is that there is a simple backoff
> or switch strategy available.
You are only half correct. With the Scheduler interface, we can only
backoff to a known broken solution. Plus, your code is broken as an Avalon
Scheduler for reasons I posted earlier. And YES, I am willing to work with
you to fix that. HOWEVER, you are correct in a backhanded way. I have been
saying this for a couple of days now: your code can be easily put under the
Watchdog interface, so that we can easily backoff. I have asked you to do
this several times. I have to finish a project somewhat urgently, but Peter
has indicated to me that he is willing to make the change.
> Once we are over this release let us talk about switching abstractions.
> I have nothing against changing to WatchDog or another scheduler
abstraction
Good, then let's accept my compromise, put both implementations into the CVS
under the Watchdog interface, and put this issue to bed. This is a TRIVIAL
change for the handlers. It is already done, and it works. We can offer to
implementations of the same interface: one using Peter's dual-thread code,
and one using your single-thread code.
> 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.
I have already pointed these out:
1) the dual thread solution has lower CPU demands. PERIOD.
2) the dual thread solution scales as well as a JVM will scale threads.
If a JVM has a threading issue at some number of threads, a shared
thread (not necessarily single-threaded, by the way) solution can
be a viable alternative USING THE SAME INTERFACE.
3) The Watchdog interface is perfectly standalone, and could be submitted
to Jakarta Commons in a heartbeat. Furthermore, I could make use of it
in other code, and in multi-threaded mailets such as RemoteDelivery.
> Noel, code will address these issues.
> Noel/others, could you please review this and suggest patches.
Yes, I will be willing to review your code again. After all, I am the one
who showed you in the source code why the Avalon Scheduler has problems, and
why your attempt to use the Timer class failed. I'm the one who explained
to you the implementation issues involved in a priority queue
implementation, and then outlined how to write the priority queue
implementation that you wrote. I appreciate your taking the time to listen
to those issues, and work on your code. I'd appreciate it if you would
consider what I am suggesting now. :-)
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
