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 "Noel J. Bergman" <no...@devtech.com> on 2002/10/15 08:12:31 UTC
[VOTE] Interface for resettable, time-guarded, operations
The question is: shall we adopt the Watchdog interface with a choice of
using either a dual or shared thread implementation? Advantages of the
change have already been presented, and include:
1) Supports both dual-thread and shared-thread implementations.
2) Provides a standalone, reusable service that can be used in
non-Avalon situations. I would suggest that we can donate
the code, so to speak, to Jakarta-Commons. This is a very
useful, and oft-needed, facility.
3) Can easily be unit tested outside of an Avalon container.
The code has already been written to make this change, so there is little
effort to adopt the vote. I don't see any downside to adopting this
interface, and because it allows the choice of either implementation, both
"camps" should be satisfied. Both Harmeet and Peter have told me,
personally, that they appreciate my efforts to mediate the issue. This is
my best proposal.
I don't get a vote (and I am really beginning to regret that), but my
non-vote is +1.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Here is the more meaningful part.....
Here may be requirements to map to:
a) Publish entire set of 'resettable, time-guarded' abstractions.
b) Support m watchdog threads watching n handlers.
c) Publish your 'resettable, time-guarded' as a pluggable service/block.
Handlers should not do this: foo = new SomeResetableTimeGuard();
Please find attached an abstraction contract that makes sense to me. Please
use it if you like.
Here is the somewhat less meaningful part....
Noel do you realize that watchdog abstractions has never been completely
posted by either you or Peter.
You have mentioned 3 abstractions. (a) watchdog, (b) target, and (c)
factory. Is that true ? Has it ever been posted ?
Wouldn't you want to make a service instead of factory in line with
component oriented model used in rest of code ?
Here is my source of confusion:
> > Peter: Are you saying we should always have this strategy
> > One additional thread per handler to watch for timeout?
>
> Yes, that's what is being said.
and later
..
> proposal is that BOTH the dual-thread and shared thread
> implementations would be available under the same interface.
Former is the part that I don't agree with. Why will there be 2
implementations if the proposal is saying James will always have 'One
additional thread per handler to watch for timeout?' Anyway if you have a
mapping from watchdog to scheduler, please post it. It was not obvious to me
how a watchdog would identify a particular handler if it was watching more
than one handler. There does not seem to be a handler id concept in the
abstractions sent.
> > Hello? Harmeet? I feel like I'm doing a vaudeville routine with you.
Let us talk interfaces instead and get a solid interface set that everyone
is happy with.
> > Gee, I'd like to fix this memory consumption problem. How about you?
Me too. :-)
Harmeet
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
> - Scheduler implementation can have m threads
scheduling events for n handlers.
Yes, we all understand that, Harmeet. Peter expressed the basic math for
this issue in the message that you replied to, except that his equation was
labeled with N workers and k scheduler threads, instead of m threads and n
handlers.
> - The watchdog implementation as proposed has one
additional thread per handler. That means number
of available threads for handling protocols can
be at most half of the threads actually used and
allocated by the VM.
ONE of the implementations has an additional thread per handler. The
tradeoff is that there is zero contention and no need for synchronization in
performance critical paths. The OTHER implementation (the shared thread
solution) trades the option to have fewer watchdogs for the overhead of
synchronization and actual thread contention.
> 2 suggestions:
> - Do a comparison of scalability and performance
while varying the thread pool size. You may
notice some patterns.
Nice of you to volunteer "someone." ;-) Who exactly is the ambiguous
person whom you think should be doing this? You aren't capable of running
these tests, yourself, and reporting the results? Right now I'm more
concerned about the behavior that I am seeing in common.
> - Create a watchdog implementation that has m watchdog
threads watching n handlers and you may notice the
same multithreading issues in it that you are refering to.
Harmeet, don't you get it? That is precisely what you have already done.
Your code IS that implementation. The watchdog depending upon context and
capitalization, is only a concept or an interface. An implementation of M
threads watch N handlers is what your code provides. So OF COURSE we would
see the same issues.
> Peter: Are you saying we should always have this strategy
> One additional thread per handler to watch for timeout?
Yes, that's what is being said.
> If not, please send an implementation that allows m
> watchdog to n handler mapping?
See above.
> 1 watchdog thread per handler is too heavy for timeout.
> Timeout to some extent can also be handled by Socket
> timeout settings.
soTimeout doesn't address either the memory issue I am seeing right now, or
the basic issue of a watchdog, which is to check for other problems that
might hang the thread. I do agree that soTimeout should be used.
As for 1 thread being too heavy, might I point out the performance numbers
that I have already reported? For the same message load, the shared thread
implementation is running between 50% and 100% higher CPU utilization. And
since that result occurs with A SINGLE CONNECTION, the number of threads is
the same for each implementation. Therefore, considering that most of the
code is in common, I'd venture to say that almost all of that excess is
located in the code that is different, e.g., the shared scheduler thread.
In other words, there *appears* to be a 50% to 100% perfomance penalty, even
without contention.
> If you have an m watchdogs to n handlers implementation ...
You just really don't get it, do you? That is what you have implemented.
And, yes, we see the contention issues that Peter raised.
> One way of reducing contention is to not have shared datastructure.
> You may notice that the implementation does that. Datastructures
> per thread are mutually exclusive and don't have contention.
That is why the dual thread model is more efficient.
> Scheduler contention characteristics can be changed by having
> different values for thread count and idle time parameters.
That can CHANGE the contention characteristics, but not eliminate them. The
fact that a block CAN be contended means that you MUST synchronize it.
Synchronization imposes a significant performance penalty regardless of
whether or not any contention is actually occuring. See above for the
impact that it appears to be causeing.
> BTW. I am not saying and have never said scheduler is the right interface.
Fine.
> Agreed there can be other implementations, but I have seen only
> one so far.
What part of the proposal to use your code AS THE SHARED THREAD WATCHDOG
IMPLEMENTATION don't you understand? You keep saying the same thing --
talking about an N thread for M worker Watchdog -- completely missing the
fact that I proposed exactly that thing.
Hello? Harmeet? I feel like I'm doing a vaudeville routine with you.
<<knock, knock -- is this thing on? Can you hear me? Someone turn on this
microphone>> The proposal is that BOTH the dual-thread and shared thread
implementations would be available under the same interface. Do you
understand?
Repeat after me: both implementations will be available. Can you say it?
C'mon, you can say it: BOTH implementations will be available. :-)
> a good abstraction for such a watchdog or timeout event scheduler
> Talking about release, I had requested someone post a schedule or
> thoughts on it.
Gee, I'd like to fix this memory consumption problem. How about you?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
- Scheduler implementation can have m threads scheduling events for n
handlers.
- The watchdog implementation as proposed has one additional thread per
handler. That means number of available threads for handling protocols can
be at most half of the threads actually used and allocated by the VM.
2 suggestions:
- Do a comparison of scalability and performance while varying the thread
pool size. You may notice some patterns.
- Create a watchdog implementation that has m watchdog threads watching n
handlers and you may notice the same multithreading issues in it that you
are refering to.
Peter: Are you saying we should always have this strategy - One additional
thread per handler to watch for timeout ? If not, please send an
implementation that allows m watchdog to n handler mapping ?
1 watchdog thread per handler is too heavy for timeout. Timeout to some
extent can also be handled by Socket timeout settings.
If you have an m watchdogs to n handlers implementation, you will have some
datastructures shared by mulitple threads and some of the issues you are
talking about.
One way of reducing contention is to not have shared datastructure. You may
notice that the implementation does that. Datastructures per thread are
mutually exclusive and don't have contention. Scheduler contention
characteristics can be changed by having different values for thread count
and idle time parameters.
BTW. I am not saying and have never said scheduler is the right interface. I
don't even want to have a general scheduler implementation for timeouts, but
I do not think watchdog is not there yet. esp. because of the 1-1
association. Agreed there can be other implementations, but I have seen only
one so far. If you have an implementation that supports m to n mapping, I
will at least think it is a better alternative than the current 1-1
watchdog. I also suspect (but don't know) a good abstraction for such a
watchdog or timeout event scheduler would be a cross between current
scheduler abstraction and watchdog abstraction.
As I have said numerous times - if there is fix within current abstractions
we should do that for now, and talk/switch to a better abstraction post
release. Talking about release, I had requested someone post a schedule or
thoughts on it. It should help me at least. I would like to see more tests.
One gain from this discussion has been better tests. I think that is good.
Harmeet
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Tuesday, October 15, 2002 10:57 AM
Subject: RE: [VOTE] Interface for resettable, time-guarded, operations
>
> Noel et al,
>
> > In other words, you took my idea about spreading the load over
> multiple
> > shared workers. There are still some issues, such as:
> >
> > (1) It doesn't work. You need to fix that. :-)
> > (2) It doesn't work as a scheduler. The problem with inserting an
> > earlier
> > time.
> > (3) Synchronization and data structure management are still
> heavyweight
> > items.
> >
> > You should be able to resolve 1 and 2.
>
> Points 1 and 2 obviously make Harmeet's comments about his successful
> tests moot, since the code didn't actually work. Obviously if all the
> threads exit immediately, that's going to be a problem.
>
> In addition, despite the danger of belaboring the obvious, this is a
> well-known pattern that explicitly doesn't address point 3.
>
> Specifically, consider the two limits in the number of threads in the
> scheduler.
>
> If we go to the one thread limit, we're back at the high contention
> case. That's bad, for all the reasons we've described ad nauseum.
>
> If we go to the N thread case, where N is the number of connections,
> then we wind up with a more expensive and less elegant version of the
> Watchdog (since there will be some contention from triggers that have
> the same hash code mod N). There will be two threads per connection,
> and all calls into the Scheduler have synchronized components.
>
> So we can disregard the two limits. Now consider k, where 1 < k < N.
> As I've explained (and as the referenced article makes clear) contention
> scales non-linearly. So if we have N total connections, on average each
> individual cache will have (N/k) + 1 contending threads, for a total of
> N + k threads. Now, since the effect is non-linear, that means that
> small changes in k can lead to wide ranging effects, most of which won't
> be obvious until you get to high N. But the situation is actually worse
> than this - (N/k) + 1 is just the mean value of contending threads.
> There will be substantial statistical deviation from this mean, and you
> get penalized more grossly for upward deviations than you get rewarded
> for downward deviations. I'm not going to run through all the math
> here, but suffice to say that it's not good - at any given point there
> is at least a (1/k)^m chance that m threads will be contending on a
> single cache.
>
> --Peter
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel et al,
> In other words, you took my idea about spreading the load over
multiple
> shared workers. There are still some issues, such as:
>
> (1) It doesn't work. You need to fix that. :-)
> (2) It doesn't work as a scheduler. The problem with inserting an
> earlier
> time.
> (3) Synchronization and data structure management are still
heavyweight
> items.
>
> You should be able to resolve 1 and 2.
Points 1 and 2 obviously make Harmeet's comments about his successful
tests moot, since the code didn't actually work. Obviously if all the
threads exit immediately, that's going to be a problem.
In addition, despite the danger of belaboring the obvious, this is a
well-known pattern that explicitly doesn't address point 3.
Specifically, consider the two limits in the number of threads in the
scheduler.
If we go to the one thread limit, we're back at the high contention
case. That's bad, for all the reasons we've described ad nauseum.
If we go to the N thread case, where N is the number of connections,
then we wind up with a more expensive and less elegant version of the
Watchdog (since there will be some contention from triggers that have
the same hash code mod N). There will be two threads per connection,
and all calls into the Scheduler have synchronized components.
So we can disregard the two limits. Now consider k, where 1 < k < N.
As I've explained (and as the referenced article makes clear) contention
scales non-linearly. So if we have N total connections, on average each
individual cache will have (N/k) + 1 contending threads, for a total of
N + k threads. Now, since the effect is non-linear, that means that
small changes in k can lead to wide ranging effects, most of which won't
be obvious until you get to high N. But the situation is actually worse
than this - (N/k) + 1 is just the mean value of contending threads.
There will be substantial statistical deviation from this mean, and you
get penalized more grossly for upward deviations than you get rewarded
for downward deviations. I'm not going to run through all the math
here, but suffice to say that it's not good - at any given point there
is at least a (1/k)^m chance that m threads will be contending on a
single cache.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
> I have tried to run it with 100,00 mail messages and 20 workers
> for a few hours. Before fix it crashed James in a few minutes.
Look at the while condition in your run method.
> If you want to change performance, look at james-config.xml.diff.
In other words, you took my idea about spreading the load over multiple
shared workers. There are still some issues, such as:
(1) It doesn't work. You need to fix that. :-)
(2) It doesn't work as a scheduler. The problem with inserting an earlier
time.
(3) Synchronization and data structure management are still heavyweight
items.
You should be able to resolve 1 and 2.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
This patch is manifestly incorrect.
Examine the run() method of TimerEventProcessor. It exits immediately,
since the while(Thread.currentThread.isInterrupted()) call is false upon
start. Run exits, and the thread never actually does anything.
Are we done yet?
--Peter
> -----Original Message-----
> From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
> Sent: Tuesday, October 15, 2002 4:10 AM
> To: James Developers List
> Subject: Re: [VOTE] Interface for resettable, time-guarded, operations
>
> Alright folks here is the patch for a scheduler impl. Tested it out.
> Applying this on the latest code, and building James will make Danny's
> EndToEnd test go on and on. I have tried to run it with 100,00 mail
> messages
> and 20 workers for a few hours. Before fix it crashed James in a few
> minutes.
>
> If you want to change performance, look at james-config.xml.diff.
Change
> number of scheduler threads and idle timeout. Haven't tested for
> performance
> but tweaking these 2 config options should do the trick if that is
what
> you
> want.
>
> Scheduler reset is a bit heavy and can be made lighter.
>
> Ok, happy hacking,
> later,
> Harmeet
>
>
> PS.
> here is the Danny's EndToTest diff I made to test this.
>
> --- EndToEnd.java 14 Oct 2002 16:14:54 -/0000 1.3
> +++ EndToEnd.java 15 Oct 2002 08:08:43 -0000
> @@ -36,7 +36,7 @@
> /**
> * The number of worker threads this test invokes
> */
> - private int numWorkers = 10;
> + private int numWorkers = 20;
>
> /**
> * The size of messages generated by this test case.
>
>
> --- SMTPDeliveryWorker.java 14 Oct 2002 16:14:55 -0000 1.3
> +++ SMTPDeliveryWorker.java 15 Oct 2002 08:09:20 -0000
> @@ -47,7 +47,7 @@
> */
> public void run() {
> try {
> - for (int run = 0; run < 100; run++) {
> + for (int run = 0; run < 10000; run++) {
> //move the connect and disconnect out of the loop to
> reuse
> // the connection for all mail
> client.connect("127.0.0.1", 25);
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Alright folks here is the patch for a scheduler impl. Tested it out.
Applying this on the latest code, and building James will make Danny's
EndToEnd test go on and on. I have tried to run it with 100,00 mail messages
and 20 workers for a few hours. Before fix it crashed James in a few
minutes.
If you want to change performance, look at james-config.xml.diff. Change
number of scheduler threads and idle timeout. Haven't tested for performance
but tweaking these 2 config options should do the trick if that is what you
want.
Scheduler reset is a bit heavy and can be made lighter.
Ok, happy hacking,
later,
Harmeet
PS.
here is the Danny's EndToTest diff I made to test this.
--- EndToEnd.java 14 Oct 2002 16:14:54 -/0000 1.3
+++ EndToEnd.java 15 Oct 2002 08:08:43 -0000
@@ -36,7 +36,7 @@
/**
* The number of worker threads this test invokes
*/
- private int numWorkers = 10;
+ private int numWorkers = 20;
/**
* The size of messages generated by this test case.
--- SMTPDeliveryWorker.java 14 Oct 2002 16:14:55 -0000 1.3
+++ SMTPDeliveryWorker.java 15 Oct 2002 08:09:20 -0000
@@ -47,7 +47,7 @@
*/
public void run() {
try {
- for (int run = 0; run < 100; run++) {
+ for (int run = 0; run < 10000; run++) {
//move the connect and disconnect out of the loop to reuse
// the connection for all mail
client.connect("127.0.0.1", 25);
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Secheduler has this method to associate a target.
> void addTrigger( String id, TimeTrigger trigger, Target target );
> Watchdog does not seem to have any callback association.
Please see my earlier response to you. I've already answered this subject
in detail.
> void addTarget(WatchdogTarget targ) ;
No. For reasons previously explained in this thread, and also because ADD
is a semantic that may not be appropriate. In some cases, SET is the
appropriate semantic. Please see MutatableWatchdog for that method.
> void startWatchdog(); to void startWatchdog(WatchdogTarget targ);
No. You are exposing the ability to set a target with the ability to start
a watchdog. That mixes two different interface notions.
> If via watchdog mechanism one thread can be associated with n watched
> objects, how would each watched object be identified at trigger time
> by the thread.
Asked and answered in a prior e-mail by me.
> Would it be better to have a generic Command interface.
Orthogonal issue. I've already written and submitted the latter (see the
archives), but there is no need to rewrite the entire protocol handler
mechanism at this time.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
>
> Harmeet,
>
> These are the interfaces in question.
>
> > - How is WatchdogTarget associated with Watchdog ? The association is
> not
> > apparent.
>
> The WatchdogTarget is the target for the Watchdog upon the triggering
> event. I don't see how could find this unclear. It's certainly at
> least as clear as the relationship between Scheduler and Target.
Secheduler has this method to associate a target.
/**
* Schedule a time based trigger.
* Note that if a TimeTrigger already has same name then it is removed.
*
* @param name the name of the trigger
* @param trigger the trigger
* @param target the target
*/
void addTrigger( String id, TimeTrigger trigger, Target target );
Watchdog does not seem to have any callback association. Is there a third
object that associates watchdog with watchdog target ?
Would it be better to have this method:
void addTarget(WatchdogTarget targ) ;
or
change
void startWatchdog();
to
void startWatchdog(WatchdogTarget targ);
>
> > - From the interface it appears there is a one to one mapping between
> a
> > watched object and watchdog. This seems to impose an additional thread
> per
> > watched object. Could this lead to scalability issues. For instance if
> > there
> > are 100 threads that can be associated with a Handler, can there now
> be at
> > most 50 concurrent handlers ?
>
> There is a one to one mapping between watched object and watch dog.
> That does not imply a thread limit in generic implementations, for all
> the reasons that Noel discussed earlier. There is such a one to one
> mapping in my Watchdog implementation. By design. As I've explained.
> Repeatedly.
Let us stick to the proposed interface in this email thread please.
If via watchdog mechanism one thread can be associated with n watched
objects, how would each watched object be identified at trigger time by the
thread. I realize from your email there must be a way but I don't see it.
Can you please elaborate on how this can be done ?
>
> > - Is WatchDogTarget really needed ? Can Runnable act as WatchDog
> target ?
>
> Runnable has a specific semantic meaning. Runnable means that the class
> implementing the Runnable interface can be executed as the body of a
> thread. That's not necessarily true for a WatchdogTarget (in fact, it
> isn't for any of the code I posted). So no, you can't use Runnable.
Good point. But watchdog target is very generic.
Would it be better to have a generic Command interface.
/**
* General command interface.
*/
public interface Command {
/**
* The method represents a command that can be executed as a callback.
*/
void execute();
}
If you need a marker interface for enforcing strong semantics, how about
/**
* This interface represents an action to be triggered by a watchdog
process.
*
* @author Andrei Ivanov
* @author Peter M. Goldstein <fa...@alum.mit.edu>
*/
public interface WatchdogTarget extends Command {
}
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Harmeet,
These are the interfaces in question.
> - How is WatchdogTarget associated with Watchdog ? The association is
not
> apparent.
The WatchdogTarget is the target for the Watchdog upon the triggering
event. I don't see how could find this unclear. It's certainly at
least as clear as the relationship between Scheduler and Target.
> - From the interface it appears there is a one to one mapping between
a
> watched object and watchdog. This seems to impose an additional thread
per
> watched object. Could this lead to scalability issues. For instance if
> there
> are 100 threads that can be associated with a Handler, can there now
be at
> most 50 concurrent handlers ?
There is a one to one mapping between watched object and watch dog.
That does not imply a thread limit in generic implementations, for all
the reasons that Noel discussed earlier. There is such a one to one
mapping in my Watchdog implementation. By design. As I've explained.
Repeatedly.
> - Is WatchDogTarget really needed ? Can Runnable act as WatchDog
target ?
Runnable has a specific semantic meaning. Runnable means that the class
implementing the Runnable interface can be executed as the body of a
thread. That's not necessarily true for a WatchdogTarget (in fact, it
isn't for any of the code I posted). So no, you can't use Runnable.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I want to make the interface solid, as I said
I appreciate and support that goal. That's why I spent the time to work
with you on your investigation.
> if you feel this has had sufficient discussion, that is fine.
I'm always up for productive discussion. It is now 4:30 AM, and I'm still
awake replying to your questions. Part of this discussion has been very
good, generating information for other developers to consider, highlighting
issues, and requiring justification. But part of it just seems to bog down,
and I suspect that everyone found that aspect frustrating.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
btw. if you like do this
- Get 2 committers to say +1. I am not planning to vote on this.
- Change and post new release schedule. This was a source of concern for me.
Change it please to make it clearer.
I want to make the interface solid, as I said, but if you feel this has had
sufficient discussion, that is fine. A bit tired of this. :-)
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Tuesday, October 15, 2002 3:50 AM
Subject: Re: [VOTE] Interface for resettable, time-guarded, operations
> Noel. are watchdog and watchdog target complete set of abstractions ?
>
> Peter are you the author of this proposal.
> I want to make sure the interfaces are solid and if we move to this set,
> there is no need to change after a few months to another abstraction.
>
> Can Peter/Noel/Andrei one of you post the entire set of interfaces as part
> of proposal.
>
> > The association is decoupled. There actually is no need for a tight
> > coupling between those interfaces at the highest level, and good reason
to
> > keep it loosely coupled.
>
> To me this means there is another association API. Can you post that API
> please. How will you lookup and associate a watchdog with target ?
>
> thanks,
> Harmeet
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
> are watchdog and watchdog target complete set of abstractions ?
Watchdog publishes start, stop and reset. Triggering is defered to Watchdog
subtypes. WatchdogTarget is the trigger type defined to work with a subset
of Watchdog subtypes.
> To me this means there is another association API. Can you post that API
> please. How will you lookup and associate a watchdog with target?
Here is the Watchdog and Adapter for the SMTPHandler:
TimeoutWatchdog theWatchdog =
new TimeoutWatchdog(timeout,
new WatchdogTarget() {
public void execute() {
SMTPHandler.this.getLogger().error("...");
try {
SMTPHandler.this.socket.close();
} catch (Exception e) {
// ignored
}
}
});
There is no lookup. The target is part of the instance data for the
Watchdog object. There is no exposed "manager" class; the client code deals
directly with the Watchdog object, which can delegate behavior to other
objects, or implement it directly. But that is not exposed by the
interface.
I have not seen the addition, but I understand that Peter has made a
Watchdog Factory providing the same capability, except that it allows the
implementation of the Watchdog to be defered, so that either the dual-thread
or shared-thread implementation can be used.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Noel. are watchdog and watchdog target complete set of abstractions ?
Peter are you the author of this proposal.
I want to make sure the interfaces are solid and if we move to this set,
there is no need to change after a few months to another abstraction.
Can Peter/Noel/Andrei one of you post the entire set of interfaces as part
of proposal.
> The association is decoupled. There actually is no need for a tight
> coupling between those interfaces at the highest level, and good reason to
> keep it loosely coupled.
To me this means there is another association API. Can you post that API
please. How will you lookup and associate a watchdog with target ?
thanks,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I assume these are the interfaces. Please correct if this is not true.
Those are the interfaces Andrei and Peter developed. I am not aware of any
changes.
> How is WatchdogTarget associated with Watchdog?
The Watchdog was done by Andrei and Peter, but I'll give a shot at the
answers just to see how well I can understand the interface without their
further explanation.
The association is decoupled. There actually is no need for a tight
coupling between those interfaces at the highest level, and good reason to
keep it loosely coupled. For one thing, have you heard the concept
"narrowing of interface"? By NOT putting the WatchdogTarget in the
interface, it isolates code that just needs to reset the Watchdog from
knowing about Target related issues. However, the MutatableTargetWatchdog
interface does expose a setter (and perhaps should have a getter) for when
you do want to expose that interface. And there is another good reason,
which answers another of your questions (below).
In this case, Andrei and Peter have an implementation that which doesn't
need to be mutable. It works on behalf of a particular handler. The
constructor for that implementation takes an inner class object that
implements WatchdogTrigger, and can do what is necessary to interrupt the
handler (or whatever class is using the watchdog).
> - From the interface it appears there is a one to one mapping between a
> watched object and watchdog. This seems to impose an additional thread
per
> watched object. Could this lead to scalability issues.
This is wrong. That is not in the interface. I have told you already that
your shared thread code can be implemented as a Watchdog. Peter said that
he's already written that code, and will submit it after he finishes testing
it.
In Andrei's and Peter's IMPLEMENTATION of the Watchdog interface, they use
the dual-thread technique. This is generally considered the correct
approach, and is widely used, but even if you want or need something else,
the INTERFACE is completely neutral on that subject. When you instantiate
the Watchdog object, THAT is your direct handle to the Watchdog (rather than
a lookup key), but internally that object can be handed to a shared-thread
implementation. When you reset the watchdog, it takes care of how that
works. You deal with the Watchdog directly, and not the underlying manager.
> Is WatchDogTarget really needed ? Can Runnable act as WatchDog target?
Yes and no. If you feel that there is some method on Runnable that you want
to call, then you can create an ADAPTER object (that is what WatchdogTrigger
actually does) to call that method. The Watchdog interface is completely
neutral not only on the issue of a trigger implementation, but even on the
issue of a trigger interface. The trigger interface is imposed further down
in an interface hierarchy. If you needed some other notion of "target", you
can implement that, but the code that starts, stops and resets the Watchdog
remains unchanged. If you wanted to create some subtype of Watchdog that
worked directly with a Runnable, you could. But it isn't necessary, because
of the Adapter pattern.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Interface for resettable, time-guarded, operations
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Please post interface as part of this proposal.
I assume these are the interfaces. Please correct if this is not true.
/**
* This interface represents an abstract watchdog process that serves to
* monitor a situation and triggers an action under an
implementation-specific
* trigger condition.
*
* @author Andrei Ivanov
* @author Peter M. Goldstein <fa...@alum.mit.edu>
*/
public interface Watchdog {
/**
* Start this Watchdog, causing it to begin monitoring. The Watchdog
can
* be stopped and restarted.
*/
void startWatchdog();
/**
* Reset this Watchdog. Resets any conditions in the implementations
* (time to expiration, etc.) to their original values
*/
void resetWatchdog();
/**
* Stop this Watchdog, terminating the monitoring condition. The
monitor
* can be restarted with a call to startWatchdog.
*/
void stopWatchdog();
}
/**
* This interface represents an action to be triggered by a watchdog
process.
*
* @author Andrei Ivanov
* @author Peter M. Goldstein <fa...@alum.mit.edu>
*/
public interface WatchdogTarget {
/**
* The method executed by the watchdog process when the trigger
condition
* is met.
*/
void execute();
}
Some questions:
- How is WatchdogTarget associated with Watchdog ? The association is not
apparent.
- From the interface it appears there is a one to one mapping between a
watched object and watchdog. This seems to impose an additional thread per
watched object. Could this lead to scalability issues. For instance if there
are 100 threads that can be associated with a Handler, can there now be at
most 50 concurrent handlers ?
- Is WatchDogTarget really needed ? Can Runnable act as WatchDog target ?
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Interface for resettable, time-guarded, operations
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
I do get a vote. :)
+1
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Monday, October 14, 2002 11:13 PM
> To: James-Dev Mailing List
> Subject: [VOTE] Interface for resettable, time-guarded, operations
>
> The question is: shall we adopt the Watchdog interface with a choice
of
> using either a dual or shared thread implementation? Advantages of
the
> change have already been presented, and include:
>
> 1) Supports both dual-thread and shared-thread implementations.
> 2) Provides a standalone, reusable service that can be used in
> non-Avalon situations. I would suggest that we can donate
> the code, so to speak, to Jakarta-Commons. This is a very
> useful, and oft-needed, facility.
> 3) Can easily be unit tested outside of an Avalon container.
>
> The code has already been written to make this change, so there is
little
> effort to adopt the vote. I don't see any downside to adopting this
> interface, and because it allows the choice of either implementation,
both
> "camps" should be satisfied. Both Harmeet and Peter have told me,
> personally, that they appreciate my efforts to mediate the issue.
This is
> my best proposal.
>
> I don't get a vote (and I am really beginning to regret that), but my
> non-vote is +1.
>
> --- 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>