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/09 02:55:02 UTC
[PATCH] Removing Scheduler dependency, refactoring service code
All,
This code is being posted almost a week after I'd originally intended to
post it. For that I can only apologize - I got held up by a bunch of
things.
Basically this code is designed to address a bunch of
memory/robustness/scalability issues. These issues were, at least in
part, due to problems with the Cornerstone TimeScheduler. Dependence on
the global TimeScheduler, previously used to handle idle timeouts, has
been removed. Instead, James now uses the classes of the new
org.apache.james.util.Watchdog package to provide this functionality.
In addition, there was substantial rearchitecting of the service
structure. James services are now subclasses of the new
AbstractJamesService class. This class serves to unify the common
functionality of the services. BaseConnectionHandler is removed,
because the functionality once provided by that class has been moved
into AbstractJamesService. The Configurable interface (and the
corresponding behavior) has been removed from all the ConnectionHandler
children, in recognition that configuration is really on a per-server,
not per-handler, basis. This leads to tighter coupling between the
Handlers and the corresponding server classes, but that's simply
recognition of a pre-existing reality. These classes are extremely
tightly coupled.
The config.xml entries were not modified to remove the
<handler></handler> tags, to maximize backwards compatibility. These
tags don't really make sense, even before this set of changes, and
should be removed in a future version.
Some enhancements, including the ability to specify a thread group for
use by a particular service and the ability to do more fine-grained
connection management (i.e. to have more than one set of SSL
connections, each for use by different services) have been added. These
will be further documented, but are basically encapsulated in the
AbstractJamesService class.
There was some change to the behavior of the SMTP server - specifically,
the number of bytes required to reset the idle timer is now measured
against the total number of bytes read off the socket, not simply those
read in the DATA command. This substantially neatens the code and in
real life scenarios doesn't make a whole lot of difference.
There is also a partial redress of bug #13316 in the NNTP code, which
will reset the watchdog every 100 headers it transmits.
I've done basic testing on this code, and I am now doing further load
testing. I will continue to do testing before submission.
The code is attached as a set of diffs, and a collection of newly added
files.
As always, comments, critiques, and questions are welcome.
--Peter
Re: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Sorry forgot to send the diff mentioned in last mail
Index: SMTPHandler.java
===================================================================
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/smtpserver/SMTPHandler.jav
a,v
retrieving revision 1.31
diff -u -r1.31 SMTPHandler.java
--- SMTPHandler.java 17 Oct 2002 22:04:01 -0000 1.31
+++ SMTPHandler.java 24 Oct 2002 02:04:21 -0000
@@ -46,7 +46,7 @@
*/
public class SMTPHandler
extends BaseConnectionHandler
- implements ConnectionHandler, Composable, Configurable, Target {
+ implements ConnectionHandler, Composable, Configurable, Command {
/**
* SMTP Server identification string used in SMTP headers
@@ -223,9 +223,14 @@
private int lengthReset = 20000;
/**
- * The scheduler used to handle timeouts for the SMTP interaction.
+ * The Event Manager used to handle timeouts for the SMTP interaction.
*/
- private TimeScheduler scheduler;
+ private ResettableTimeGuardedCommandMap eventMgr;
+
+ /**
+ * ID used to identify handler with Event Manager
+ */
+ private int handlerEventID;
/**
* The user repository for this server - used to authenticate
@@ -252,9 +257,9 @@
*/
public void compose(final ComponentManager componentManager) throws
ComponentException {
mailServer = (MailServer)
componentManager.lookup("org.apache.james.services.MailServer");
- scheduler =
- (TimeScheduler) componentManager.lookup(
-
"org.apache.avalon.cornerstone.services.scheduler.TimeScheduler");
+ eventMgr =
+ (ResettableTimeGuardedCommandMap) componentManager.lookup(
+ ResettableTimeGuardedCommandMap.ROLE);
UsersStore usersStore =
(UsersStore)
componentManager.lookup("org.apache.james.services.UsersStore");
users = usersStore.getRepository("LocalUsers");
@@ -325,8 +330,7 @@
// Initially greet the connector
// Format is: Sat, 24 Jan 1998 13:16:09 -0500
- final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
timeout, -1 );
- scheduler.addTrigger( this.toString(), trigger, this );
+ handlerEventID = eventMgr.add(timeout, this );
StringBuffer responseBuffer =
new StringBuffer(192)
.append("220 ")
@@ -339,7 +343,7 @@
writeLoggedFlushedResponse(responseString);
while (parseCommand(readCommandLine())) {
- scheduler.resetTrigger(this.toString());
+ scheduler.reset(handlerEventID);
}
getLogger().debug("Closing socket.");
} catch (SocketException se) {
@@ -392,7 +396,7 @@
}
// release from scheduler.
try {
- scheduler.removeTrigger(this.toString());
+ eventMgr.remove(handlerEventID);
} catch(Throwable t) { }
}
}
@@ -406,7 +410,7 @@
*
* TODO: Remove this interface from the class and change the mechanism
*/
- public void targetTriggered(final String triggerName) {
+ public void execute() {
getLogger().error("Connection timeout on socket with " + remoteHost
+ " (" + remoteIP + ")");
try {
out.println("Connection timeout. Closing connection");
--
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> > We seem to be arguing if the handler key should be there
> > or not in the Abstraction.
>
> Precisely.
> The Watchdog interface does not model a manager passed a token/key. It
Handler key was important to me because it allowed n handler to m watchdog
interactions. But if the Watchdog is passed to the handler and it there is
an m handler to n watchdog mapping, the handler ID is implicit.
I see your point...
>
> > > The Watchdog is a just portable, lightweight interface.
> > > If someone wanted to create a Block that provided
> > > Watchdog instances, they could.
> > Would it be possible to provide this as part of the proposal/patch.
>
> Provide what, precisely? A Watchdog Block? I don't see much value to it,
> and I don't want to make the assembly and config files even more complex.
It is a consistency issue . All interfaces etc are registered as services.
A simple watchdog factory registered as a block could do the trick. For
instance
interface WatchdogFactory {
String ROLE = WatchdogFactory.class.getName();
Watchdog getWatchdog();
}
or better have this and remove Watchdog#start.
interface WatchdogFactory {
String ROLE = WatchdogFactory.class.getName();
/** Start the watchdog and have it trigger after @param offset
milliseconds */
Watchdog startWatchdog(long offset);
}
WatchdogFactory could be passed to handlers via config or some other
alternate method.
> OK, now that you've sent your proposed change, I see that your change
> doesn't actually involve a command map abstraction.
I picked the name 'ResettableTimeGuardedCommandMap' from your proposal
subject 'Resetteable Time Guarded Operations'. Replaced Operations with
Command and added Map to indicate m to n semantics.
Never been happy about the name, but did want to not use watchdog or
scheduler word.
> What you did was simply
> rename "trigger" to "execute" on the handler itself, as if one could
> "execute" the handler. Further, since the operation performed was
actually
> semantically an interrupt instead of an execute, it implied the wrong
> semantic.
I put something together fast in the hope we could get talking more about
interfaces.
> Now that I've seen your code in-situ, let's put this into perspective so
> that we all see the difference. We're talking about changing
>
> From: manager = componentManager.lookup(<role>)
[hb]
Or: eventMgr = componentManager.lookup(<role>)
Or: void setEventManager(eventMgr)
Or: eventMgr = config.getEventManger();
> To: void setWatchdog(Watchdog)
>
> From: manager.addX(<arg-list)
[hb]
Or: handlerEventID = add(timeout, this); // handlerEventID is int.
> To: watchdog.start()
[hb] do you mean ?
To: watchdog.start(this)
> From: scheduler.resetTrigger(this.toString())
> Or: eventMgr.reset(handlerEventID)
> To: watchdog.reset()
>
> From: manager.remove(<arg-list>)
[hb]
Or: eventMgr.remove(handlerEventID)
> To: watchdog.stop()
>
> If you want to argue that there should be an Avalon Frameworks interface
for
> these kinds of services, that'd be for the Avalon folks to take up, and
I'm
> sure that Peter and Peter could do something about the service model if
> Peter thought it worthwhile (I'll leave interpretation of the overloaded
> name as an exercise for the reader ;-)).
Good one. :-)
I don't see a big gain in service refactoring, but it looks like James is
getting good performace and you have confidence in it.
Regd. watchdog I still think we should use lookup and block facilities and
not have code like this. abstraction = new AbstractionImpl();
m to n semantics could be done either implicitly or explicitly. Either way
would work but should be there.
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
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
> > if we are adding value to Avalon's service,
> > why don't we push this into Avalon.
>
> As I understand it from Peter and Andrei (I don't consider myself an
> Avalon
> guru), the question is what value does AbstractService provide? It
isn't
> a
> generic interface, it is a particular subclassable implementation
provided
> by Cornerstone. In the case of AbstractService and
AbstractJamesService,
> every method would need to be overridden, as well as the new ones
added.
>
> If you want to argue that there should be an Avalon Frameworks
interface
> for
> these kinds of services, that'd be for the Avalon folks to take up,
and
> I'm
> sure that Peter and Peter could do something about the service model
if
> Peter thought it worthwhile (I'll leave interpretation of the
overloaded
> name as an exercise for the reader ;-)). But in the meantime,
> AbstractJamesService models the behavior James needs, and would gain
> nothing
> from extending AbstractService.
>
> Frankly, Peter and Andrei are far more Avalon knowledgable than I, and
> ought
> to be able to explain (or correct) this better to everyone.
>
Noel is correct, on all points.
To put this in perspective, not a single application in the Avalon-apps
repository uses AbstractService as a base class for their components.
That includes applications such as an FTP server for which such an
implementation might make sense. AbstractService is just a random
implementation that someone wrote - there's nothing special about it.
Andrei and I rewrote AbstractService because it didn't meet our needs -
it was tied to the old ConnectionManager implementation, didn't match
our configuration, etc.
--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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We seem to be arguing if the handler key should be there
> or not in the Abstraction.
Precisely.
The Watchdog interface does not model a manager passed a token/key. It
models an abstract object that performs an operation if a resettable timer
expires. There is nothing in the Watchdog interface that even hints at
implementation. That is deferred to implementing subclasses, each of which
would maintain all the state necessary to perform its task. The abstraction
is that if I am using a Watchdog, I am given one, and I talk to it. I don't
carry around both a manager and a key. A Watchdog, if you want to look at
it that way, encapsulates both the management and the identity.
> > The Watchdog is a just portable, lightweight interface.
> > If someone wanted to create a Block that provided
> > Watchdog instances, they could.
> Would it be possible to provide this as part of the proposal/patch.
Provide what, precisely? A Watchdog Block? I don't see much value to it,
and I don't want to make the assembly and config files even more complex.
But hey, if a Watchdog Block turned out to be a useful thing, there wouldn't
be any change to a handler using the Watchdog interface -- not a single
line.
> I was thinking something like in config object
> (i.e. once per n handlers)
The shared config object is the wrong place for it. Putting it there
already places into the model the notion that it MUST handle multiple
states.
> Attaching what would be the diff for SMTP Handler. It is pretty similar to
> the current code and not very far from watchdog either.
OK, now that you've sent your proposed change, I see that your change
doesn't actually involve a command map abstraction. What you did was simply
rename "trigger" to "execute" on the handler itself, as if one could
"execute" the handler. Further, since the operation performed was actually
semantically an interrupt instead of an execute, it implied the wrong
semantic.
I'll send you one so that you can see what a command map looks like.
Basically, each command is an object, as in the Command Pattern, and each
operation (e.g., protocol verb) is dispatched to the corresponding command
object. But now I see why you didn't understand why I said that
implementing a command map model within the handlers would involve more code
movement than I wanted to involve in this release.
> replacing scheduler with a lighter weight
> resettable-timeguarded-operations Abstraction.
Now that I've seen your code in-situ, let's put this into perspective so
that we all see the difference. We're talking about changing
From: manager = componentManager.lookup(<role>)
To: void setWatchdog(Watchdog)
From: manager.addX(<arg-list)
To: watchdog.start()
From: scheduler.resetTrigger(this.toString())
Or: eventMgr.reset(handlerEventID)
To: watchdog.reset()
From: manager.remove(<arg-list>)
To: watchdog.stop()
The handler is given an opaque object that hides all implementation details.
> Will there be one connection limits for pop3 and pop3 secure?
As I understand it, separate or shared. Up to the admin.
> if we are adding value to Avalon's service,
> why don't we push this into Avalon.
As I understand it from Peter and Andrei (I don't consider myself an Avalon
guru), the question is what value does AbstractService provide? It isn't a
generic interface, it is a particular subclassable implementation provided
by Cornerstone. In the case of AbstractService and AbstractJamesService,
every method would need to be overridden, as well as the new ones added.
If you want to argue that there should be an Avalon Frameworks interface for
these kinds of services, that'd be for the Avalon folks to take up, and I'm
sure that Peter and Peter could do something about the service model if
Peter thought it worthwhile (I'll leave interpretation of the overloaded
name as an exercise for the reader ;-)). But in the meantime,
AbstractJamesService models the behavior James needs, and would gain nothing
from extending AbstractService.
Frankly, Peter and Andrei are far more Avalon knowledgable than I, and ought
to be able to explain (or correct) this better to everyone.
> All of these [configuration items] can be handled by
> you ConfigData object. Right ?
Actually, you were the one who first mentioned the idea, I just championed
it into the code.
> why don't we simply get to the bottom on config
> passing that we have agreement on and come up
> with a good 'resettable-timeguarded-operations'
> abstraction that we are pretty close and leave
> out Refactoring unless you see a huge gain.
The "refactoring" is because of the config passing change. The
configuration code moves from the handler into the server. The change in
handler lifecycle permits object pooling, which Peter added at my request,
and we are seeing an significant incremental performance benefit. As I
said, running Peter's code from Monday showed a 33% increase in performance
over the Oct 17th code. The major change is the object pooling.
Which reminds me of reason 127 why I'd really like to get this resolved and
into the CVS. Exchanging code outside of the project mechanism isn't the
way this is supposed to work as a general method.
Reminder: if you want to provide another build, I'd be happy to run all of
the same tests against your build, too. I have an equal opportunity test
net. Pending the ability to actually commit code, descriptions of all of
the changes that led to improvement have been published to the mailing list
(one I found yesterday is setting buffer sizes that are smaller than the
default for handler input -- this has a significant impact on the heap when
running with lots of connections).
> Good to get agreement on this. Patch really has nothing
> to do with logging improvements.
Similarly, the logging change is simple. Remember the configuration object
that gets passed to handlers? Because that is constructed once by the
server, instead of each handler re-processing the configuration block, it
provides a clean opportunity to write the configuration information to the
log in one place and at the same time. That's it.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> > I thought that the Watchdog as an abstraction lacked
> > a few important things. These were the things that I
> > thought were worth having :
> > Support m watchdog threads watching n handlers.
> > Publish 'resettable, time-guarded' as a pluggable service/block.
>
> You are confusing ABSTRACTION with IMPLEMENTATION. The ABSTRACTION of the
> Watchdog interface is that client code has an opaque object with which to
> interact using a small set of operations, e.g., start, stop, reset.
This is exactly what the Abstraction I sent earlier has, except there is an
associated handler key. Instead of start, stop, reset methods are add,
remove, reset.
We seem to be arguing if the handler key should be there or not in the
Abstraction.
> The Watchdog is a just portable, lightweight interface. If someone wanted
> to create a Block that provided Watchdog instances, they could.
Would it be possible to provide this as part of the proposal/patch. James
has been following a Component oriented approach elsewhere it would be nice
to follow it for the watchdog too.
>
> > Handlers should not do this: foo = new SomeResetableTimeGuard();
>
> You mean like in the current (CVS) code? Where it has:
>
> final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
> timeout, -1 );
I was thinking something like
in config object (i.e. once per n handlers)
ResettableTimeGuardedCommandMap timerEventMgr =
componentManager.lookup(ResettableTimeGuardedCommandMap.ROLE);
In handler code.
this.handlerTimeoutEventID = timerEventMgr.add(timeout,this);
There is no PeriodicTimeTrigger object or any other heavyweight object
created.
>
> Thanks for bringing this up. Good news. Watchdog creation is no longer
in
> the Handler. Handlers are given a Watchdog. They are ignorant of the
> implementation of that interface.
Is watchdog part of the context provided ?
>
> > ResettableTimeGuardedCommandMap was a suggestion
> > to facilitate arriving at a good abstraction.
>
> It is a completely different approach to handler implementation that
> requires rewriting Handlers to use a command map. I had submitted code
for
> that over the summer, but I would not propose rewriting handlers for 2.1.
> IF we rewrite the handlers for v3 to use a command map, changing how
> handlers do timeout will be the least of our issues.
Attaching what would be the diff for SMTP Handler. It is pretty similar to
the current code and not very far from watchdog either. It certainly is
really far from rewrite :-)
BTW. I didn't like the name ResettableTimeGuardedCommandMap but I wanted the
name to derive from proposal subject and not have either watchdog or
scheduler word in the name.
I would prefer we arrive at one abstraction and not revisit this for a few
years. Let us try to settle on something really good now and not revisit for
v3 etc.
>
> > Logging can be configured to ...
>
> Logging support is provided to James by Avalon, and as you said, "Logging
> facilities seem pretty flexible and good to me as it is."
Good to get agreement on this. Patch really has nothing to do with logging
improvements.
>
> > Latter looks fine to me. I agree with your comments on information
hiding.
> > Is the configure object something like the one attached?
> > with POP3Handler having something like
> > void setConfiguration(POP3HandlerConfig config)
>
> public interface POP3HandlerConfigurationData {
> String getHelloName();
> int getResetLength();
> MailServer getMailServer();
> UsersRepository getUsersRepository();
> }
>
> void setConfigurationData(POP3HandlerConfigurationData theData);
Looks good.
>
> > Do you agree that the config optimization could be
> > done in a more localized manner?
>
> By localized, you mean you just want the change for configuration, and no
> other code change? The changes I am aware of are:
Config changes and replacing scheduler with a lighter weight
resettable-timeguarded-operations Abstraction.
>
> - handler configuration
> - this requires the server to prepare the service-wide
> configuration.
Part of the confiuration change.
> - this permits object pooling of handlers and related objects.
Handler object would be very lighweight using POP3HandlerConfigurationData.
It would prob. only contain a socket, Input Output Stream object and not
much else. Socket related objects cannot be pooled.
> - Watchdog interface
This is part of resettable-timeguarded-operations Abstraction change. I like
your original proposal subject name better.
> - Unlike the Scheduler interface, this interface hides
> implementation details of timeout from the client
> code, and supports arbitrary timeout mechanisms
> transparently.
> - Support for per-service (POP3, SMTP, ...) and global
> connection limits.
Will there be one connection limits for pop3 and pop3 secure ?
Connection limits are already imposed by current code.
>
> > Why pull and duplicate code ?
>
> It doesn't. Thread management has always been part of James, provided by
an
> Avalon thread manager. That thread manager still does its job. What DOES
> open is the OPTION of having additional <thread-group> elements. And
James
> is now able to enforce connection limits per service.
Alreay there in current code.
>
> AbstractJamesService does not "pull in thread management" or even use it.
> What it does do is provide better control over thread pooling. It simply
> finds out from the service configuration if a specific pool is to be used
> for the service, gets either the specified pool or the default pool from
the
> thread manager service, and passes that onto the ConnectionManager.
Threads
> are still managed by the thread manager, and connections are still managed
> (and dispatched on threads) by the connection manager.
I realize it is pretty similar. What I don't know is this if we are adding
value to Avalon's service, why don't we push this into Avalon. There are lot
of common Avalon/James commiters who could do this.
> There is nothing wrong with Avalon's base service. But it does not model
> the behavior common to Jame's services.
There are upto 5 protocol handlers in James, Most things common for James
would be useful would be useful for other servers too. So again, why pull in
code into james and not push changes as need be into Avalon.
If we have found a better pattern of doing listener-dispatch, we might as
well push it in a more general location.
To me, it would be way cooler to say: would be nice if Avalon did xyz and
get them to do add it via a patch.
>
> AbstractJamesService models behavior for James services. It provides a
> shared implementation for derived classes, handling such common model
> elements as bindaddress, port, enabled, useTLS, helloName, timeout, and
> connection limits; behavior such as initialize and dispose; and exposes
the
> HandlerFactory interface.
All of these can be handled by you ConfigData object. Right ?
Anyway I don't think it is a big deal. I have been a bit apprehensive about
the amont of redisgn for fixing things. Even for this fix, why don't we
simply get to the bottom on config passing that we have agreement on and
come up with a good 'resettable-timeguarded-operations' abstraction that we
are pretty close and leave out Refactoring unless you see a huge gain.
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I thought that the Watchdog as an abstraction lacked
> a few important things. These were the things that I
> thought were worth having :
> Support m watchdog threads watching n handlers.
> Publish 'resettable, time-guarded' as a pluggable service/block.
You are confusing ABSTRACTION with IMPLEMENTATION. The ABSTRACTION of the
Watchdog interface is that client code has an opaque object with which to
interact using a small set of operations, e.g., start, stop, reset. As I've
mentioned, the interface hides the underlying implementation, which is where
decisions such as a second thread or shared thread implementation are made.
It can hide an adapter to the Avalon Scheduler interface, if one were to
insist on using the Scheduler.
The Watchdog is a just portable, lightweight interface. If someone wanted
to create a Block that provided Watchdog instances, they could.
> Handlers should not do this: foo = new SomeResetableTimeGuard();
You mean like in the current (CVS) code? Where it has:
final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
timeout, -1 );
Thanks for bringing this up. Good news. Watchdog creation is no longer in
the Handler. Handlers are given a Watchdog. They are ignorant of the
implementation of that interface.
> ResettableTimeGuardedCommandMap was a suggestion
> to facilitate arriving at a good abstraction.
It is a completely different approach to handler implementation that
requires rewriting Handlers to use a command map. I had submitted code for
that over the summer, but I would not propose rewriting handlers for 2.1.
IF we rewrite the handlers for v3 to use a command map, changing how
handlers do timeout will be the least of our issues.
> Logging can be configured to ...
Logging support is provided to James by Avalon, and as you said, "Logging
facilities seem pretty flexible and good to me as it is."
> Latter looks fine to me. I agree with your comments on information hiding.
> Is the configure object something like the one attached?
> with POP3Handler having something like
> void setConfiguration(POP3HandlerConfig config)
public interface POP3HandlerConfigurationData {
String getHelloName();
int getResetLength();
MailServer getMailServer();
UsersRepository getUsersRepository();
}
void setConfigurationData(POP3HandlerConfigurationData theData);
> Do you agree that the config optimization could be
> done in a more localized manner?
By localized, you mean you just want the change for configuration, and no
other code change? The changes I am aware of are:
- handler configuration
- this requires the server to prepare the service-wide
configuration.
- this permits object pooling of handlers and related objects.
- Watchdog interface
- Unlike the Scheduler interface, this interface hides
implementation details of timeout from the client
code, and supports arbitrary timeout mechanisms
transparently.
- Support for per-service (POP3, SMTP, ...) and global
connection limits.
> Why pull and duplicate code ?
It doesn't. Thread management has always been part of James, provided by an
Avalon thread manager. That thread manager still does its job. What DOES
open is the OPTION of having additional <thread-group> elements. And James
is now able to enforce connection limits per service.
AbstractJamesService does not "pull in thread management" or even use it.
What it does do is provide better control over thread pooling. It simply
finds out from the service configuration if a specific pool is to be used
for the service, gets either the specified pool or the default pool from the
thread manager service, and passes that onto the ConnectionManager. Threads
are still managed by the thread manager, and connections are still managed
(and dispatched on threads) by the connection manager.
> If there are issues in the Avalon Base Service
There is nothing wrong with Avalon's base service. But it does not model
the behavior common to Jame's services.
AbstractJamesService models behavior for James services. It provides a
shared implementation for derived classes, handling such common model
elements as bindaddress, port, enabled, useTLS, helloName, timeout, and
connection limits; behavior such as initialize and dispose; and exposes the
HandlerFactory interface.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> > I agree that it is a good idea to have a lighter weight abstraction, but
> > that should not prevent replacing a current broken implementation (not
> > abstraction) esp. as it has already been tested and does not exhibit the
> > leak. Sure, can hold off...
>
> But you did introduce an entirely new abstraction, the
> ResettableTimeGuardedCommandMap. Or am I mixing proposals?
It is the same proposal. I thought that the Watchdog as an abstraction
lacked a few important things. These were the things that I thought were
worth having :
- Support m watchdog threads watching n handlers.
- Publish 'resettable, time-guarded' as a pluggable service/block.
Handlers should not do this: foo = new SomeResetableTimeGuard();
ResettableTimeGuardedCommandMap was a suggestion to facilitate arriving at a
good abstraction. If we are moving to a new abstraction let us talk about
what the right abstraction should be and not visit this again.
>
> >
> > Fails to address the already stated logging/validation concerns that
> > should be localized in the server class, as per my earlier post.
>
> > Logging can be in one log file per protocol or one log file per
> > server.
>
> How are you defining the terms? By server do you mean James? Within
James,
> server == service == protocol.
Server really has 3 meanings, it could be James, it could be a single
protocol server instance or it could protocol server instances. I will
attempt to be more unabiguous about nomenclature. Logging can be configured
to
- log pop3 listener on port 110 to a log file or
- log pop3 and pop3 secure listener to the same or different file. or
- log all serers to same file.
Logging facilities seem pretty flexible and good to me as it is.
> The bigger win in this change is that Peter adopted the single
configuration
> object that you, yourself, have promoted several times. He changed the
> interface from calling n setters to calling a single method, passing an
> interface to the immutable service-wide configuration data. This brings
it
> back closer to the Configure approach, but with an optimized config.
> ...
> Regardless of where it is passed, what you're suggesting is that it should
> be:
> serviceConfig.timeout instead of serviceConfig.getTimeout()
>
> As I said, I don't see a justification to abandon implementation hiding.
Latter looks fine to me. I agree with your comments on information hiding.
Is the configure object something like the one attached ?
with POP3Handler having something like
void setConfiguration(POP3HandlerConfig config)
Regd this:
> To me refactoring for the optimization described seems like applying more
> changes and pulling in more code than need be.
Do you agree that the config optimization could be done in a more localized
manner ?
I am not concerned about final variables vs. getters, but about pulling in
code that may have little to do with this configuration passing
optimization.
Is there real need for AbstractService to pull in thread management etc.
code into James ? Why pull and duplicate code ? If there are issues in the
Avalon Base Service class, we should suggest patches to Avalon folks or deal
with those issues separately.
Harmeet
RE: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I agree that it is a good idea to have a lighter weight abstraction, but
> that should not prevent replacing a current broken implementation (not
> abstraction) esp. as it has already been tested and does not exhibit the
> leak. Sure, can hold off...
But you did introduce an entirely new abstraction, the
ResettableTimeGuardedCommandMap. Or am I mixing proposals?
>
> Fails to address the already stated logging/validation concerns that
> should be localized in the server class, as per my earlier post.
> Logging can be in one log file per protocol or one log file per
> server.
How are you defining the terms? By server do you mean James? Within James,
server == service == protocol.
> > Exposes member variables directly, rather than by 'getter' methods.
> Isn't a final variable in a package scoped immutable object better
> than calling n getters ?
Not in my mind. The expense of a simple getter is not significant, and
certainly not worth tossing off implementation hiding. Also, it is a fun
activity for some friends of mine to demonstrate that final isn't. If you
really want immutable data, you do it with read-only properties.
The bigger win in this change is that Peter adopted the single configuration
object that you, yourself, have promoted several times. He changed the
interface from calling n setters to calling a single method, passing an
interface to the immutable service-wide configuration data. This brings it
back closer to the Configure approach, but with an optimized config.
> n getter would make handlers more heavyweight(orig. concern)
> and may end up being a sizable chunk of code
This is backwards. The getters are on the config, not the handler. From
the handler's perspective, there is one configuration method for setting the
shared data. The only question thereafter is does it do:
serviceConfig.X or serviceConfig.getX()
> There is one Params object for n handlers and it is passed into the
handler
> constructor.
Regardless of where it is passed, what you're suggesting is that it should
be:
serviceConfig.timeout instead of serviceConfig.getTimeout()
As I said, I don't see a justification to abandon implementation hiding.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@peter-goldstein.com>
>
> -1.
>
> Interferes with current short term plans still under discussion.
>
I assume you are refering to the 'resettable, time-guarded' proposal.
I agree that it is a good idea to have a lighter weight abstraction, but
that should not prevent replacing a current broken implementation (not
abstraction) esp. as it has already been tested and does not exhibit the
leak. Sure, can hold off...
>
> Fails to address the already stated logging/validation concerns that
> should be localized in the server class, as per my earlier post.
How is the logging/validation any worse ? It seems that these are fine.
There is nothing preventing the Params constructor to more validation if
need be. Logging can be in one log file per protocol or one log file per
server. This is controlled by separate logging config file.
>
> Exposes member variables directly, rather than by 'getter' methods.
Isn't a final variable in a package scoped immutable object better than
calling n getters ? You may notice that this addresses a larger set of
instance variables more easily. n getter would make handlers more
heavyweight(orig. concern) and may end up being a sizable chunk of code,
thus distracting from the main methods.
It is also easier to see the diffs and exact optimization made. All it
involves is - replace instance variables e.g. timeout with params.timeout.
There is one Params object for n handlers and it is passed into the handler
constructor.
To me refactoring for the optimization described seems like applying more
changes and pulling in more code than need be.
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
Posted by "Peter M. Goldstein" <pe...@peter-goldstein.com>.
-1.
Interferes with current short term plans still under discussion.
Fails to address the already stated logging/validation concerns that
should be localized in the server class, as per my earlier post.
Exposes member variables directly, rather than by 'getter' methods.
While I don't object to a "Params" object per se, this implementation is
not acceptable for these reasons.
> Regd. service refactoring I had promised to send an alternate patch
in,
> but
> had not done so.
>
> I hoping to not get into a long discussion on this one, as even the
more
> important
> 'Interface for resettable, time-guarded, operations' issue has not
been
> resolved. I would have preferred to have a better scheduler
implementation
> in place till the 'resettable, time-guarded' proposal is resolved.
>
> This is an attempt to finish something I had promised to send earlier.
My
> main motivation is that we should not be refactoring existing stable
code
> and pulling in parts of Avalon unless we need to. If there are
specific
> issues in the way James is architected we should resolve exactly that.
> In this patch I have broken the dependency between POP3Handler and
> BaseConnectionHandler, but I think is better to keep the current
> abstraction
> as there is lot of commonality between protocol handlers. For instance
> variables like Socket, Input Stream, Output Stream etc need not exist
in
> separate handlers.
>
> This is a complete working patch.
>
> Hope this discussion doesn't trigger another looong round.
> Harmeet
>
> here is what the patch addressees:
> ----- Original Message -----
> From: "Peter M. Goldstein" <pe...@yahoo.com>
> There were a number of very serious problems with the handler heavy
> approach.
>
> First, there was the simple expense. Server objects are created once
> per service, handler objects are created, fed through the lifecycle,
and
> destroyed multiple times a second. Thus it is advantageous to move as
> much of the lifecycle expense into the server code.
>
> Second, there's a bizarre division of configuration information.
--
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
> Guys, I gotta say, I don't think we're making a lot of headway
> discussing this anymore. I think all sides have been raised their
> points, and further communication does not seem to be benefitting anyone.
>
> Can we
> just delete this class and move on?
Sounds sensible at this point.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Commiting recent changes (was: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
The Avalon Scheduler doesn't leak. It gets flooded. Big difference.
FetchPOP doesn't cause flooding.
In any event, my point is that if anyone is going to be able to use your
Scheduler instead of the default from Avalon, that you'll have to fix that
bug.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Friday, October 25, 2002 22:48
To: James Developers List
Subject: Re: Commiting recent changes (was: Code change the Apache way)
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> Harmeet, since FetchPOP does use the Scheduler in the way it is designed
> to work, I think you do need to address the problem I have mentioned
> about it not working properly when inserting a time earlier than the
> current head of the list. Until that is resolved, I don't think that
> it can replace the general Scheduler Block.
If we are going to live with the scheduler, it may be a good idea to have
the bug fixed version that was posted rather than the current one with
memory leak.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Commiting recent changes (was: Code change the Apache way)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> Harmeet, since FetchPOP does use the Scheduler in the way it is designed
to
> work, I think you do need to address the problem I have mentioned about it
> not working properly when inserting a time earlier than the current head
of
> the list. Until that is resolved, I don't think that it can replace the
> general Scheduler Block.
If we are going to live with the scheduler, it may be a good idea to have
the bug fixed version that was posted rather than the current one with
memory leak.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Commiting recent changes (was: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > Are we near to seeing stuff commited.. ?
> > apart from the obvious fact that some contentious
> > items can be vetoed *after* commit, I'd say that
> > as long as it builds we should be commiting often.
I generally agree, Danny, and found that to be one of the more frustrating
thing.
Generally speaking, how easy or hard it is it to allow posting proposed
changes into the proposals/ tree, and automating the build? Something that
would let me say, "./build <proposal>", and have a build made from the HEAD
with the proposed changes applied. What would be involved, and is this a
viable approach?
> What I will do is post the latest, greatest code
Sounds good, Peter. As soon as I get it, I should have time to work on the
promised Scheduler <-> Watchdog adaption.
Harmeet, since FetchPOP does use the Scheduler in the way it is designed to
work, I think you do need to address the problem I have mentioned about it
not working properly when inserting a time earlier than the current head of
the list. Until that is resolved, I don't think that it can replace the
general Scheduler Block.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> Are we near to seeing stuff commited.. ?
> apart from the obvious fact that some contentious items can be vetoed
> *after* commit, I'd say that as long as it builds we should be
commiting
> often.
Noel and I are currently running more tests, and everything is coming up
green. What I will do is post the latest, greatest code for evaluation
later today. If the consensus is that I should commit said code, I'll
be more than happy to do so. I have simply been unwilling to do so over
an outstanding -1.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by Danny Angus <da...@apache.org>.
Are we near to seeing stuff commited.. ?
apart from the obvious fact that some contentious items can be vetoed *after* commit, I'd say that as long as it builds we should be commiting often.
d.
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 25 October 2002 18:23
> To: 'James Developers List'
> Subject: RE: Code change the Apache way
>
>
>
> Serge,
>
> > > - Keep scope as close to what is being attempted. We have been
> making
> > more
> > > design changes than a bug fix/cleanup needs.
> >
> > Yes which are fixing show-stopper bugs and improving performace by 30%
> +.
> >
> > Whats an email server if you can't count on it to do its job? How many
> > people keep asking "is it production ready?"
>
> Agreed. One minor correction. Performance improvement isn't 30%, it's
> 900%. Prior to these changes James crashed under a load of ~6
> mails/second (360 mails/minute). With the current code base (Watchdog,
> object pooling, deleteonexit removed) we are getting a performance of
> ~60 mails/second (3600 mails/minute).
>
> --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: Code change the Apache way
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Serge,
> > - Keep scope as close to what is being attempted. We have been
making
> more
> > design changes than a bug fix/cleanup needs.
>
> Yes which are fixing show-stopper bugs and improving performace by 30%
+.
>
> Whats an email server if you can't count on it to do its job? How many
> people keep asking "is it production ready?"
Agreed. One minor correction. Performance improvement isn't 30%, it's
900%. Prior to these changes James crashed under a load of ~6
mails/second (360 mails/minute). With the current code base (Watchdog,
object pooling, deleteonexit removed) we are getting a performance of
~60 mails/second (3600 mails/minute).
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Code change the Apache way
Posted by Serge Sozonoff <se...@globalbeach.com>.
Hi Harmeet,
> - Keep scope as close to what is being attempted. We have been making more
> design changes than a bug fix/cleanup needs.
Yes which are fixing show-stopper bugs and improving performace by 30% +.
Whats an email server if you can't count on it to do its job? How many
people keep asking "is it production ready?"
Thanks, Serge
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, October 25, 2002 6:56 PM
Subject: Re: Code change the Apache way
> We seem to have extremely strong views over things that are of marginal
> importance. My rule of the thumb is usu. to not do minor cleanup(like
> removing one not useful for now class) if someone objects. This also sits
> well with rules but there is no point arguing endlessly about it. Willing
to
> give in... :-(
> and eager to move to other things. :-)
>
>
> Some suggestions to facilitate changes:
> - Cleanup/redesign few things at a time not 5 things together
> - Keep scope as close to what is being attempted. We have been making more
> design changes than a bug fix/cleanup needs.
>
> This was a really nice thing to say :
> From: "Serge Knystautas" <se...@lokitech.com>
> > saying the rules and regs aren't heavy and not a big part of
> > the culture
>
> 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: Code change the Apache way
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We seem to have extremely strong views over things that are of marginal
> importance.
Sometimes that happens. My inquiry was not about any particular example. I
just want to know how resolution works.
Which is why I am not going to reply to your examples in this thread, other
than to say that as a general rule, I agree that micro-change is less
stressful than macro. But it not necessarily more correct. Sometimes a
change of design is good, or even necessary. Those things should be
discussed. Also, not every change that moves code is a design change, and
not every class is part of the design.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Sorry last email was a bit confusing, did cut and paste in the wrong email.
I try to reduce time on emails, and that sometimes reduces the quality of
response:
Please ignore the last email and read this one.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> > I don't think much is to be gained by continuing this thread.
> > I really would like us to get over 2.1 and focus on 3.0.
>
> The only thing I'd like to gain from it is to ensure that we don't have
> similar issues for v3.
me too. :-)
One thing that would help a lot is a formal release manager. It could be an
active developer or even someone outside the group who feels strongly about
mail,
schedule/planning and can herd cats..
Would be good to have someone who has managed distributed or open source
projects in the past where developers are not always available. Any takers ?
I think this is an extremely critical role and would help make us all more
successful with James. We should also decide on what are we going to do in
the next major release.
>
> > I haven't seen any test added to verify the
> > functionality. We should augment our testing.
>
> Sounds like an opportunity. Volunteering? :-)
I hope to be more active in at least testing.
>
> > Hopefully NNTP will be a focus for 3.0 along with more testing.
>
> Thanks for reminding me! Check out this thread:
>
> http://www.mail-archive.com/general@jakarta.apache.org/msg05985.html
>
> TestMaker sounds similar to what we talked about building with BSF. But
> neither TestMaker nor JMeter seem to handle SMTP, POP3, NNTP or IMAP.
>
Started looking at it. It seems very python oriented.
One problem is that this approach seems to require significant coding
component in scripts. Scripts are not strongly typed and at least one level
of checks are lost.
It would be good to have some template based test capability. Preferably,
tied into a standard too.
For example it should be trivial to pick from RFC 821 section
-------------------------
3.2. FORWARDING
Example of Forwarding
Either
S: RCPT TO:<Po...@USC-ISI.ARPA>
R: 251 User not local; will forward to <Po...@USC-ISIF.ARPA>
Or
S: RCPT TO:<Pa...@USC-ISIB.ARPA>
R: 551 User not local; please try <Mo...@USC-ISIF.ARPA>
-------------------------
And have script like
# forwarding test from RFC 821, Section 3.2
# user local
S: RCPT TO:test@localhost
C: 250.*
# user is not local
S: RCPT TO:test@yahoo.com
C: 551.*
With a TestMaker it looks like a lot more work.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't think much is to be gained by continuing this thread.
> I really would like us to get over 2.1 and focus on 3.0.
The only thing I'd like to gain from it is to ensure that we don't have
similar issues for v3.
> I haven't seen any test added to verify the
> functionality. We should augment our testing.
Sounds like an opportunity. Volunteering? :-)
> Hopefully NNTP will be a focus for 3.0 along with more testing.
Thanks for reminding me! Check out this thread:
http://www.mail-archive.com/general@jakarta.apache.org/msg05985.html
TestMaker sounds similar to what we talked about building with BSF. But
neither TestMaker nor JMeter seem to handle SMTP, POP3, NNTP or IMAP.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Noel J. Bergman" <no...@devtech.com>
> The NNTP code was broken for a long time with no one working on it. Peter
> fixed it and posted changes for comment. Obviously, he didn't ignore the
> discussion, because you and he got into an argument over the changes. You
> two couldn't agree
Yes, Peter found exact problem. I offerred to fix it and he ignored and
checked it in.
The question I had was - Why did he invite the discussion and if he had he
should have let the author make a stab at it before changing the design.
This is esp. important as the author had disagreed with the changes.
Anyway ignored that but it that was followed by some more design changes
that seemed to be only driven by cleanup instincts and caused at least one
significant regression.
Btw. for all the excitement about bug fixing and pointing to
implementation/design flaws, I haven't seen any test added to verify the
functionality. We should augment our testing.
I don't think much is to be gained by continuing this thread. I really would
like us to get over 2.1 and focus on 3.0.
Hopefully NNTP will be a focus for 3.0 along with more testing.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> From: Nicola Ken Barozzi <ni...@apache.org>
> > A note on this subject:
> > Developers that are not involved in a specific part of the codebase
> > should abstain from vetoing components that other developers work on.
> That is the exact thing that got me ticked off.
The NNTP code was broken for a long time with no one working on it. Peter
fixed it and posted changes for comment. Obviously, he didn't ignore the
discussion, because you and he got into an argument over the changes. You
two couldn't agree, but that is not the same as if Peter were vetoing
changes that you were making to NNTP, without his having spent time working
on it. I doubt that he'd have done either, if someone had been actively
maintaining it. You could have vetoed his changes, and submitted your own
for acceptance.
As I understand it from the messages between you two, Peter said on multiple
occassions that future versions should have a "real" Authentication Service,
but he removed AuthService for v2.1 because it was seriously flawed, and his
change was the more expedient one for this release.
Honestly, I haven't looked at the code that was in question, and personally,
I'd have just moved NNTP out of the release (e.g., into proposal/) until
someone(s) agreed on how to fix it, and did so.
> This had been going on for some time
I've only been here since April or so, but you've got me with that one.
What has been going on for some time? I have not seen any substantial
change checked in that wasn't discussed first, or at least posted for
discussion. Changes are lazy consensus. If no one speaks up, they are
accepted. No one should be faulted for not hearing what's not said. Every
time an issue has come up, it has been discussed, so far as I'm aware.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: Nicola Ken Barozzi <ni...@apache.org>
> A note on this subject:
> Developers that are not involved in a specific part of the codebase
> should abstain from vetoing components that other developers work on.
> For example, say that I have worked for weeks on IMAP, and someone that
> has never committed anything to it vetos one of my commits...
That is the exact thing that got me ticked off.
This had been going on for some time, but invite to discussion and ignore
and silent NNTP design changes forced me to react more than I normally do.
In case you want to dig up look before '[PATCH] Removing Scheduler
dependency, refactoring service code'.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
[Harmeet]
> > > - Keep scope as close to what is being attempted. We have been
> making
> > more
> > > design changes than a bug fix/cleanup needs.
> >
[Serge]
> > Yes which are fixing show-stopper bugs and improving performace by 30%
> +.
> >
> > Whats an email server if you can't count on it to do its job? How many
> > people keep asking "is it production ready?"
>
[Peter]
> Agreed. One minor correction. Performance improvement isn't 30%, it's
> 900%. Prior to these changes James crashed under a load of ~6
> mails/second (360 mails/minute). With the current code base (Watchdog,
> object pooling, deleteonexit removed) we are getting a performance of
> ~60 mails/second (3600 mails/minute).
This is not a minor correction. I think you have done an excellent job.
While I may not agree with you all the time but what you have done is very
creditable.
What I was suggesting neither discourages or slows. It may do the opposite -
facilitate and make things easier.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > > we should get into the habit of tagging... we
> > > haven't done this since 2.0a3.
> > Ahem, we've (I've) tagged everything thats invloved
> > incrementing the version numbers.
> Where are you tagging? I graphed build.xml,
> a src/java/.java file, and a couple other
> files and didn't see any tags or branches.
While you guys are hashing this out, perhaps we can use this discussion as
fodder for putting together good guidelines / instructions for Committers
with respect to the CVS is in order? :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
>>Also, with the release, we should get into the habit of tagging... we
>>haven't done this since 2.0a3.
>
>
> Ahem, we've (I've) tagged everything thats invloved incrementing the version numbers.
Where are you tagging? I graphed build.xml, a src/java/.java file, and
a couple other files and didn't see any tags or branches.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by Danny Angus <da...@apache.org>.
> Also, with the release, we should get into the habit of tagging... we
> haven't done this since 2.0a3.
Ahem, we've (I've) tagged everything thats invloved incrementing the version numbers.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Current changes (was RE: Code change the Apache way)
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I took a look at the change log that Serge put out for each prior release;
> boy, do we have a lot of work to do pulling that together for 2.1!
Yeah, that's a real pain, but really necessary (and part of the Apache
Way if I'm not mistaken (although I already have been once today)). I
usually use a cvs changelog to make sure I don't miss any changes. Also
generally makes it easy to give the right person/people credit too.
Also, with the release, we should get into the habit of tagging... we
haven't done this since 2.0a3. I really like this bit from Maven's
site...
http://jakarta.apache.org/turbine/maven/development-process.html.
Documentation on our release process and naming conventions and anything
else related would be great to capture as we do this next build.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> A design is not a design until it works.
Well, it could just be a bad design :-), but that issue aside, I think that
an implementation can validate a design, but that a bad implementation
doesn't invalidate a design.
Yes, a validation ought to provide the basic functionality.
Not having spent any time looking at AuthService, I'd have to correct that
lack before involving myself in that technical discussion.
> I've starting coordinating a list by examining the
> commit messages for the last three months.
Good place to start.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
> > In short, if something doesn't work it doesn't
> > constitute a design.
>
> I don't agree with that as a general statement, and I don't believe
that
> you
> do, either. Bugs do not invalidate design. Architecture, design and
> implementation each has a role, and a defect in one does NOT imply a
> defect
> in another. Bugs exist and can be fixed. For that matter, proper
> operation
> does not imply that the design or architecture is correct, but as
Thomas
> Kuhn would likely argue, we often require failure before we are
motivated
> to
> undertake structural change.
I actually do believe in this as a general statement. A design is not a
design until it works. That doesn't mean that the implementation can't
have bugs, but it does mean that the basic functionality has to be
provided and work as expected. Anything else is virtually an invitation
for developers to spend their time doing what most of them enjoy most
(designing components) and not doing what most of them enjoy least
(testing functionality). BTW, I put myself into this group.
A great example of this is AuthService. AuthService was a singleton
component that stored authentication credentials in a global fashion.
This was a critical bug from day one. Even the simplest negative test
case would've exposed the problem. But none was done. Thus I don't
consider that design to have any merit - since it never worked, I can't
really worry about breaking it. Fixing it in any sense would've
required changing the "design", as the auth credentials would've had to
have been moved from the global context.
I do agree that basic proper function is not a sufficient condition for
optimal design, but I will argue that it's a necessary condition. An
architecture that precludes proper function is not an optimal design -
it's not even a valid one.
> Again, as for the rest, I think that we're moving forward, should
leave it
> at that, and do what we can to keep James established as an attractive
> community for developers interested in a high quality, flexible, mail
> server.
>
> I took a look at the change log that Serge put out for each prior
release;
> boy, do we have a lot of work to do pulling that together for 2.1!
Yeah, I've starting coordinating a list by examining the commit messages
for the last three months. Lots to do...
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Current changes (was RE: Code change the Apache way)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Except you keep blocking submission with -1 votes.
Did he? Or were they simply implied? It has been so long, I honestly don't
recall. And at this point, since we are moving forward, I DO NOT CARE. I
do, however, believe that should all relax and move forward with as much
harmony as we can muster.
As for "design changes", hopefully we can all agree with something I posted
a few minutes ago, to wit:
- As a general rule, micro-change is less stressful than macro.
But not necessarily more correct.
- Sometimes a change of design is good, or even necessary.
Those things should be discussed.
- Not every change that moves code is a design change,
and not every class is part of the design.
Now, in the context of this thread, as opposed to the other one where I
really want to keep the discussion on the Apache philosophy and not our
current issues, I will say that I consider BaseConnectionHandler to fall
into that last category. It is a class that clearly was part of the
implementation, but not a design element.
> Of the changes discussed to date, the only one that is arguably a
> "design change" is removing the dependency on the scheduler.
Actually, I would disagree with that argument. The Watchdog fills exactly
the same role in the design that the Scheduler was used to fill. There is
no design change. If anything, tying handlers more closely to their server,
rather than having a handler as an pseudo-independent construct, could be
viewed as a design change, although a minor design change with significant
positive implementation benefits. We still have the same design elements,
all filling the same roles. All that has changed is a bit of linkage.
> In short, if something doesn't work it doesn't
> constitute a design.
I don't agree with that as a general statement, and I don't believe that you
do, either. Bugs do not invalidate design. Architecture, design and
implementation each has a role, and a defect in one does NOT imply a defect
in another. Bugs exist and can be fixed. For that matter, proper operation
does not imply that the design or architecture is correct, but as Thomas
Kuhn would likely argue, we often require failure before we are motivated to
undertake structural change.
Again, as for the rest, I think that we're moving forward, should leave it
at that, and do what we can to keep James established as an attractive
community for developers interested in a high quality, flexible, mail
server.
I took a look at the change log that Serge put out for each prior release;
boy, do we have a lot of work to do pulling that together for 2.1!
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Current changes (was RE: Code change the Apache way)
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
> Some suggestions to facilitate changes:
> - Cleanup/redesign few things at a time not 5 things together
We would have. Except you keep blocking submission with -1 votes. And
Noel keeps trying to figure out creative ways to appease you while
keeping the momentum to improve the product going
> - Keep scope as close to what is being attempted. We have been making
more
> design changes than a bug fix/cleanup needs.
I'm baffled by your definition of "design changes". Basically you seem
to think that any change that
i) Removes a file
ii) Reorganizes the methods of a file
constitutes a design change. It doesn't.
Of the changes discussed to date, the only one that is arguably a
"design change" is removing the dependency on the scheduler. And that
one was discussed ad nauseum over the summer. Everyone agreed, the
scheduler had to go. Everyone but you still does. We have successful
demonstrated tests of a scheduler-free James that runs like a bat out of
hell. You haven't put the time and energy in to bolster your position -
you haven't provided a .sar upon request. But we're still stuck on your
-1.
This behavior is exactly the sort of plodding thinking that let this
trivial bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=5824
sit around for nine months. In short, if something doesn't work it
doesn't constitute a design. It's only when
i) An architectural issue has been discussed and documented
ii) The basic functionality expected of that feature is provided (bugs
are allowed, critical ones are not)
that you have anything that can possibly constitute a design. The above
criteria ensure that the proposed feature/arrangement/etc. works, and
that understanding of the ideas involved is passed to the community.
Otherwise, you've got nothing.
I have a real problem with this sort of paralysis. It basically
guarantees that the product goes nowhere.
In the last three months the James community has, by group effort:
i) Closed James as an open SMTP relay
ii) Added a new service for fetching POP3 mail to a single mailbox
iii) Improved the performance of the spooler by 50%+, depending on the
configuration.
iv) Removed multiple critical memory leaks
v) Made the NNTP service come into line with spec
vi) Made NNTP SSL and auth functional
vii) Improved SMTP performance by 900%. Other handlers should see a
substantial improvement as well.
viii) Reduced heap size under load dramatically.
ix) Fixed god knows how many other bugs
At no time save this one did we debate whether these were "design
changes". We examined the code base and modified it as necessary to
make James work properly. In some cases files were reorganized or
deleted, but this was almost never a real consideration as to whether
the fix would be accepted. There was discussion in almost all cases of
whether the proposed fixes were the right fixes, but the community came
to a consensus and the fixes were made in short order. The current
discussion, forced entirely by you, is easily the longest discussion
we've had on implementing a bug fix during my time at James. And easily
the least productive.
As software developers, we are bound by our own sense of professionalism
to maintain support for our published APIs until and unless we announce
that the next version will not support them. This is a responsibility
to our user base, and it is one I have championed vigorously.
The same logic doesn't hold true for the details of our internal
classes. Frankly, I don't care how the system currently works
internally - that's not a criterion that we use to evaluate change.
There is nothing sacrosanct about the current code. In most of the
above cases the current "design" was flawed, in either a major
(AuthService) or a minor (SMTPHandler) way. So they were fixed. That
applies whether the original author of the code is Serge, you, me, or
anyone else. That's the way successful software projects work.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Code change the Apache way
Posted by Harmeet Bedi <ha...@kodemuse.com>.
We seem to have extremely strong views over things that are of marginal
importance. My rule of the thumb is usu. to not do minor cleanup(like
removing one not useful for now class) if someone objects. This also sits
well with rules but there is no point arguing endlessly about it. Willing to
give in... :-(
and eager to move to other things. :-)
Some suggestions to facilitate changes:
- Cleanup/redesign few things at a time not 5 things together
- Keep scope as close to what is being attempted. We have been making more
design changes than a bug fix/cleanup needs.
This was a really nice thing to say :
From: "Serge Knystautas" <se...@lokitech.com>
> saying the rules and regs aren't heavy and not a big part of
> the culture
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by Danny Angus <da...@apache.org>.
> I hate to say this but I total disagree concerning the PMC.
I'm sorry about that, I do continue to feel that if we can't sort out our own code-related arguments then we are failing as a community.
However the rest of your comments, about making the PMC work for us, I do agree with. I'm not saying we should not use our recourse to the PMC, otherwise from our POV what would they be there for?
d.
>
I really
> think that there is a *major* fobia concerning project to PMC
> interaction. Projects like James and Avalon and I'm sure other should
> be making PMC members work their buts off for and on behalf of the
> projects they are representing. IOf they don't have the bandwith then
> the need to expand capacity - look at Jakarta today - it does not have
> the bandwith to handle everything - which means that there is a
> potential that they are not representing you. Due to that flack on the
> reorg list concerning licensing I'm currently working with the PMC to
> come up with a license solution with will take a lot of icky stuff out
> of the code that I have committed (icky from a legal point of view).
> The actions of the PMC have a potential to make the work I'm doing much
> easier - engage more comitters in content I'm directly involved within.
> I've been stuffing around with getting solutiuon "by myself" for 9
> months - then I went to thr PMC - winthin 48 hours we have a couple of
> people who have the necessary contacts to make things happen jumped up
> and voluteer to help. The board jumped in with opinions wich provide me
> sufficient guidance so that I know what to do to conform with the
> "Apache Way".
>
> Working with your PMC is a positive thing.
> Making your PMC work for you is even better.
>
> :-D
>
> Cheers, Steve.
>
> >
> >All of the above helps to reduce the possibility of code
> yo-yo-ing between two competing designs.
> >
> >d.
> >
> >
> >--
> >To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
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: Code change the Apache way
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>>p.s. I don't know anything about the context of this dicussion :-)
>>
>>Cheers, Steve.
>>
>>
>
>Well done then for hitting the nail on the head!
>
>As far as I can ascertain the rules mean this; That although the policy is "comit then review", and review is subject to lazy concensus (ie abstention is tacit aceptance) changes affecting architecure, existing functionality or design policy which are likely to provoke comment are best discussed beforehand and concensus reached, with or without a formal vote on the issue.
>
>If the community is working well discussions will be taking place anyway.
>
>This is one very good reason to keep technical discussions on the list, not behind the scenes, even where the perticipants feel that it would be of no value to have them in public, perhaps because they are esoteric, of marginal relevance to the overall picture, or just plain dull.
>
>As far as a veto, I agree with Steves analysis that vetos have to be justified, and that the only way to remove a veto is by reaching concensus with the vetoer. In the case where concensus can't be reached, the PMC are there to help resolve issues, but I couldn't imagine resorting to this drastic step would do much more than harm the community, whatever the outcome.
>
Dany:
I hate to say this but I total disagree concerning the PMC. I really
think that there is a *major* fobia concerning project to PMC
interaction. Projects like James and Avalon and I'm sure other should
be making PMC members work their buts off for and on behalf of the
projects they are representing. IOf they don't have the bandwith then
the need to expand capacity - look at Jakarta today - it does not have
the bandwith to handle everything - which means that there is a
potential that they are not representing you. Due to that flack on the
reorg list concerning licensing I'm currently working with the PMC to
come up with a license solution with will take a lot of icky stuff out
of the code that I have committed (icky from a legal point of view).
The actions of the PMC have a potential to make the work I'm doing much
easier - engage more comitters in content I'm directly involved within.
I've been stuffing around with getting solutiuon "by myself" for 9
months - then I went to thr PMC - winthin 48 hours we have a couple of
people who have the necessary contacts to make things happen jumped up
and voluteer to help. The board jumped in with opinions wich provide me
sufficient guidance so that I know what to do to conform with the
"Apache Way".
Working with your PMC is a positive thing.
Making your PMC work for you is even better.
:-D
Cheers, Steve.
>
>All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.
>
>d.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Code change the Apache way
Posted by Nicola Ken Barozzi <ni...@apache.org>.
A note on this subject:
Developers that are not involved in a specific part of the codebase
should abstain from vetoing components that other developers work on.
For example, say that I have worked for weeks on IMAP, and someone that
has never committed anything to it vetos one of my commits...
That person has no real moral "right" to do it, unless its global
involvement and partecipation in the project is so big that he can
rightly claim to have high stakes in it.
Some think this has to be made a rule, some don't.
The bottom line is: respect the work of others and don't block them if
you are not helping them.
And I agree with what Danny says below :-)
Danny Angus wrote:
>>p.s. I don't know anything about the context of this dicussion :-)
>>
>>Cheers, Steve.
>
>
> Well done then for hitting the nail on the head!
>
> As far as I can ascertain the rules mean this; That although the policy is "comit then review", and review is subject to lazy concensus (ie abstention is tacit aceptance) changes affecting architecure, existing functionality or design policy which are likely to provoke comment are best discussed beforehand and concensus reached, with or without a formal vote on the issue.
>
> If the community is working well discussions will be taking place anyway.
>
> This is one very good reason to keep technical discussions on the list, not behind the scenes, even where the perticipants feel that it would be of no value to have them in public, perhaps because they are esoteric, of marginal relevance to the overall picture, or just plain dull.
>
> As far as a veto, I agree with Steves analysis that vetos have to be justified, and that the only way to remove a veto is by reaching concensus with the vetoer. In the case where concensus can't be reached, the PMC are there to help resolve issues, but I couldn't imagine resorting to this drastic step would do much more than harm the community, whatever the outcome.
>
> All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by Danny Angus <da...@apache.org>.
> p.s. I don't know anything about the context of this dicussion :-)
>
> Cheers, Steve.
Well done then for hitting the nail on the head!
As far as I can ascertain the rules mean this; That although the policy is "comit then review", and review is subject to lazy concensus (ie abstention is tacit aceptance) changes affecting architecure, existing functionality or design policy which are likely to provoke comment are best discussed beforehand and concensus reached, with or without a formal vote on the issue.
If the community is working well discussions will be taking place anyway.
This is one very good reason to keep technical discussions on the list, not behind the scenes, even where the perticipants feel that it would be of no value to have them in public, perhaps because they are esoteric, of marginal relevance to the overall picture, or just plain dull.
As far as a veto, I agree with Steves analysis that vetos have to be justified, and that the only way to remove a veto is by reaching concensus with the vetoer. In the case where concensus can't be reached, the PMC are there to help resolve issues, but I couldn't imagine resorting to this drastic step would do much more than harm the community, whatever the outcome.
All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by "Noel J. Bergman" <no...@devtech.com>.
> p.s. I don't know anything about the context of this dicussion :-)
In this case, the context is simple and complete: Serge indicated that CVS
commit was by majority vote, and that wasn't what I thought the rules said.
So outside of any other context that one might wrongly assume, I wanted to
correct my own understanding of what the rules are, and how they work.
Especially since I would not be surprised if I get questions about them at
Software Summit.
Watching the discussion right now between you and Danny regarding going to
the PMC is educational, in and of itself.
I hadn't mentioned forking, becase although I did understood it to be a
"solution", I don't consider it to be a healthy solution. It is a solution
of last resort.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Code change the Apache way
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Serge,
>
>Judging from "All other action items are considered to have lazy approval
>until somebody votes -1, after which point they are decided by either
>consensus or majority vote, depending on the type of action item" it seems
>that lazy simply means that it is accepted until rejected. On the one hand,
>it means that a Committer on vacation can't be "surprised" when he or she
>gets back. On the other hand, I don't see what (on paper) prevents a
>Committer from rejecting decisions made months or even years previously.
>
>Practically, this surely can't happen (or at least often), or nothing would
>get done. I'd venture that the rules work best where everyone tacitly
>agrees to seek the best solution for the project. I don't see what
>procedures are provided for resolving conflict, other than discussing it
>until everyone agrees on something. Other parts of the Jakarta site
>emphasis the importance of community building, so apparently part of the
>solution is getting along.
>
>In any event, I'd be interested in hearing more from experienced Apache
>members just informationally, but hopefully it won't be a practical issue
>here.
>
I can give you my understanding (having gone though though this). If a
committer has contributed to a particular source file, that contributor
can -1 the action. Generally speaking the only course of action is for
the community to lobby that committer to change his/her mind. There is
a qualification that a committer must provide justification, however
that justification may be totally irrelevant or oven irrationale. The
committer right to veto holds. The standard solution presumed under the
Jakarta framework is that the option is always available for a fork to
take place. Within small scenarios this is workable - within larger
scenanarios the single committer veto start to fall appart - because of
the implications of forking of a large scale project. There is an
option to request mediation from the Jakarta PMC - just email
pmc@jakarta.apache.org with a request for assistance. I've been told
not to do this in the past - but its clear from the reorg list that the
PMC is there to work for you in thise sort of cases.
p.s. I don't know anything about the context of this dicussion :-)
Cheers, Steve.
>
>Thanks for the kudos. And I agree with you regarding ASF. I think that it
>is definitely the right kind of organization, with the best attitude towards
>licensing, allowing a synergistic mixture of open (Tomcat) and closed
>(Websphere) participants contributing to a common code base.
>
> --- Noel
>
>-----Original Message-----
>From: Serge Knystautas [mailto:sergek@lokitech.com]
>Sent: Friday, October 25, 2002 0:13
>To: James Developers List
>Subject: Re: Code change the Apache way
>
>
>Noel,
>
>Technically, I think you're right. I read this half a dozen times
>before sending my previous email, and with another half a dozen reads,
>I'm still confused but now leaning towards your interpretation. I was
>deriving significance from the term "lazy", although it's never defined
>in the document.
>
>As for a clarification, you'll have to request one from the Jakarta PMC.
> From my memory, I thought voting used to be typically majority-style.
> But from this doc, a release plan and a release testing are the only
>actions that are to use this vote-style. All others should ultimately
>be consensus. I have to think this is backwards... changing CVS
>requires consensus but making a release doesn't?
>
>Anyway, kudos on being a committer. I firmly believe the ASF has
>produced so much great stuff, and it's because it has the right style...
>from licensing model to decision making approach to project proposal
>credentials to culture. I think the interpretations and the future
>re-org are relatively minor and just clarifying what's largely already
>in place. (saying the rules and regs aren't heavy and not a big part of
>the culture, imho.)
>
>--
>Serge Knystautas
>Loki Technologies
>http://www.lokitech.com/
>
>Noel J. Bergman wrote:
>
>
>>>a code change [only needs] a majority vote (even a -1 isn't blocking).
>>>
>>>
>>Please explain this. Because I really want to understand, and I had
>>understood it differently. From
>>http://jakarta.apache.org/site/decisions.html:
>>
>>"Changes to the products of the Project, including code and documentation,
>>will appear as action items in the status file. All product changes to the
>>currently active repository are subject to lazy consensus."
>>
>>I'd interpreted this to say that CVS changes are subject to lazy
>>
>>
>consensus.
>
>
>>And the document says that "[an] action requiring consensus approval must
>>receive at least 3 binding +1 votes and no binding vetos."
>>
>>Please explain where I missed the point, and where I can find more
>>illuminating information. I figure that between my being a new Committer,
>>the talk about a PMC, and having to stand in front of 600 people in 10
>>
>>
>days
>
>
>>talking about all of the wonderful Java technologies from Apache, it is
>>probably a good idea to get more clarity on Apache's rules and regs. :-)
>>
>>Thanks! :-)
>>
>> --- Noel
>>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Code change the Apache way
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Judging from "All other action items are considered to have lazy approval
until somebody votes -1, after which point they are decided by either
consensus or majority vote, depending on the type of action item" it seems
that lazy simply means that it is accepted until rejected. On the one hand,
it means that a Committer on vacation can't be "surprised" when he or she
gets back. On the other hand, I don't see what (on paper) prevents a
Committer from rejecting decisions made months or even years previously.
Practically, this surely can't happen (or at least often), or nothing would
get done. I'd venture that the rules work best where everyone tacitly
agrees to seek the best solution for the project. I don't see what
procedures are provided for resolving conflict, other than discussing it
until everyone agrees on something. Other parts of the Jakarta site
emphasis the importance of community building, so apparently part of the
solution is getting along.
In any event, I'd be interested in hearing more from experienced Apache
members just informationally, but hopefully it won't be a practical issue
here.
Thanks for the kudos. And I agree with you regarding ASF. I think that it
is definitely the right kind of organization, with the best attitude towards
licensing, allowing a synergistic mixture of open (Tomcat) and closed
(Websphere) participants contributing to a common code base.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Friday, October 25, 2002 0:13
To: James Developers List
Subject: Re: Code change the Apache way
Noel,
Technically, I think you're right. I read this half a dozen times
before sending my previous email, and with another half a dozen reads,
I'm still confused but now leaning towards your interpretation. I was
deriving significance from the term "lazy", although it's never defined
in the document.
As for a clarification, you'll have to request one from the Jakarta PMC.
From my memory, I thought voting used to be typically majority-style.
But from this doc, a release plan and a release testing are the only
actions that are to use this vote-style. All others should ultimately
be consensus. I have to think this is backwards... changing CVS
requires consensus but making a release doesn't?
Anyway, kudos on being a committer. I firmly believe the ASF has
produced so much great stuff, and it's because it has the right style...
from licensing model to decision making approach to project proposal
credentials to culture. I think the interpretations and the future
re-org are relatively minor and just clarifying what's largely already
in place. (saying the rules and regs aren't heavy and not a big part of
the culture, imho.)
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Noel J. Bergman wrote:
>>a code change [only needs] a majority vote (even a -1 isn't blocking).
>
>
> Please explain this. Because I really want to understand, and I had
> understood it differently. From
> http://jakarta.apache.org/site/decisions.html:
>
> "Changes to the products of the Project, including code and documentation,
> will appear as action items in the status file. All product changes to the
> currently active repository are subject to lazy consensus."
>
> I'd interpreted this to say that CVS changes are subject to lazy
consensus.
> And the document says that "[an] action requiring consensus approval must
> receive at least 3 binding +1 votes and no binding vetos."
>
> Please explain where I missed the point, and where I can find more
> illuminating information. I figure that between my being a new Committer,
> the talk about a PMC, and having to stand in front of 600 people in 10
days
> talking about all of the wonderful Java technologies from Apache, it is
> probably a good idea to get more clarity on Apache's rules and regs. :-)
>
> Thanks! :-)
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Code change the Apache way
Posted by Serge Knystautas <se...@lokitech.com>.
Noel,
Technically, I think you're right. I read this half a dozen times
before sending my previous email, and with another half a dozen reads,
I'm still confused but now leaning towards your interpretation. I was
deriving significance from the term "lazy", although it's never defined
in the document.
As for a clarification, you'll have to request one from the Jakarta PMC.
From my memory, I thought voting used to be typically majority-style.
But from this doc, a release plan and a release testing are the only
actions that are to use this vote-style. All others should ultimately
be consensus. I have to think this is backwards... changing CVS
requires consensus but making a release doesn't?
Anyway, kudos on being a committer. I firmly believe the ASF has
produced so much great stuff, and it's because it has the right style...
from licensing model to decision making approach to project proposal
credentials to culture. I think the interpretations and the future
re-org are relatively minor and just clarifying what's largely already
in place. (saying the rules and regs aren't heavy and not a big part of
the culture, imho.)
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Noel J. Bergman wrote:
>>a code change [only needs] a majority vote (even a -1 isn't blocking).
>
>
> Please explain this. Because I really want to understand, and I had
> understood it differently. From
> http://jakarta.apache.org/site/decisions.html:
>
> "Changes to the products of the Project, including code and documentation,
> will appear as action items in the status file. All product changes to the
> currently active repository are subject to lazy consensus."
>
> I'd interpreted this to say that CVS changes are subject to lazy consensus.
> And the document says that "[an] action requiring consensus approval must
> receive at least 3 binding +1 votes and no binding vetos."
>
> Please explain where I missed the point, and where I can find more
> illuminating information. I figure that between my being a new Committer,
> the talk about a PMC, and having to stand in front of 600 people in 10 days
> talking about all of the wonderful Java technologies from Apache, it is
> probably a good idea to get more clarity on Apache's rules and regs. :-)
>
> Thanks! :-)
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Code change the Apache way
Posted by "Noel J. Bergman" <no...@devtech.com>.
> a code change [only needs] a majority vote (even a -1 isn't blocking).
Please explain this. Because I really want to understand, and I had
understood it differently. From
http://jakarta.apache.org/site/decisions.html:
"Changes to the products of the Project, including code and documentation,
will appear as action items in the status file. All product changes to the
currently active repository are subject to lazy consensus."
I'd interpreted this to say that CVS changes are subject to lazy consensus.
And the document says that "[an] action requiring consensus approval must
receive at least 3 binding +1 votes and no binding vetos."
Please explain where I missed the point, and where I can find more
illuminating information. I figure that between my being a new Committer,
the talk about a PMC, and having to stand in front of 600 people in 10 days
talking about all of the wonderful Java technologies from Apache, it is
probably a good idea to get more clarity on Apache's rules and regs. :-)
Thanks! :-)
--- 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
Posted by Serge Knystautas <se...@lokitech.com>.
Guys, I gotta say, I don't think we're making a lot of headway
discussing this anymore. I think all sides have been raised their
points, and further communication does not seem to be benefitting anyone.
While complete consensus isn't achievable, this is just a code change
that's only needs a majority vote (even a -1 isn't blocking). Can we
just delete this class and move on?
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
Peter M. Goldstein wrote:
> Harmeet et al,
>
>
>>- There is no loss in keeping BaseHandler except for cleanup value.
>>- I think it is going to be useful as there will be common code in
>>handlers
>>that would be best handled in base class. There have been
>>patches/cleanups
>>proposed but not committed that you pointed out. There may be more in
>>future.
>>
>>Why don't you leave BaseHandler where it is for now and see if there
>
> are
>
>>some patterns across handlers that can be refactored into base.
>>
>
>
> I find this logic ridiculous. And I just don't buy it. It just doesn't
> explain the almost religious devotion you've expressed to
> BaseConnectionHandler in the face of all logic and reason. Even here
> you can't express an actual commonality that the BaseConnectionHandler
> would take advantage of measured against a clear benefit (what you refer
> to as cleanup).
>
> We have repeatedly stated that if and when a need for
> BaseConnectionHandler or its like arose, we would introduce such a
> class. But it's clear from the current code base and from the proposed
> patch that almost zero common behavior exists. So why won't you let
> this one go?
>
> Let me give you my theory, shall I? You mentioned in your email
> retracting the -1 on Noel that you had used parts of James in other
> projects. How much do we want to be that you are using the handlers
> with another service mechanism? One that requires a common subclass for
> your handlers - like BaseConnectionHandler ? Could this be the unstated
> motivation behind your religious devotion to BaseConnectionHandler.
> Somehow I think so...
>
> Why wouldn't you be explicit about this issue? Again, the reason is
> obvious. You know that the list would reject the needs of your personal
> software as a valid reason. And rightly so. So you make repeated
> statements, none of which have any actual backing or coherent logic.
> Like the one quoted above.
>
> Personally, I didn't sign up to work for kodemuse.org. I find this
> behavior an unethical abuse of committer privileges. I'll let the other
> members of this list read the back and forth and decide whether they
> agree with my assessment. But I'd bet $100 that if we ripped open the
> Kodemuse code we'd find a non-James service class using
> BaseConnectionHandler... Am I wrong?
>
>
> --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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
> But I'd bet $100 that if we ripped open the
> Kodemuse code we'd find a non-James service class using
> BaseConnectionHandler... Am I wrong?
You lose the bet. I don't use it. :-)
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
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Harmeet et al,
> - There is no loss in keeping BaseHandler except for cleanup value.
> - I think it is going to be useful as there will be common code in
> handlers
> that would be best handled in base class. There have been
> patches/cleanups
> proposed but not committed that you pointed out. There may be more in
> future.
>
> Why don't you leave BaseHandler where it is for now and see if there
are
> some patterns across handlers that can be refactored into base.
>
I find this logic ridiculous. And I just don't buy it. It just doesn't
explain the almost religious devotion you've expressed to
BaseConnectionHandler in the face of all logic and reason. Even here
you can't express an actual commonality that the BaseConnectionHandler
would take advantage of measured against a clear benefit (what you refer
to as cleanup).
We have repeatedly stated that if and when a need for
BaseConnectionHandler or its like arose, we would introduce such a
class. But it's clear from the current code base and from the proposed
patch that almost zero common behavior exists. So why won't you let
this one go?
Let me give you my theory, shall I? You mentioned in your email
retracting the -1 on Noel that you had used parts of James in other
projects. How much do we want to be that you are using the handlers
with another service mechanism? One that requires a common subclass for
your handlers - like BaseConnectionHandler ? Could this be the unstated
motivation behind your religious devotion to BaseConnectionHandler.
Somehow I think so...
Why wouldn't you be explicit about this issue? Again, the reason is
obvious. You know that the list would reject the needs of your personal
software as a valid reason. And rightly so. So you make repeated
statements, none of which have any actual backing or coherent logic.
Like the one quoted above.
Personally, I didn't sign up to work for kodemuse.org. I find this
behavior an unethical abuse of committer privileges. I'll let the other
members of this list read the back and forth and decide whether they
agree with my assessment. But I'd bet $100 that if we ripped open the
Kodemuse code we'd find a non-James service class using
BaseConnectionHandler... Am I wrong?
--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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> > Don't you expect some common code to exist in each handler?
>
> I did, however, raise this issue with Peter. What Peter has said is that
he
> doesn't see a need for it in the current code, and is perfectly
willing to
> add it when it becomes useful.
It looks like
- There is no loss in keeping BaseHandler except for cleanup value.
- I think it is going to be useful as there will be common code in handlers
that would be best handled in base class. There have been patches/cleanups
proposed but not committed that you pointed out. There may be more in
future.
Why don't you leave BaseHandler where it is for now and see if there are
some patterns across handlers that can be refactored into base.
> Since we don't have this code in the CVS, all I'm doing is kibbitzing with
> you and Peter on each of your private builds, and testing.
Thanks Noel. Appreciate it very much.
One could checkin proposals under the proposals area, but we don't seem to
be doing that very much.
> I don't think that this particular issue is a reason to hold up code
> release, do you?
This reason is a complete distraction. I don't see a big gain in this is
cleanup. My concern is that it reduces potential value and I have been a
unconfortable with us doing larger than need be changes. Do you or Peter
really care about this one ? I could enumerate some reuse ideas and we could
talk long about it, but I would prefer not to do it in this thread.
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Don't you expect some common code to exist in each handler?
Since we don't have this code in the CVS, all I'm doing is kibbitzing with
you and Peter on each of your private builds, and testing.
I did, however, raise this issue with Peter. What Peter has said is that he
doesn't see a need for it in the current code, and is perfectly willing to
add it when it becomes useful.
He points out that even the hello name is different with Remote Manager. I
thought, as you did, that there must be something in common but looking over
the code, there is very little. A few instance variables, maybe a couple of
convenience methods. In the latter case, Peter has a comment that they are
private final to encourage the compiler to inline them, since they are
purely syntactic sugar and he didn't want a performance hit.
If/when there really is a reason, it can be reintroduced without changing
anything outside of the handler. For example, if James v3 handlers use a
real command map, we could have a common handleConnection() method with an
abstract getCommands() method. That could be one justification for a
BaseConnectionHandler.
I don't think that this particular issue is a reason to hold up code
release, do you? Are you saying that the difference between a -1 and a +1
is whether or not (shorthand):
BCH { socket; watchdog; setWatchdog; }
is in the build?
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> BaseConnectionHandler is a misnomer, it is not part of the abstraction (as
> seen in the code), and it is vestigial. Therefore it is unnecessary now,
> and should there be some common implementation determined in the future,
it
> could be added by either inheritance or delegation without changing the
> abstraction.
The idea was to pull in common handler code in a base class. Was not and is
not used much and dosen't add much value today.
There is however commonality across handlers that could pushed in base
class. For instance socket related variables or common cleanup code. It may
be an under used but useful abstraction. Would be ok to cleanup or could be
useful to have around even if it doesn't do much. Don't you expect some
common code to exist in each handler ?
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> even the more important 'Interface for resettable,
> time-guarded, operations' issue has not been resolved.
I've been distracted on making sure that at least the path through
SMTPHandler, up to the point where it hands off to the spooler, is clean.
At the moment, I have a 12 hour run going with heap profiling turned on. It
appeared to be clean in a prelimnary heap snapshot last night. Also found a
few places where we can significantly reduce memory footprint, and cut down
on GC. The code running in this test is at least 33% faster than the code
previously reported on the October 18th, based upon my re-testing both SAR
files under the same conditions over hours long tests. YMMV.
> I would have preferred to have a better scheduler implementation
> in place till the 'resettable, time-guarded' proposal is resolved.
Seems to me that you owed me a revised SAR file for testing. But don't
worry about it. I realized that it would be straightforward to wrap an
Avalon Scheduler inside a Watchdog interface. That basically has the same
impact, and pretty much the same signatures, as the earlier patch that
didn't make it into BaseConnectionHandler. The handler would be isolated
from the implementation.
> we should not be refactoring existing stable code and
> pulling in parts of Avalon unless we need to.
James is an Avalon application. My own opinion is that if James is going to
use additional packages, there should be a good reason not to use one
provided by Avalon; why create more footprint than we need? If there are
problems with the Avalon components, that should be communicated back to the
Avalon group. That said, there will be cases where other packages make
sense. The Watchdog is an example.
> I think is better to keep the current abstraction as
> there is lot of commonality between protocol handlers.
What "abstraction" do you have in mind? What "commonality" of *INTERFACE*
do protocol handlers have that isn't provided by the ConnectionHandler
interface provided by Avalon? BaseConnectionHandler provides common
IMPLEMENTATION, which should not be exposed outside of the handlers.
Now that you've gotten me to take a closer look at the object relationships,
I notice that BaseConnectionHandler's interface is:
BaseConnectionHandler extends AbstractLogEnabled implements Configurable
BaseConnectionHandler is a misnomer; it is NOT a ConnectionHandler. THAT
interface is introduced by each specific Handler, e.g.,
public class SMTPHandler
extends BaseConnectionHandler
implements ConnectionHandler, Composable, Configurable, Target
So what is in BaseConnectionHandler? Configuration data:
private static int DEFAULT_TIMEOUT = 1800000;
protected int timeout = DEFAULT_TIMEOUT;
protected String helloName;
public static String configHelloName(final Configuration configuration)
public void configure( final Configuration configuration )
public void releaseConnectionHandler(ConnectionHandler
connectionHandler)
None of that is necessary after making the change that you, yourself,
suggested, which is to have a single, shared, pre-prepared, service-wide
configuration object that is given to the handler. The release method isn't
used anywhere within James, which makes sense since in simple point of fact,
there is not one line of code in James, other than the "extends" clause for
each handler, that references BaseConnectionHandler.
> variables like Socket, Input Stream, Output Stream,
> etc. need not exist in separate handlers.
This is an implementation issue, not an abstraction, and not even present in
the current BaseConnectionHandler. For example, since
handlerConnection(Socket) is abstract in BaseConnectionHandler, I might
argue that it breaks encapsulation to put the instance variable in the
abstract class. The same is true of the values currently in
BaseConnectionHandler. As you suggested, amongst others, handler
configuration is a shared object that is passed to each handler by the
HandlerFactory. So the timeout values for that service are shared. The
hello name for that service is shared. Etc.
BaseConnectionHandler is a misnomer, it is not part of the abstraction (as
seen in the code), and it is vestigial. Therefore it is unnecessary now,
and should there be some common implementation determined in the future, it
could be added by either inheritance or delegation without changing the
abstraction.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Regd. service refactoring I had promised to send an alternate patch in, but
had not done so.
I hoping to not get into a long discussion on this one, as even the more
important
'Interface for resettable, time-guarded, operations' issue has not been
resolved. I would have preferred to have a better scheduler implementation
in place till the 'resettable, time-guarded' proposal is resolved.
This is an attempt to finish something I had promised to send earlier. My
main motivation is that we should not be refactoring existing stable code
and pulling in parts of Avalon unless we need to. If there are specific
issues in the way James is architected we should resolve exactly that.
In this patch I have broken the dependency between POP3Handler and
BaseConnectionHandler, but I think is better to keep the current abstraction
as there is lot of commonality between protocol handlers. For instance
variables like Socket, Input Stream, Output Stream etc need not exist in
separate handlers.
This is a complete working patch.
Hope this discussion doesn't trigger another looong round.
Harmeet
here is what the patch addressees:
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
There were a number of very serious problems with the handler heavy
approach.
First, there was the simple expense. Server objects are created once
per service, handler objects are created, fed through the lifecycle, and
destroyed multiple times a second. Thus it is advantageous to move as
much of the lifecycle expense into the server code.
Second, there's a bizarre division of configuration information.
RE: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [Harmeet]
> One time timer task rather than repeated timer tasks is the same thing as
> Watchdog timeout. It is property of implementation.
> Schedulers can work like one-time alarm clocks.
If I recall correctly, the Scheduler interface isn't designed to support
truly lightweight special purpose timeouts. It is designed to act as a
manager -- as a mux. And that imposes overhead, unless you just ignore the
interface contract.
> If you have an object that monitors timeout on lots of events, it would
have
> the same property and load. It may be called a watchdog or a scheduler.
A lightweight watchdog doesn't monitor lots of events.
> lightweight-effiicient etc. are properties of implementation. The
scheduler
> abstraction cannot enforce or avoid any of these.
An interface is a contract specifying abstract behavior, and it does have an
impact.
scheduler.addTrigger( this.toString(), trigger, this );
scheduler.resetTrigger(this.toString());
Unless you're willing to discard the contract and say that THIS Scheduler
implementation has a different semantic interpretation then you have both a
string lookup issue and an obligation to handle multiple triggers. I'd
rather have a well-defined interface for a watchdog object than depend upon
an unusual semantic interpretation of the Scheduler interface that makes my
client code dependent upon a particular implementation of Scheduler.
> [Harmeet]
> A Config object can take care of this. Handlers don't need to
> expose themselves to lifecycle. What you are describing is configuration
per
> handler and as you pointed out that is not needed.
Are you proposing that servers be (semi-)generic Avalon Frameworks objects,
and that most of the work be done in a handler that is not integrated with
the Avalon lifecycle?
> [Harmeet]
> Listener-dispactch(handler) is the pattern followed in current code. It is
> more flexible than server class hierarchy. The missing piece is confusing
> and repeated configuration of the handler not a problem with the pattern
> iteself. Most other servers try to separate the listeners from dispatch
> workers/handlers.
I agree that a server -- dispatch --> worker model is good. I disagree that
the server is 100% generic, although there should be considerable common
code. More below.
> > Adding a "params" object would either require re-validation
> Params/Config need not require revalidation and if they do there will be
the
> overhead that you are avoiding by server class hierarchy.
I'm not sure, but I think that the two of you are missing each other's
points on this one. Here is my take:
Any common "params" object, post-initialization, would be configured with
validated information specific to the needs of a given service. It would be
"common" to the handlers, but not to other services. SOMEONE is responsible
for instantiating and populating the service specific configuration
information from the environment's configuration information. That someone
is the SERVER, not the handler, to my way of thinking. Therefore, if for no
other reason, there is a notion of service specific server behavior.
Minimal, perhaps, but existent.
> Cache the config. Precalculation for handlers, isn't that the only gain in
> having a server class hierarchy. Maybe that idea can be abstracted and
used
> with current model.
Yes, caching a config object could be abstracted, but instantiating and
populating it is still service specific. And unless the config object has a
(slow) generic access mechanism (like a property table), it is going to be a
service specific type. So, yes, you could have a config bean, but it would
still be a service specific type.
If you disagree, please outline the alternative.
> I am saying listeners are generic. Handlers/Workers are specific. A mix
> of two makes service and servers.
Did I miss someone adding a protocol specific listener? Where? And are you
saying that there is nothing specific to a service other than the handler?
> But a socket listener associated with SMTP handler makes an SMTP Service.
Who knows about preparing service specific configuration information, such
as maximum message size, online filtering, or authentication options?
Surely not the handler, which doesn't get invoked until there is a
conversation ready to happen.
> An incremental and better system would be Socket Listener with Config
Object
> and Handler makes a Service.
> A Bad State would be a server class hierarchy that couples Listener,
Config
> and Handler.
If there is nothing specific about being a server other than configuration
information, then we might get away with a single generic server, and
Class-based instantiation of service specific objects:
<service type="Foo" ...>
...
</service>
config = Class.forName(getType() + "Config");
handler = Class.forName(getType() + "Handler");
But I don't know if we've established that configuration information is the
only service specific behavior. And it seems to me that Avalon pretty much
does the preceeding, except that "Config" is the block / service.
-------------------------------
> > So if you wanted to have two different SSL socket types,
> > one for use by the NNTP server and another for use by the
> > SMTP server (a very common configuration), then you would
> > have to run two separate servers. Very bad.
> It is pretty standard. Take a look at tomcat. They do the same thing.
Huh? Behind the "Connectors" the code is the same, and in their case, the
wire level protocols are different. In this case, the protocol is NNTP,
SMTP, IMAP, POP3, ..., regardless of whether the transport layer is secure
or not. Oughtn't that be primarily a function of the listener, not the
handler?
> The observer-observable is a clean and standard pattern way. It allows an
> observer to monitor and decide on timeout reset.
Yah, but what is the observer, and what/how is it observing? That is a
valid question. Are you observing in the domain of a byte stream, or are
you observing in the domain of a semantic protocol? That appears to be the
specific nature of this dispute.
--- 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
Posted by Nathan Carter <na...@gmx.net>.
Noel,
Noel J. Bergman wrote:
>>We should have a set of functionality and performance
>>tests before we get into (re)architecture esp. if the
>>changes are ment to improve performance.
>
>
> I agree that we should have tests for performance and adherence to
> specifications, but what are you proposing with respect to getting James 2.1
> released? Are you proposing that all work on James cease until there is a
> new test suite authored, or just that we prepare unit tests at the beginning
> of work for James v3 so that we can do regression and performance testing as
> changes in code and architecture occur?
>
> Personally, I agree with the latter, but I have some concern about the
> former. The current code is demonstrably better than the current release,
> and the plan was to get out a stable replacement for 2.0a3, fork it as a
> maintainable branch, and then look at future work. The scheduler problem,
> and the benefit of switching to the watchdog code, is demonstrable. Do you
> read the James User list as well as the James Developer list?
>
>
>>Checking in JUnit based test suite for POP3 protocol in a short while.
>>Planning to add SMTP and NNTP too. IMAP would be an excellent addition.
>
>
> You might also want to take a look at Russell Coker's POSTAL performance
> tests (http://www.coker.com.au/postal/). External tests don't need to be
> written in Java to be useful.
>
>
>>Currently it exercises POP3 Protocol and collects performance stats but it
>>does not check for correctness.
>
>
> There are plenty of available performance metrics, so IMO we need
> correctness testing more than we need performance testing.
>
Especially when we begin looking seriously at IMAP, which has
historically been quite difficult to do "correctly".
>
>>Would be good get our testing strategy to a better level.
>
>
> Is this something you have the time to do, and take responsibility for? Do
> you have time to take a lead role and work with other volunteers to
> coordinate a test plan and suite?
>
> [Nathan]
>
>>>using a profiling tool to see how much time is actually being
>>>wasted by configuring each Handler instead of more tightly
>>>coupling them to the server listener.
>>
>
> This one is pretty a priori. The plain fact is that a handful of simple
> setX methods is going to be faster than even just the string lookup part of
> pulling named attributes from a DOM. Whether or not the performance savings
> is significant is a different matter. My guess is more than likely not,
> although there are also savings related to transient objects and garbage
> collection, because the operation of the handler will be relatively large
> compared to its initialization. HOWEVER, there is more to architecture than
> JUST performance. :-)
>
Yes - based on people's testing so far, it sounds as though there is a
definite improvement. As I just mentioned in another reply, I was
unaware of the overall history and background of the issue. I did, just
for fun, run a profiler on the JVM last night while James was running
under light load, but I'm not familiar enough with the Avalon classes at
this point to interpret the (quite complex) results.
> [Nathan]
>
>>>JMeter doesn't seem to support email server load testing
>>>- is there anything better than this?
>>
>
> See Russell Coker's postal (above).
>
> [Nathan]
>
>>>Again, I'd be more than happy to help in testing because this
>>>significantly affects what I'm doing in IMAP, and I'm going to have to
>>>perform this kind of testing on IMAP due to its complexity and higher
>>>overhead.
>>
>
> Again, more important than performance is adherence to the RFCs. If, as is
> appropriate, there is going to be effort put into testing, I think that the
> first thing for folks to do is learn the RFCs (or at least OF them) and
> write test specs to ensure that the code is CORRECT.
>
Trust me - I have a 3-inch thick (dead trees) stack of email related
RFCs that have been my subway reading material for the last few weeks ;)
>
>>I was initially thinking of using jython and writing JUnit tests with it.
>
>
> Has anyone integrated JUnit with the Avalon lifecycle? Remember that these
> things run in a context that is not obvious to JUnit. I've run google
> looking for references, but no luck.
>
>
>>Velocity was the preffered template language choice.
>
>
> Must have been before my time. I dislike Velocity intensely. There are any
> number of other choices.
>
> By the way, Harmeet, if you have some spare time on your hands, a bridge for
> writing matchers and mailets in jython (or any BSF supported scripting
> language) would be slick. :-)
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
-Nathan
--
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
Charles,
I've always said that I'm not a CVS guru. I had a concept of the goal, and
it sounds like you are indicating how to accomplish the goal with a
different (defered) mechanism. So what you are saying is that we "tag" the
release as Danny suggested, and then WHEN we need to make a fix in a prior
release, we create a "branch" at that time? [Yes, "fork" === "branch" as I
was using the term] Works for me.
Thanks. :-) Much appreciated.
--- Noel
-----Original Message-----
From: Charles Benett [mailto:charlesb@apache.org]
Sent: Sunday, October 13, 2002 14:04
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
Noel,
When you say "fork" do you mean "create a branch in CVS" (per Chapter 5
of CVS manual)? If so, I disagree with you and Danny.
Surely we create a branch (in CVS) after we have a bug-fix to an
existing release? At least, that's my understanding of the CVS docs.
In which case, discussion of to branch or not to branch can be deferred
until we have the next release and a critical bug (ie one requiring a
bug-fix release).
All that we need to do now is to make the new release and tag the
release in CVS.
Charles
Noel J. Bergman wrote:
>If we fork it, and find that we don't have time, we've lost nothing. If we
>don't create the fork, and find a need to issue some critical bug fix(es),
>then we've got a bigger problem. Seems the prudent thing to do, especially
>since it sounds like the next release cycle may introduce compatibility
>issues due to API changes.
>
> --- Noel
>
>-----Original Message-----
>From: Danny Angus [mailto:danny@apache.org]
>Sent: Sunday, October 13, 2002 12:33
>
>We've never maintained a branch for a release before, I don't think we have
>the resources.
>I really can't see that we have enough time to maintain two different
>versions of James, though the principle is reasonable of itself.
>Its my view that we should tag the release, and address bug fixes in the
>next release cycle.
>
>d.
>
>
>
>>-----Original Message-----
>>From: Noel J. Bergman [mailto:noel@devtech.com]
>>Sent: 12 October 2002 23:30
>>
>>
>>
>>>There is no reason to fork the code if its going to evolve.
>>>
>>>
>>The reason for forking is simply to be able to put out fixes to
>>the 2.1 code based after we make major API changes. If you have
>>an alternative that permits both, great.
>>
>> --- Noel
>>
>>
>
>
>--
>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>
--
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
Posted by Danny Angus <da...@apache.org>.
> All that we need to do now is to make the new release and tag the
> release in CVS.
>
> Charles
+1 quite right Charles!
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
Posted by Charles Benett <ch...@apache.org>.
Noel,
When you say "fork" do you mean "create a branch in CVS" (per Chapter 5
of CVS manual)? If so, I disagree with you and Danny.
Surely we create a branch (in CVS) after we have a bug-fix to an
existing release? At least, that's my understanding of the CVS docs.
In which case, discussion of to branch or not to branch can be deferred
until we have the next release and a critical bug (ie one requiring a
bug-fix release).
All that we need to do now is to make the new release and tag the
release in CVS.
Charles
Noel J. Bergman wrote:
>If we fork it, and find that we don't have time, we've lost nothing. If we
>don't create the fork, and find a need to issue some critical bug fix(es),
>then we've got a bigger problem. Seems the prudent thing to do, especially
>since it sounds like the next release cycle may introduce compatibility
>issues due to API changes.
>
> --- Noel
>
>-----Original Message-----
>From: Danny Angus [mailto:danny@apache.org]
>Sent: Sunday, October 13, 2002 12:33
>
>We've never maintained a branch for a release before, I don't think we have
>the resources.
>I really can't see that we have enough time to maintain two different
>versions of James, though the principle is reasonable of itself.
>Its my view that we should tag the release, and address bug fixes in the
>next release cycle.
>
>d.
>
>
>
>>-----Original Message-----
>>From: Noel J. Bergman [mailto:noel@devtech.com]
>>Sent: 12 October 2002 23:30
>>
>>
>>
>>>There is no reason to fork the code if its going to evolve.
>>>
>>>
>>The reason for forking is simply to be able to put out fixes to
>>the 2.1 code based after we make major API changes. If you have
>>an alternative that permits both, great.
>>
>> --- Noel
>>
>>
>
>
>--
>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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
If we fork it, and find that we don't have time, we've lost nothing. If we
don't create the fork, and find a need to issue some critical bug fix(es),
then we've got a bigger problem. Seems the prudent thing to do, especially
since it sounds like the next release cycle may introduce compatibility
issues due to API changes.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Sunday, October 13, 2002 12:33
We've never maintained a branch for a release before, I don't think we have
the resources.
I really can't see that we have enough time to maintain two different
versions of James, though the principle is reasonable of itself.
Its my view that we should tag the release, and address bug fixes in the
next release cycle.
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 12 October 2002 23:30
>
> > There is no reason to fork the code if its going to evolve.
>
> The reason for forking is simply to be able to put out fixes to
> the 2.1 code based after we make major API changes. If you have
> an alternative that permits both, great.
>
> --- 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
Posted by Danny Angus <da...@apache.org>.
We've never maintained a branch for a release before, I don't think we have the resources.
I really can't see that we have enough time to maintain two different versions of James, though the principle is reasonable of itself.
Its my view that we should tag the release, and address bug fixes in the next release cycle.
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 12 October 2002 23:30
> To: James Developers List
> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> > There is no reason to fork the code if its going to evolve.
>
> The reason for forking is simply to be able to put out fixes to
> the 2.1 code
> based after we make major API changes. If you have an alternative that
> permits both, great.
>
> --- Noel
>
>
> --
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
> There is no reason to fork the code if its going to evolve.
The reason for forking is simply to be able to put out fixes to the 2.1 code
based after we make major API changes. If you have an alternative that
permits both, great.
--- 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
Posted by Danny Angus <da...@apache.org>.
> Personally, I agree with the latter, but I have some concern about the
> former. The current code is demonstrably better than the current release,
> and the plan was to get out a stable replacement for 2.0a3, fork it as a
> maintainable branch,
There is no reason to fork the code if its going to evolve.
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We should have a set of functionality and performance
> tests before we get into (re)architecture esp. if the
> changes are ment to improve performance.
I agree that we should have tests for performance and adherence to
specifications, but what are you proposing with respect to getting James 2.1
released? Are you proposing that all work on James cease until there is a
new test suite authored, or just that we prepare unit tests at the beginning
of work for James v3 so that we can do regression and performance testing as
changes in code and architecture occur?
Personally, I agree with the latter, but I have some concern about the
former. The current code is demonstrably better than the current release,
and the plan was to get out a stable replacement for 2.0a3, fork it as a
maintainable branch, and then look at future work. The scheduler problem,
and the benefit of switching to the watchdog code, is demonstrable. Do you
read the James User list as well as the James Developer list?
> Checking in JUnit based test suite for POP3 protocol in a short while.
> Planning to add SMTP and NNTP too. IMAP would be an excellent addition.
You might also want to take a look at Russell Coker's POSTAL performance
tests (http://www.coker.com.au/postal/). External tests don't need to be
written in Java to be useful.
> Currently it exercises POP3 Protocol and collects performance stats but it
> does not check for correctness.
There are plenty of available performance metrics, so IMO we need
correctness testing more than we need performance testing.
> Would be good get our testing strategy to a better level.
Is this something you have the time to do, and take responsibility for? Do
you have time to take a lead role and work with other volunteers to
coordinate a test plan and suite?
[Nathan]
> > using a profiling tool to see how much time is actually being
> > wasted by configuring each Handler instead of more tightly
> > coupling them to the server listener.
This one is pretty a priori. The plain fact is that a handful of simple
setX methods is going to be faster than even just the string lookup part of
pulling named attributes from a DOM. Whether or not the performance savings
is significant is a different matter. My guess is more than likely not,
although there are also savings related to transient objects and garbage
collection, because the operation of the handler will be relatively large
compared to its initialization. HOWEVER, there is more to architecture than
JUST performance. :-)
[Nathan]
> > JMeter doesn't seem to support email server load testing
> > - is there anything better than this?
See Russell Coker's postal (above).
[Nathan]
> > Again, I'd be more than happy to help in testing because this
> > significantly affects what I'm doing in IMAP, and I'm going to have to
> > perform this kind of testing on IMAP due to its complexity and higher
> > overhead.
Again, more important than performance is adherence to the RFCs. If, as is
appropriate, there is going to be effort put into testing, I think that the
first thing for folks to do is learn the RFCs (or at least OF them) and
write test specs to ensure that the code is CORRECT.
> I was initially thinking of using jython and writing JUnit tests with it.
Has anyone integrated JUnit with the Avalon lifecycle? Remember that these
things run in a context that is not obvious to JUnit. I've run google
looking for references, but no luck.
> Velocity was the preffered template language choice.
Must have been before my time. I dislike Velocity intensely. There are any
number of other choices.
By the way, Harmeet, if you have some spare time on your hands, a bridge for
writing matchers and mailets in jython (or any BSF supported scripting
language) would be slick. :-)
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Nathan Carter" <na...@gmx.net>
> 1) This thread is quite interesting because I've asked many of these
> same questions in beginning to look at the IMAP stuff, which in many
> cases (at least the listener and handler code) seems to be based on old
> versions of the POP equivalents (i.e., they are missing august and
> september changes by danny and peter to the POP code).
>
> 2) In your initial post, you mention doing some "basic" and "load"
> testing to further quantify the memory/robustness/scalability issues and
> show how your patch solves them. What about (and I'd be happy to donate
> time for this):
This is an excellent idea. We should have a set of functionality and
performance tests before we get into (re)architecture esp. if the changes
are ment to improve performance.
Checking in JUnit based test suite for POP3 protocol in a short while.
Planning to add SMTP and NNTP too. IMAP would be an excellent addition.
Currently it exercises POP3 Protocol and collects performance stats but it
does not check for correctness.
Had to jump through a few hoops to reach a happy point with the test suite.
Please review the changes in testing package. Would be good get our testing
strategy to a better level.
>
> a)using a profiling tool to see how much time is actually being
> wasted by configuring each Handler instead of more tightly coupling them
> to the server listener.
This information should be very helpful, end to end stat collection may
supplement and verify but we really should throw a profiler. Would you be
able to do that ?
>
> b)Do you have before/after metrics for your load tests? A 2X
> improvement will be a strong argument in itself. JMeter doesn't seem to
> support email server load testing - is there anything better than this
> (e.g. PushToTest,
> http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
This looks like a good tool. It may be better to have performace and
functionality test suites driven by the same code. Java/JUnit seems better
than tcl to me, but try this out. Have you used this tool ?
>
> Again, I'd be more than happy to help in testing because this
> significantly affects what I'm doing in IMAP, and I'm going to have to
> perform this kind of testing on IMAP due to its complexity and higher
> overhead.
That would be wonderful.
Here are some thoughts that may or may not be useful to you:
I was initially thinking of using jython and writing JUnit tests with it.
This was discussed earlier on this list.
One strategy for testing was to have a record-replay mechanism. Velocity was
the preffered template language choice. (webmacro was talked about too, but
not favored)
For POP3 test, I am using Jakarta Commons. Test use is similar to FetchPOP
functionality. Jakarta-commons seemed nice but it does not have IMAP,
Jython/Python has an IMAP library.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tests, scheduler and release..
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 1/ that Harmeet move the whole of o.a.j.testing (including the
> pre-existing potocol tests) into a proposal or first
> sub-directory of jakarta-james where it can be used to create
> an independantly distributable test suite.
Seems good.
2/ that the scheduler/watchdog and service issues be defered until after the
release.
Disagree. More below.
3/ we move on with the release as planned.
Yes.
> .. otherwise these will hold up what is regarded as being a
> much needed release of the 2.1a1 code.
Instead we would hold up a needed and long awaited change? I would rather
hash this out with Harmeet and see it committed, if that doesn't take too
much longer. And I think that is realistic, since he specifically said that
he is willing to give his +1 if everyone else agrees.
> I'd also propose that those concerned with the issues note
> them in a todo file in the root of the jakarta-james module
> to be addressed after the release.
General question: HOW? Do we submit a patch for the TODO file?
> Unless I am missing something important none of this
> was current before the release plan, none of it
> represents fixes for pre-existing reported bugs
Actually, this is the part that's not correct. All of this is based upon
defects identified by Andrei months ago, and discussed on the list by he,
myself, Serge, Paul, Peter and others. It was also discussed on the Avalon
Developers mailing list. The same problem that was reported last week, and
verified by you, was the impetus for fixing this. If Peter hadn't taken the
time to work on NNTP first, this would have been posted weeks ago, if not
longer.
> I'm concerned that progress with the release will founder
> if we get involved in protracted debate (or worse..)
Again, a general question: what is the mechanism for resolving a debate,
other than agreement?
> I have a number of significant changes I am withholding
> until then for exactly these reasons.
LOL I can imagine we'll be having fun. :-) Please note that I will be at
Colorado Software Summit the first week of November
(www.softwaresummit.com), so no fair making decisions that week! ;-)
Not that I get a vote. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tests, scheduler and release..
Posted by "Noel J. Bergman" <no...@devtech.com>.
> It causes them to crash disastrously under any serious load.
So when Danny posts his load test code, we ought to be able to verify that
these changes do, in fact, correct the problem. :-)
> This is not a little game to me. I'm not interested in getting a beer
> from anyone - I want the server to work the way it should.
Hopefully, everyone takes James seriously. Personally, I run James as our
primary mail server, with about 200 users receiving e-mail through it, a
bunch of mailing lists, and a bit more than a dozen domains. I need for
James to work. As a professional matter, I always look at code change as
introducing the risk of defects, and tests are important. But when we can
reproduce a failure, fixing it is a good thing. If people are to start
running James more widely, I don't think that we don't want it to fail in
such a resource constrained manner if we have the fix.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Tests, scheduler and release..
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> 1/ that Harmeet move the whole of o.a.j.testing (including the pre-
> existing potocol tests) into a proposal or first sub-directory of
jakarta-
> james where it can be used to create an independantly distributable
test
> suite.
+1
> 2/ that the scheduler/watchdog and service issues be defered until
after
> the release.
-1
IMHO there is no point doing the release until this issue is addressed.
This isn't a minor little problem. This is a core issues that affects
every single service on the system. It causes them to crash
disastrously under any serious load.
There hasn't been a single coherent objection to the changes proposed
other than "that's not the way it used to work". Every question has
been answered, every issue addressed. If there are more serious
questions/issues about the design/implementation let's hear them. If
there's an objection other than "I don't see why we should change
things", then let's hear it. If not, let's put the patch in and fix the
outstanding problems.
This is not a little game to me. I'm not interested in getting a beer
from anyone - I want the server to work the way it should.
> 3/ we move on with the release as planned.
>
> .. otherwise these will hold up what is regarded as being a much
needed
> release of the 2.1a1 code.
One of the reasons it's much needed (as the recent dialogue on the James
user list makes clear) is precisely the scheduler problem that we're
addressing. Leaving it unaddressed only exacerbates the problem.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Tests, scheduler and release..
Posted by Danny Angus <da...@apache.org>.
I have a proposal to make.
1/ that Harmeet move the whole of o.a.j.testing (including the pre-existing potocol tests) into a proposal or first sub-directory of jakarta-james where it can be used to create an independantly distributable test suite.
2/ that the scheduler/watchdog and service issues be defered until after the release.
3/ we move on with the release as planned.
.. otherwise these will hold up what is regarded as being a much needed release of the 2.1a1 code.
I'd also propose that those concerned with the issues note them in a todo file in the root of the jakarta-james module to be addressed after the release.
Unless I am missing something important none of this was current before the release plan, none of it represents fixes for pre-existing reported bugs, and its deferal does not detract from the fact that this release marks an improvement in James over the 2.0a3 release.
I'm concerned that progress with the release will founder if we get involved in protracted debate (or worse..) on these issues, and I have a number of significant changes I am withholding until then for exactly these reasons.
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: <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>
RE: [PATCH] Removing Scheduler dependency, refactoring service code-P
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> I ran the postal test for a little while against Harmeet's server with
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.
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.
Noel, code will address these issues.
> creating a new Event object, iteratively SEARCHING the timerMap to find
the
> next open time after the one we want, creating a new Event each iteration,
> and then adding the final Event to both the TreeMap and the HashMap.
> it cannot effectively handle a time for less than the current wake
> time, due to the operational loop:
> Another change is that the constrant re-creation of Entry objects should
be
> replaced by a mutator method that changes the internal values.
Noel/others, could you please review this and suggest patches.
Additional testing would be a big help too. I will also do additional
testing.
thanks,
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
I forgot to mention a key point. Remember that the high duty cycle is this
code:
synchronized void reset(String id) {
Entry entry = (Entry)idMap.remove(id);
timerMap.remove(entry.scheduledTime);
entry = new Entry(entry.offset,entry.id,entry.trg);
// move by on millisec, if there is a stored entry
while ( timerMap.containsKey(entry.scheduledTime) ) {
entry = new Entry(entry.offset+1,entry.id,entry.trg);
}
timerMap.put(entry.scheduledTime,entry);
idMap.put(entry.id,entry);
}
The general operation of this method slows down as you add additional
threads (thus additional entries in the mechanism). Further, all of the
other client threads have to wait (contend) for the synchronized block. It
means that during I/O handling, all protocol handlers have to take their
turn when resetting their watchdogs because of this implementation. The
more threads, the more contention.
--- 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
Posted by "Noel J. Bergman" <no...@devtech.com>.
I ran the postal test for a little while against Harmeet's server with 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.
Performing a resetTrigger is a significantly more costly operation than
either the Watchdog implementation or the Avalon scheduler implementation,
demonstrating some of the challenges involved in maintaining a
single-threaded multi-event timing mechanism.
The high duty cycle is this code (I've unwrapped one method):
synchronized void reset(String id) {
Entry entry = (Entry)idMap.remove(id);
timerMap.remove(entry.scheduledTime);
entry = new Entry(entry.offset,entry.id,entry.trg);
// move by on millisec, if there is a stored entry
while ( timerMap.containsKey(entry.scheduledTime) ) {
entry = new Entry(entry.offset+1,entry.id,entry.trg);
}
timerMap.put(entry.scheduledTime,entry);
idMap.put(entry.id,entry);
}
Resetting the timer involves removing from both a TreeMap and a HashMap,
creating a new Event object, iteratively SEARCHING the timerMap to find the
next open time after the one we want, creating a new Event each iteration,
and then adding the final Event to both the TreeMap and the HashMap.
The code wakes up periodically to check the next entry in the TreeMap. One
limitation in this implementation is that once the scheduler starts
sleeping, it cannot effectively handle a time for less than the current wake
time, due to the operational loop:
synchronized void execFirstTask() throws InterruptedException {
// sleep if there is nothing.
while ( timerMap.isEmpty() )
Thread.currentThread().sleep(1000);
Long first = (Long)timerMap.firstKey();
long future = first.longValue()-System.currentTimeMillis();
if ( future > 0 )
Thread.currentThread().sleep(future);
else {
Entry entry = (Entry)timerMap.remove(first);
idMap.remove(entry.id);
entry.trg.targetTriggered(entry.id);
}
}
One way to fix that is to modify the code so that if the new trigger time is
less than the current wake time, that the thread is interrupted so that it
can go back to sleep for the correct time.
Another change is that the constrant re-creation of Entry objects should be
replaced by a mutator method that changes the internal values.
This basically showcases the tradeoffs between a multi-threaded solution and
a single-threaded solution. There is still significant and unavoidable
overhead due to all of the collection manipulation, creation of a
non-mutable Long object to be a key value, and synchronization. The
tradeoff is that it runs with one thread. However, if having more threads
is an issue in some implementation, this is one way to do it.
As I mentioned earlier, this code could easily sit underneath the Watchdog
interface, and I would actually prefer that solution for a variety of
reasons. The chang in our handlers is trivial, it would be easier to Unit
test, and more reusable. Given that we have our own implementation, there
is no reason to hardwire it to Avalon Frameworks. A useful watchdog, with
multi-threaded and single-threaded implementations could be submitted to
Commons, and easily bridged to the Avalon Frameworks interfaces if that
group also wants to use it. In our case, we could also use it in code that
is not married to Avalon Frameworks, e.g., multi-threaded mailets.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Sunday, October 13, 2002 22:41
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
Here is a patch that seems to hold up fine.
It involves a TimeScheduler implemenation.
Please try it out.
Ran with danny test, 20 threads and no upper bound. Seems to be stable and
not leak memory.
Please try it out.
thanks,
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Here is a patch that seems to hold up fine.
It involves a TimeScheduler implemenation.
Please try it out.
Ran with danny test, 20 threads and no upper bound. Seems to be stable and
not leak memory.
Please try it out.
thanks,
Harmeet
Re: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Actually use this one for TimeSchedulerImpl.java from part 2 for load test.
only diff is that I have removed redundant printlns
The patches I have sent should work without problems on latest codebase.
That is what I have tested on.
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, October 13, 2002 12:54 AM
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service code
> Part 2 for the scheduler. Here is an alternate scheduler implementation
that
> I have tested with as well.
>
> Nice thing about this one is that, it implements the scheduler contract
and
> uses JDK timer classes to do the task scheduling - java.util.Timer(Task).
In
> this case scheduled task being fire timeout trigger.
>
> If there are problems with scheduler implementations, one could have a
> Scheduler implementation that is a hybrid of watchdog-timer ideas and is
not
> as heavy as watchdog.
>
> Check it out...
>
> Harmeet
> ----- Original Message -----
> From: "Harmeet Bedi" <ha...@kodemuse.com>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Sunday, October 13, 2002 12:43 AM
> Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
>
>
> > Here is the code. Danny/Noel/Peter if you could test this for load.
> >
> > This post has the right way to use scheduler for James fix.
> >
> > The watchdog approach calls for one thread per handler to watch for
> timeout.
> > So per connection there will be 2 threads - Handler and Watchdog.
Although
> > the Thread will mostly be in wait-notify state, it is still very heavy
and
> > unavailable.
> > In this approach there is a scheduler per handler, one additional
thread.
> > This will allow James to scale more smoothly.
> >
> > I have tested this with cornerstone scheduler and after replacing
> > cornerstone scheduler with another implementaion that I have been using.
> >
> > It is entirely possible that watchdog approach may be better, but by
> looking
> > at the thread semantics it would be a surprise to me.
> >
> > I suggest taking this POP3 implementation and the one Peter has sent out
> and
> > doing a load comparison.
> >
> > There is nothing better than 2 developers pushing their point of view
and
> > the gain is to be had by all. :-)
> >
> > 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Part 2 for the scheduler. Here is an alternate scheduler implementation that
I have tested with as well.
Nice thing about this one is that, it implements the scheduler contract and
uses JDK timer classes to do the task scheduling - java.util.Timer(Task). In
this case scheduled task being fire timeout trigger.
If there are problems with scheduler implementations, one could have a
Scheduler implementation that is a hybrid of watchdog-timer ideas and is not
as heavy as watchdog.
Check it out...
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, October 13, 2002 12:43 AM
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service code
> Here is the code. Danny/Noel/Peter if you could test this for load.
>
> This post has the right way to use scheduler for James fix.
>
> The watchdog approach calls for one thread per handler to watch for
timeout.
> So per connection there will be 2 threads - Handler and Watchdog. Although
> the Thread will mostly be in wait-notify state, it is still very heavy and
> unavailable.
> In this approach there is a scheduler per handler, one additional thread.
> This will allow James to scale more smoothly.
>
> I have tested this with cornerstone scheduler and after replacing
> cornerstone scheduler with another implementaion that I have been using.
>
> It is entirely possible that watchdog approach may be better, but by
looking
> at the thread semantics it would be a surprise to me.
>
> I suggest taking this POP3 implementation and the one Peter has sent out
and
> doing a load comparison.
>
> There is nothing better than 2 developers pushing their point of view and
> the gain is to be had by all. :-)
>
> Harmeet
Re: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Harmeet Bedi" <ha...@kodemuse.com>
> - I'll post cleaner code for POP3 and SMTP handler.
Here is the somewhat cleaner POP3 and SMTP fixes for scheduler. POP3 and
SMTP are the same so either should work to understand the fix.
Basically
- Server object creates handler, (current code)
- Sets scheduler for handler and a handler unique ID. (new code)
- Handler schedules events of interest with scheduler as callback (current
code)
- Scheduler identifies handler with the handler unique id instead of
Handler#toString (changed code)
There is an additional thread created by the scheduler. It appears that
there is one more threads before and after patch for James server, but it
leaves the thread pool free to handle higher load.
> - Patch my server.
I have patched my server for POP3 and SMTP.
from earlier mail:
> I have opened up port 110, 25, 4555(for remote manager). My home IP Is
> 24.102.230.223.
There are 11 users - harmeet, user1, user2, user3, user4, user5, user6,
user7, user8, user9, and userA and each user has at least one mail.
My server does not use the cornerstone scheduler but the implementation I
sent yesterday. Either implementation should work, unless there are
implementation bugs.
I am doing some work, and there are lots of things running. It would work
best if Noel/Danny/Peter/others who may want to test, to send me email when
you are about to hit my server. I'll make sure it is up and running. It is
running now, but I don't want to spam list if I bring it down. My yahoo IM
is hbedi, if that works better.
> - Post simpler service/configuration related code.
Will work on this next.
Harmeet
RE: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
> My understanding was JDK 1.3 was fine. I did not know this though. good
> link - thanks.
Welcome.
Mind you, that code doesn't accomplish what you seem to think it does.
AFAIK, there is only once scheduler, anyway, coming from the
componentManager.lookup() call, so all you've done is change an instance
reference to a shared object to a static reference to a shared object. A
lot of work for no real gain. So long as the code uses the default
scheduler, the problem remains. I didn't have time to look at your other
scheduler implementation, and you seem to be saying you've got other ideas
to test.
> Butm this was a short term fix. I wanted to limit changes to one file
I don't have a good test for the POP3 side. I have a good test for the SMTP
side (actually, we have two of them now :-)), hence the request for that
service to be the guinea pig. :-)
> It is worthwhile to test and use the best approach.
I agree. One question is how to measure "best". I'd say stability,
performance, and cleanliness are key issues, in just about that order.
I had portal hammering away on Peter's server (with his changes) all night.
It didn't die, but there was a definite performance degradation over time
that needs to be understood and fixed. Unclear if it is in the changes or
if we're just exposing another issue within James. I don't believe that the
problem is in postal because if I stop it and restart the performance picks
up where it left off.
When Andrei did his tests, he commented out the sendMail line in
SMTPHandler, so that he could isolate the Handler's issues from the rest of
James. That is probably a good idea.
- I'll post cleaner code for POP3 and SMTP handler.
- Patch my server.
- Post simpler service/configuration related code.
I look forward to seeing it.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
My understanding was JDK 1.3 was fine. I did not know this though. good
link - thanks.
Butm this was a short term fix. I wanted to limit changes to one file
- I'll post cleaner code for POP3 and SMTP handler.
- Patch my server.
- Post simpler service/configuration related code.
Peter, for now please continue to hold off on the patch. There may be better
ways of fixing scheduler/configuratio problem. It is worthwhile to test and
use the best approach.
give me another hour or so..
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, October 13, 2002 12:16 AM
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> Harmeet,
>
> More tomorrow, but my first glance at the code points something out. Are
> you not familar with this:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html?
You
> used the paradigm, which people initially thought was a good solution, but
> it has been shown that it simply doesn't work.
>
> Also, if you want me to re-run tests against your server, please update
> SMTPHandler. :-)
>
> --- Noel
>
>
> --
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
More tomorrow, but my first glance at the code points something out. Are
you not familar with this:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html? You
used the paradigm, which people initially thought was a good solution, but
it has been shown that it simply doesn't work.
Also, if you want me to re-run tests against your server, please update
SMTPHandler. :-)
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Here is the code. Danny/Noel/Peter if you could test this for load.
This post has the right way to use scheduler for James fix.
The watchdog approach calls for one thread per handler to watch for timeout.
So per connection there will be 2 threads - Handler and Watchdog. Although
the Thread will mostly be in wait-notify state, it is still very heavy and
unavailable.
In this approach there is a scheduler per handler, one additional thread.
This will allow James to scale more smoothly.
I have tested this with cornerstone scheduler and after replacing
cornerstone scheduler with another implementaion that I have been using.
It is entirely possible that watchdog approach may be better, but by looking
at the thread semantics it would be a surprise to me.
I suggest taking this POP3 implementation and the one Peter has sent out and
doing a load comparison.
There is nothing better than 2 developers pushing their point of view and
the gain is to be had by all. :-)
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, October 12, 2002 3:30 PM
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> I have been running James as a primary mail server all summer. In general
> it works, but try load testing.
>
> And yes, please post your code.
>
> --- Noel
>
> -----Original Message-----
> From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
> Sent: Saturday, October 12, 2002 20:43
> To: James Developers List
> Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> From: "Noel J. Bergman" <no...@devtech.com>
> > If I quote the Avalon developers telling you that you're wrong, does
that
> > count? ;-) You should be able to find the discussion in the Avalon
> > Developers mailing list archive.
>
> Not likely. I have been using scheduler for 1+ year. This mail goes
through
> to you with the help of a scheduler
> I'll make a patch, reading code is always more interesting than quoting.
>
> >
> > Cheap bet, by the way. I don't drink beer. :-)
>
> Good habit. :-)
>
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
I have been running James as a primary mail server all summer. In general
it works, but try load testing.
And yes, please post your code.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Saturday, October 12, 2002 20:43
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
From: "Noel J. Bergman" <no...@devtech.com>
> If I quote the Avalon developers telling you that you're wrong, does that
> count? ;-) You should be able to find the discussion in the Avalon
> Developers mailing list archive.
Not likely. I have been using scheduler for 1+ year. This mail goes through
to you with the help of a scheduler
I'll make a patch, reading code is always more interesting than quoting.
>
> Cheap bet, by the way. I don't drink beer. :-)
Good habit. :-)
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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Noel J. Bergman" <no...@devtech.com>
> If I quote the Avalon developers telling you that you're wrong, does that
> count? ;-) You should be able to find the discussion in the Avalon
> Developers mailing list archive.
Not likely. I have been using scheduler for 1+ year. This mail goes through
to you with the help of a scheduler
I'll make a patch, reading code is always more interesting than quoting.
>
> Cheap bet, by the way. I don't drink beer. :-)
Good habit. :-)
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> - You believe scheduler code cannot be used with handlers.
> - I think scheduler is designed with handlers in mind. I'll post the fixed
> code for pop3.
If I quote the Avalon developers telling you that you're wrong, does that
count? ;-) You should be able to find the discussion in the Avalon
Developers mailing list archive.
Cheap bet, by the way. I don't drink beer. :-)
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
The problem seems to be this
- You believe scheduler code cannot be used with handlers.
- I think scheduler is designed with handlers in mind. I'll post the fixed
code for pop3.
I'll buy you beer if I get it wrong. :-)
ok ?
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, October 12, 2002 1:59 PM
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> > Peter, would you be able to put your proposals up for voting. I think
> > such a major change requires proposal and voting.
>
> I believe that he did. And I don't think that this represents that major
a
> change.
>
> > The patch sent did not have any working protocol.
>
> The entire patch set would have to be integrated. I suppose that Peter
> could post the files and everyone would have to manually integrate them
into
> the source tree. Or they could be committed, people could check them out
as
> normal, and tested.
>
> Or do you just want to see it visually, and couldn't run patch against his
> diffs?
>
> > We seem to be talking about exchanging scheduler implementation
> > with watchdog implementation.
>
> Yes.
>
> > It is felt that scheduler is not very performant.
>
> It is demonstrable, and was discussed extensively both on this mailing
list
> and on the Avalon mailing list. The point is that James is using the
> Scheduler in a way contrary to the design point (purpose) for the
scheduler.
> In contrast, FetchPOP uses the Scheduler for precisely the designed
purpose.
> It isn't a matter of "James" using it correctly. The problem is that it
is
> not designed to serve the purpose that James needs.
>
> > Watchdog usage could be clearer in a complete protocal
>
> Looks to be there from what I can see. Please re-read the code. And
there
> is a thread pool associated with the watchdogs.
>
> > If (b) is true then the this will severly constrain James. Each
> > thread is heavy and we should attempt to limit the number of
> > threads.
>
> Try performance testing James and seeing how many minutes it takes to
crash
> it (< 4). The changes made by Peter and Andrei directly relate to these
> problems.
>
> > I belive the right solution is to have a scheduler per server or
> > a single scheduler for James and have unique identifier per
> > handler.
>
> Please indicate how you write a single watchdog that handles timeouts of
> arbitrary granularity for arbitrary threads. I don't think that you've
> thought this out carefully. One problem is that the watchdog has to
wakeup
> periodically to basically poll a list of entries, and can't do better than
> the granularity of its sleep cycle.
>
> > [Currently] handlers are transient objects. I don't think that is
> > the right usage. Avalon developers on this list or in Avalon list
> > may be able to confirm. If we have one scheduler for n handlers,
> > James would suddenly be a lot better.
>
> As far as I can see from Avalon's documentation, that is exactly how
> handlers are used. There could be an object pool for handlers, but that
is
> all you'd save. There is already a thread pool, and the new code provides
> for one per service.
>
> > Would prefer a proposal, some performance figures and resolution based
on
> that.
>
> Please go back a few months in the archives and find Andrei's measurements
> showing how James will fail in MINUTES at load, and how the changes
proposed
> corrected that problem. And I don't believe that justification for
> architectural improvement is predicated solely upon performance
> improvements.
>
> > server object(s) read handler configuration and pass a
> > handler specific and strongly typed datastructure to
> > each handler ?
>
> That is precisely what the new code does, EXCEPT that it sets each
property
> separately as a bean property, which is more in accord with Java
programming
> style.
>
> --- Noel
>
>
> --
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Peter, would you be able to put your proposals up for voting. I think
> such a major change requires proposal and voting.
I believe that he did. And I don't think that this represents that major a
change.
> The patch sent did not have any working protocol.
The entire patch set would have to be integrated. I suppose that Peter
could post the files and everyone would have to manually integrate them into
the source tree. Or they could be committed, people could check them out as
normal, and tested.
Or do you just want to see it visually, and couldn't run patch against his
diffs?
> We seem to be talking about exchanging scheduler implementation
> with watchdog implementation.
Yes.
> It is felt that scheduler is not very performant.
It is demonstrable, and was discussed extensively both on this mailing list
and on the Avalon mailing list. The point is that James is using the
Scheduler in a way contrary to the design point (purpose) for the scheduler.
In contrast, FetchPOP uses the Scheduler for precisely the designed purpose.
It isn't a matter of "James" using it correctly. The problem is that it is
not designed to serve the purpose that James needs.
> Watchdog usage could be clearer in a complete protocal
Looks to be there from what I can see. Please re-read the code. And there
is a thread pool associated with the watchdogs.
> If (b) is true then the this will severly constrain James. Each
> thread is heavy and we should attempt to limit the number of
> threads.
Try performance testing James and seeing how many minutes it takes to crash
it (< 4). The changes made by Peter and Andrei directly relate to these
problems.
> I belive the right solution is to have a scheduler per server or
> a single scheduler for James and have unique identifier per
> handler.
Please indicate how you write a single watchdog that handles timeouts of
arbitrary granularity for arbitrary threads. I don't think that you've
thought this out carefully. One problem is that the watchdog has to wakeup
periodically to basically poll a list of entries, and can't do better than
the granularity of its sleep cycle.
> [Currently] handlers are transient objects. I don't think that is
> the right usage. Avalon developers on this list or in Avalon list
> may be able to confirm. If we have one scheduler for n handlers,
> James would suddenly be a lot better.
As far as I can see from Avalon's documentation, that is exactly how
handlers are used. There could be an object pool for handlers, but that is
all you'd save. There is already a thread pool, and the new code provides
for one per service.
> Would prefer a proposal, some performance figures and resolution based on
that.
Please go back a few months in the archives and find Andrei's measurements
showing how James will fail in MINUTES at load, and how the changes proposed
corrected that problem. And I don't believe that justification for
architectural improvement is predicated solely upon performance
improvements.
> server object(s) read handler configuration and pass a
> handler specific and strongly typed datastructure to
> each handler ?
That is precisely what the new code does, EXCEPT that it sets each property
separately as a bean property, which is more in accord with Java programming
style.
--- 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
Posted by Danny Angus <da...@apache.org>.
> > Using 100 delivery threads, each delivering 100 1k mails
> > to James with new connections every time Java bugs out at
> > about mail 1200, out of memory, ps shows a gazillion James
> > threads. Re-using a single connection for each thread lets
> > 10,000 11k mails be delivered in 690 seconds on my hardware,
> > however James does freak out at this too, it stops accepting
> > connections and I don't yet know why.
>
> FWIW, I seem to recall that there is an error where you if increase the
> threads in one place, but not in another, there isn't a good configuration
> check; it just dies. So if you tried 100 receiving threads, that might be
> the problem.
no i didn't
> Assuming that you just had your regular receiving threads, then in your
> first case you had 100 threads competing to attach to each server thread,
> each one delivering a single e-mail and disconnecting. So you'd have
> created 1200 or so connections (and handlers and other objects,
> plus around
> 6000 scheduler entries). In the second case, you have 100
> delivery threads,
> but each one keeps its connection live until it is finished sending 100
> e-mails.
yes I know, that was the point..
--
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Using 100 delivery threads, each delivering 100 1k mails
> to James with new connections every time Java bugs out at
> about mail 1200, out of memory, ps shows a gazillion James
> threads. Re-using a single connection for each thread lets
> 10,000 11k mails be delivered in 690 seconds on my hardware,
> however James does freak out at this too, it stops accepting
> connections and I don't yet know why.
FWIW, I seem to recall that there is an error where you if increase the
threads in one place, but not in another, there isn't a good configuration
check; it just dies. So if you tried 100 receiving threads, that might be
the problem.
Assuming that you just had your regular receiving threads, then in your
first case you had 100 threads competing to attach to each server thread,
each one delivering a single e-mail and disconnecting. So you'd have
created 1200 or so connections (and handlers and other objects, plus around
6000 scheduler entries). In the second case, you have 100 delivery threads,
but each one keeps its connection live until it is finished sending 100
e-mails.
All of the current handlers have basically the same loop:
final PeriodicTimeTrigger trigger = new PeriodicTimeTrigger(
timeout, -1 );
scheduler.addTrigger( triggerId, trigger, this );
while (parseCommand(reader.readLine())) {
scheduler.resetTrigger(triggerId);
}
scheduler.removeTrigger(triggerId);
Just so you know, unless you specify a connection timeout for the handler,
the default is 30 minutes (1800000 ms). The defaults in james-config are:
RemoteManager: 1 minute ( 60000 ms)
POP3: 2 minutes (120000 ms)
SMTP: 6 minutes (360000 ms)
NNTP: 2 minutes (120000 ms)
If I am counting properly, SMTP generates 5 scheduler entries per e-mail
(initial, HELO, MAIL FROM, RCPT TO, DATA), plus additional entries per
20,000 bytes of content. 10K e-mails would have put 60K scheduler entries
into the queue, and it wouldn't even start to remove them until after the
first 36K entries. In contrast, there would be exactly one watchdog object.
Plus there are other objects that might lend themselves to object pooling,
if we find that to be an issue.
--- 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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Using 100 delivery threads, each delivering 100 1k mails
> to James with new connections every time Java bugs out at
> about mail 1200, out of memory, ps shows a gazillion James
> threads. Re-using a single connection for each thread lets
> 10,000 11k mails be delivered in 690 seconds on my hardware,
> however James does freak out at this too, it stops accepting
> connections and I don't yet know why.
> I can commit my tests, but they're very rough, I wanted to
> see the results, not build something nice.
Please do! We can run them against the new code for comparison and critical
testing. Regardless, this type of testing can help identify and correct
problems under load in all areas of James.
--- 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
Posted by Danny Angus <da...@apache.org>.
> a) We seem to be talking about exchanging scheduler implementation
> with watchdog implementation. It is felt that scheduler is not very
> performant. It would be good to collect some data on it. I think
> scheduler does not perform well, but not because the scheduler is
> broken but because James is not using it correctly.
> b) Watchdog usage could be clearer in a complete protocal
> implementation(1st general comment) but from what I can tell, there
> will be one thread associated with per watchdog.
> c) If (b) is true then the this will severly constrain James. Each
> thread is heavy and we should attempt to limit the number of
> threads.
> d) I belive the right solution is to have a scheduler per server or
> a single scheduler for James and have unique identifier per
> handler. Currently there is one scheduler per handler and handlers
> are transient objects. I don't think that is the right
> usage. Avalon developers on this list or in Avalon list may be able
> to confirm. If we have one scheduler for n handlers, James would
> suddenly be a lot better.
Using 100 delivery threads, each delivering 100 1k mails to James with new connections every time Java bugs out at about mail 1200, out of memory, ps shows a gazillion James threads.
Re-using a single connection for each thread lets 10,000 11k mails be delivered in 690 seconds on my hardware, however James does freak out at this too, it stops accepting connections and I don't yet know why.
I can commit my tests, but they're very rough, I wanted to see the results, not build something nice.
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Noel J. Bergman" <no...@devtech.com>
> I believe that there are two separate issues. One issue relates to the
> watchdog, the other to the service refactoring.
I agree, these seem to be the 2 main issues.
Peter, would you be able to put your proposals up for voting. I think
such a major change requires proposal and voting.
I am hoping a proposal can be done, but there has been some
discussion/work on this already. I will attempt to briefly put in my
main concerns without waiting for a proposal.
General Comments:
-----------------
a) The patch sent did not have any working protocol. Peter, can you
post a complete working protocol, for example POP3. This would help
see the complete working proposal.
b) can you post before and after performance statistics. I have
added pop3 protocol test suite. In testing package, runtest.[sh|bat]
reads testconf.xml, exercises protocol and generates performance
stats in CSV format. If you need any help, let me know.
Watchdog Comments
-----------------
a) We seem to be talking about exchanging scheduler implementation
with watchdog implementation. It is felt that scheduler is not very
performant. It would be good to collect some data on it. I think
scheduler does not perform well, but not because the scheduler is
broken but because James is not using it correctly.
b) Watchdog usage could be clearer in a complete protocal
implementation(1st general comment) but from what I can tell, there
will be one thread associated with per watchdog.
c) If (b) is true then the this will severly constrain James. Each
thread is heavy and we should attempt to limit the number of
threads.
d) I belive the right solution is to have a scheduler per server or
a single scheduler for James and have unique identifier per
handler. Currently there is one scheduler per handler and handlers
are transient objects. I don't think that is the right
usage. Avalon developers on this list or in Avalon list may be able
to confirm. If we have one scheduler for n handlers, James would
suddenly be a lot better.
Service vs. handler
-------------------
a) I really don't like the high coupling this may involve and don't
see the advantage in this.
b) Would prefer if this is resolved based on real gain(vs. I know
better) i.e. performance gain and if current architecture can
address a problem that may show up. Would prefer a proposal, some
performance figures and resolution based on that.
c) The main gain seems to that configuration is read a number of
times in the current code. Handler is a transient object and it is
configured each time before use. This seems to be a
precalculation/caching gain related to configuration. If
configuration object is slow, is there a way to make it faster ? If
not, can server object(s) read handler configuration and pass a
handler specific and strongly typed datastructure to each handler ?
comments...
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
I believe that there are two separate issues. One issue relates to the
watchdog, the other to the service refactoring.
With respect to the listener->dispatcher->worker question, the new code has
this ConnectionManager method:
public void connect( String name,
ServerSocket socket,
ConnectionHandlerFactory handlerFactory,
ThreadPool threadPool )
which is called from a Service object as:
connectionManager.connect(connectionName, serverSocket, this,
threadPool);
The ConnectionManager sets up a listener that waits for a connection, calls
the factory to get a worker, and then dispatches the worker for that
connection on a new thread. It is up to the factory to implement a pool of
workers or an efficient construction mechanism. The Connection Manager
supports a shared pool of worker threads, or per service pools.
Handler classes change from
public class Handler extends BaseConnectionHandler
implements ConnectionHandler, Composable,
Configurable, Target
to:
public class Handler extends AbstractLogEnabled
implements ConnectionHandler, Composable {
Configurable is replaced by service specific properties that can be set by
the handler Factory. Target is replaced by the new watchdog support.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Friday, October 11, 2002 3:20
To: James Developers List
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service
code
not quite sure if I get this, cant see how related it is to the scheduler
question, perhaps someone will enlighten me..
but if the discussion is about should we have listener->despatcher->worker
architecture with a pool of workers, then yes from me, if it is should we
instatiate new workers with "pre-built" configurations, then I guess thats
better than instantiating new workers from scratch.
I cant see any alternative to listener->despatcher->worker , hence my
confusion about the question..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 10 October 2002 22:01
> To: James Developers List
> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> Nathan,
>
> Seems to me that A (not THE) model might look something like:
>
> Server
> Interacts with underlying server platform.
>
> Parses service configuration information,
> and prepares configuration necessary for
> handlers.
>
> Responsible for providing a handler to
> handle each incoming connection. This
> is a factory function, regardless of
> whether the objects are pooled or
> constructed per use. The latter is an
> implementation issue, not an interface
> issue, although if pooling is used, at
> some point you need to provide a means
> for returning objects to the pool.
>
> Logs information related to service startup.
>
> ConnectionManager
> Listens for connections.
>
> When a new connection arrives, it
> interacts with a server to associate
> a handler, connection and thread.
>
> Connection
> Data transport
>
> Handler
> Given a connection (transport), it
> implements the semantics of a given
> protocol.
>
> Protocol (semantic) logging.
>
> Needs configuration information, but
> information that isn't per-connnection
> shouldn't be re-processed each time.
>
> Config
> This is service specific, but is it
> even an object? Where does the
> notion of "config" exist? Some of
> it is part of the contract between
> Server and ConnectionManager, e.g.,
> number of simultaneous connections.
> Some of it is part of the contract
> between the Handler and the Handler
> Factory. That could be implemented
> with a service specific object, or
> implemented with bean properties.
>
> Watchdog
> Lightweight timeout.
>
> This is just off-the-cuff. Reaction?
>
> --- Noel
>
> -----Original Message-----
> From: Nathan Carter [mailto:nathancarter@gmx.net]
> Sent: Thursday, October 10, 2002 13:50
> To: James Developers List
> Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> Peter et al,
>
> 1) This thread is quite interesting because I've asked many of these
> same questions in beginning to look at the IMAP stuff, which in many
> cases (at least the listener and handler code) seems to be based on old
> versions of the POP equivalents (i.e., they are missing august and
> september changes by danny and peter to the POP code).
>
> 2) In your initial post, you mention doing some "basic" and "load"
> testing to further quantify the memory/robustness/scalability issues and
> show how your patch solves them. What about (and I'd be happy to donate
> time for this):
>
> a)using a profiling tool to see how much time is actually being
> wasted by configuring each Handler instead of more tightly coupling them
> to the server listener.
>
> b)Do you have before/after metrics for your load tests? A 2X
> improvement will be a strong argument in itself. JMeter doesn't seem to
> support email server load testing - is there anything better than this
> (e.g. PushToTest,
> http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
>
> Again, I'd be more than happy to help in testing because this
> significantly affects what I'm doing in IMAP, and I'm going to have to
> perform this kind of testing on IMAP due to its complexity and higher
> overhead.
>
> Nathan Carter
>
>
> Peter M. Goldstein wrote:
> > Harmeet et al,
> >
> >
> >>Because the scheduler is the wrong abstraction. This is not a
> >
> > scheduler
> >
> >>problem - it's a timeout. A timeout is far simpler than a scheduler.
> >>And that's the core issue.
> >>
> >>
> >>[Harmeet]
> >>One time timer task rather than repeated timer tasks is the same thing
> >
> > as
> >
> >>Watchdog timeout. It is property of implementation.
> >>
> >
> >
> > See Noel's comments on this.
> >
> > I also want to add that this situation is directly analogous to the
> > AuthService issue. The interface itself defines a contract. In the
> > case of the Scheduler, that contract requires support for multi-threaded
> > lookup of targets on each reset. This requires lock contention
> > (assuming the implementation properly implements the contract) on each
> > reset. Lock contention which is both unnecessary, since no handler is
> > interested in the target of any other timeout and potentially expensive
> > (multi-way lock contentions cost ~50x uncontested locks/volatiles in
> > modern JVMs). The interface contract puts restrictions on the
> > implementation.
> >
> > I'm not going to respond to the rest of the specific scheduler comments,
> > because they all labor under the same confusion of interface contract
> > and implementation. Noel nailed the crucial point.
> >
> >
> >>[Harmeet]
> >>A Config object can take care of this. Handlers don't need to
> >>expose themselves to lifecycle. What you are describing is
> >
> > configuration
> >
> >>per
> >>handler and as you pointed out that is not needed. You are also saying
> >>configuration is spread out, that can be centralized too in a config
> >>object.
> >>
> >
> >
> > This is not correct.
> >
> > There are a couple of real problems with this proposal, some of them
> > highlighted in Noel's reply, some not.
> >
> > Let's start with the situation. We have a block definition in Phoenix
> > that represents a service. This class representing this block
> > (NNTPServer, SMTPServer, etc.) is instantiated by Phoenix (or any other
> > Avalon container) and is passed a read-only Configuration object (see
> > the comments for the Configuration interface). What happens now?
> >
> > In the current code base the following behavior occurs. Some parameters
> > (port, isSSL, enabled) are read out of the configuration, validated, and
> > set to defaults if they are not present. The parameters that are read
> > and validated are logged, the rest are not. Note that even this
> > functionality requires customized Server classes for each service.
> >
> > A child of the Configuration is then passed to the superclass
> > AbstractService. There is no clear distinction between the elements
> > that are in the top level Configuration object and its child class.
> > When the first connection (and every subsequent connection) is made, the
> > remainder of the Configuration parameters are read and validated. This
> > expense is incurred on each connection. Note that the server may fail
> > because of bad configuration upon first connection, which may be hours
> > or even days after the server was started.
> >
> > Changes to the handler which add additional component dependencies now
> > require alteration to the supposedly independent server configuration,
> > both in the .xinfo and in the assembly.xml. This is totally non-obvious
> > from the "decoupled" listener/handler model.
> >
> > Now consider the situation with the changed code. The server starts and
> > all service configuration parameters are read, validated, and set to
> > defaults if they are not present. Any fatal misconfiguration will be
> > detected here and cause server failure. All service configuration
> > information is logged, so an administrator can simply look at the
> > startup log and see how the service was configured. There is no extra
> > per-connection logging to that prints a config parameter that doesn't
> > change over the life of the server. It's stated just once in the log.
> >
> > Since the handler is viewed as tightly coupled to the listener, and
> > dependency checking is understood to be a function of the listener
> > block, it is obvious that changes to the handler that introduce new
> > dependencies will require modification of the listener configuration
> > files.
> >
> > Personally I much prefer the second scenario. It's cleaner from both an
> > administrator and a developer point of view. See below for reasons why
> > the potential third scenario - the suggestion to "cache" configuration
> > information - is badly flawed.
> >
> >
> >>[Harmeet]
> >>Listener-dispactch(handler) is the pattern followed in current code.
> >
> > It is
> >
> >>more flexible than server class hierarchy. The missing piece is
> >
> > confusing
> >
> >>and repeated configuration of the handler not a problem with the
> >
> > pattern
> >
> >>iteself. Most other servers try to separate the listeners from
> >
> > dispatch
> >
> >>workers/handlers.
> >
> >
> > The current code is a listener-dispatch pattern. It is a
> > listener-dispatch pattern, and would remain so after the changes I
> > propose.
> >
> > I don't think you quite understand what a listener-dispatch pattern
> > implies. There is absolutely no requirement in that pattern (and
> > certainly it doesn't hold true in generic implementations) that the
> > listener be generic. In general, the listener is specific to the
> > particular service being implemented. Usually there is a common
> > interface that describes the listener-handler (in this case
> > ConnectionHandlerFactory / ConnectionHandler) but there is certainly no
> > requirement (nor is it desirable) that either part of the pattern be
> > generic. This pattern is all about a division of responsibility, not
> > about the ability to swap in and out different partners. The division
> > of responsibility is clarified in my proposal, as all the configuration
> > is moved to the listener and the handler can focus on its purpose -
> > describing the logic for a particular transaction type (NNTP, SMTP,
> > etc.).
> >
> > As I stated before, neither side is generic in the current code base.
> > The server or listener side inherits from a reasonably heavyweight
> > AbstractService class - about the same weight as the
> > AbstractJamesService class, but with fewer features.
> >
> >
> >>[Harmeet]
> >>Params/Config need not require revalidation and if they do there will
> >
> > be
> >
> >>the
> >>overhead that you are avoiding by server class hierarchy.
> >>
> >
> >
> > Again, this is not correct. You need to validate your config
> > parameters. You need to do it somewhere. If you load and parse the
> > parameters in the handler, you do it in the handler. If you load and
> > parse the parameters in the server class, you do it in the server class.
> >
> >
> >>[Harmeet]
> >>Cache the config. Precalculation for handlers, isn't that the only
> >
> > gain in
> >
> >>having a server class hierarchy. Maybe that idea can be abstracted and
> >>used
> >>with current model.
> >>
> >
> >
> > No, this isn't the only gain in having a server class hierarchy. See
> > this email and the previous one for a discussion of gains. They
> > include, but aren't limited to, better error handling, clearer logging,
> > simpler configuration, and simpler code.
> >
> > Moreover this caching idea you suggest is even worse than the current
> > code. Consider the situation. Since you object to distinguishing
> > between the server objects, presumably you're going to have the "first"
> > handler for the service initialize the configuration and all others will
> > access it. That's because someone has to initialize the config. If
> > you've got a generic server with no ability to interpret the content of
> > the configuration, it has to be the handler. This is a classic server
> > design anti-pattern. Because what you've done is introduced a mutable
> > (because the handler has to do the initial parsing and setting to
> > defaults), shared configuration object. Access to this object will
> > require a lock on every call, because the handler has to check if the
> > config is initialized and, if not, initialize it. This becomes a
> > heavily contested lock. Very expensive, destroys performance.
> >
> > Now, let's imagine that we admit that the natural place for the
> > configuration parsing is in the server class. But we still want to
> > stick with this notion of "generic" arguments passed to the handler.
> > What's wrong with this? The basic problem with it is that you don't
> > gain anything over the approach I suggest and you lose type safety. The
> > server class still needs to know what type of service it represents in
> > order to parse and validate the configuration parameters. In addition,
> > if we restrict ourselves to the Avalon configuration rather than some
> > Properties object, we lose even more. Configuration parameters that
> > aren't easily represented as Strings become difficult to pass to the
> > handler. We have to put some String key in place, and give the handler
> > the Configuration. It pulls out the String, and looks up the non-String
> > thing. Ugh.
> >
> > This is simple?
> >
> >
> >>>>This leads to tighter coupling between the
> >>>>Handlers and the corresponding server classes, but that's simply
> >>>>recognition of a pre-existing reality. These classes are
> >>>
> > extremely
> >
> >>>>tightly coupled.
> >>>
> >>>Server is a listener. Handler contains protocol specific stuff. Why
> >>
> >>would
> >>
> >>>there be a (tight) coupling ?
> >>>It is a listen-dispatch mechanism. Shouldn't it be as loosely
> >>
> > coupled
> >
> >>as
> >>
> >>>possible ?
> >>
> >>This is a somewhat nave view of a service architecture. Servers
> >
> > aren't
> >
> >>generic. If they were, we'd need only one server class period. But
> >>servers are different from one another, so we need separate server
> >>classes. You can see how the servers differ by examining the diffs
> >
> > for
> >
> >>the assorted server classes that were submitted with this patch.
> >>
> >>
> >>
> >>[Harmeet]
> >>No I am saying listeners are generic. Handlers/Workers are specific. A
> >
> > mix
> >
> >>of two makes service and servers.
> >>
> >
> >
> > Listeners are not generic. Not even close. They aren't now, they can't
> > be for the reasons I outlined in my last email, and there's been no
> > compelling reason presented for them to be generic.
> >
> >
> >
> >>[Harmeet]
> >>But a socket listener associated with SMTP handler makes an SMTP
> >
> > Service.
> >
> >>That is the current state.
> >>An incremental and better system would be Socket Listener with Config
> >>Object
> >>and Handler makes a Service.
> >>
> >>A Bad State would be a server class hierarchy that couples Listener,
> >>Config
> >>and Handler.
> >>
> >>-------------------------------
> >
> >
> > I couldn't disagree more with this statement.
> >
> > It's a typical expression of extensibility at any cost. The trick to
> > writing extensible code is to pick your extension points. The
> > Configuration object is generic, so the class itself is not coupled to
> > the server or the handler. Of course the specific values stored in that
> > Configuration object ARE tightly coupled to the SMTP server. They have
> > to be, as they're the values that configure how the SMTP server runs.
> >
> > The Handler and Listener should be tightly coupled. There is no reason
> > why an NNTPServer should work with a SMTPHandler. That wouldn't make
> > any sense. Even in the proposed solution they wouldn't work together -
> > they'd just fail miserably on each connection because the SMTPHandler
> > wouldn't have the parameters it needed. The handler and listener are
> > tightly coupled precisely because they are implementations of a service
> > - a service that has configuration, server specific details, and a
> > protocol.
> >
> >
> >>[Harmeet]
> >>Port, queus size etc are the only listener concerns.
> >>
> >
> >
> > Port, queue, etc.? What's hidden in the etc.?
> >
> > Trivializing the listener concerns like this is just hiding the issue.
> > The listener is responsible for socket and connection management, so it
> > needs to be able to specify the ConnectionManager and socket type. As
> > the ConnectionManager needs a thread group to invoke a server
> > connection, it needs a thread group. For certain services there will be
> > configuration restriction logic related to the socket types (imagine
> > publishing an HTTPS service with TCP/IP sockets). This all belongs in
> > the listener. The handler can't deal with any of it, because by the
> > time the handler is invoked this needs to have been already dealt with.
> > So the listener has to have a very non-trivial configuration.
> >
> >
> >>-------------------------------
> >>
> >>Second, there are resources provided by the server that depend on the
> >>configuration. Yes, it's possible to re-read the configuration on a
> >
> > per
> >
> >>handler invocation basis. But that's a bad idea for the reasons
> >>described above.
> >>
> >>[Harmeet]
> >>That is why I am suggesting params or configuration object, cached for
> >
> > a
> >
> >>class of handlers.
> >
> >
> > See above why a param (lose type safety) or configuration object (can
> > only hold Stringifiable objects) is a bad idea.
> >
> >
> >>[Harmeet]
> >>Are you saying Avalon is too complicated. Avalon complexity or user
> >>friendliness is not a reason to change a fairly standard
> >
> > listener-dispatch
> >
> >>model. If there are problems with Phoenix, would it be better to not
> >
> > use
> >
> >>it
> >>? That is a different topic. Complexity in one part should ideally not
> >
> > be
> >
> >>reason a rearchitect another part.
> >
> >
> > This is just silly. What's being critiqued here as over-complex is a
> > vast simplification of one of the most difficult aspects of server
> > design.
> >
> > Let me be clear - this is one of the best parts of Phoenix. It's
> > incredibly well designed and well thought out and it takes one of the
> > most annoying parts of server design (getting all your dependency
> > checking right) and makes it trivial.
> >
> > Avalon in general, and Phoenix as a specific container is based around
> > the idea of component oriented programming. Each of the services we
> > define - the listener classes - comprises a component. It's a component
> > because it can be uniquely defined by a name, provides one or more
> > interfaces, exists for the life of the container, and can be looked up
> > by the other components running in the container. These characteristics
> > are all necessary to establish a dependency chain and ensure that each
> > component can both declare what it needs to function and be evaluated as
> > part of a dependency chain.
> >
> > The handler instances cannot be components. There are some arbitrary
> > number of them, they don't have unique names, they can't be accessed by
> > other components, and they have very limited lifetimes. Thus they don't
> > meet the minimum requirements.
> >
> > Avalon is great, and Phoenix is a great container. Chucking it is
> > really out of the question. This is not a fault in the Avalon
> > framework, but rather a fault in your proposal. Your proposal violates
> > basic principles of component oriented design.
> >
> >
> >
> >>-------------------------------
> >>
> >>[Harmeet]
> >>You can have different services. POP3 and POP3 Secure. Doesn't that
> >
> > achive
> >
> >>what you are describing. If you POP3 is a service, POP3 (plain) and
> >
> > POP3
> >
> >>Secure are 2 instances of it. It depends on what you mean by a
> >
> > service.
> >
> >>Effectiely if you want different listereners/threadgroups for a
> >
> > protocol,
> >
> >>that exists.
> >
> >
> > No, it doesn't. You are misunderstanding the problem. The ability to
> > configure different socket types and different thread groups is not
> > present in the current code. Period. The configuration doesn't look
> > for it. All it can do is "plain" sockets vs. "ssl". That's it. And
> > the thread pool is always the default thread pool. There is no way to
> > configure the server to use different thread pools for different
> > services.
> >
> >
> >
> >>-------------------------------
> >>
> >>As far as the ability to handle multiple socket types, that wasn'tb
> >>there. The socket type was one of two hard coded strings, and the SSL
> >>selection was Boolean. So if you wanted to have two different SSL
> >>socket types, one for use by the NNTP server and another for use by
> >
> > the
> >
> >>SMTP server (a very common configuration), then you would have to run
> >>two separate servers. Very bad.
> >>
> >>[Harmeet]
> >>It is pretty standard. Take a look at tomcat. They do the same thing.
> >>
> >
> >
> > No, it isn't. Almost nobody writes production servers that handle SSL
> > for multiple services without providing the ability to have multiple SSL
> > connection types.
> >
> > This is also a misunderstanding of the standard recommended production
> > deployment of Tomcat.
> >
> > Tomcat is a reference implementation of the Servlet/JSP specs. As such
> > it was an explicit decision to focus on the Servlet/JSP processing in
> > Tomcat. The network interface was left uber-simple on purpose. The
> > static page delivery wasn't tuned. Why? Because the developers wanted
> > to focus on the core functionality.
> >
> > And that's why the recommended deployment of Tomcat is in a reverse
> > proxy environment. Apache in front to handle complex connection
> > management and configuration (and it certainly does allow multiple SSL
> > connection types) and to handle static page delivery. And then Apache
> > proxies Servlet and JSP requests to the Tomcat server. That allows the
> > production environment to take advantage of Apache's strong connection
> > management.
> >
> > This is a recognized weakness of the Tomcat implementation. That's why
> > there is always a lot of discussion about embedding Tomcat in Avalon
> > containers, etc. on the Avalon mailing lists. Because a container that
> > implements the Avalon framework would provide all of the complex
> > connection management features that the Tomcat implementation lacks and
> > allow you to run more complex systems in non-reverse proxy environments.
> >
> > I don't see any reason to hobble ourselves with an unnecessary flaw.
> >
> >
> >>[Harmeet]
> >>Basically if n lines have been written out, observer resets the timer.
> >>rather than only after all the lines have been written out.
> >>
> >
> >
> > And this won't work. Why? Because it ignores the distinction between
> > observer and observable as well as the conditions under which we want a
> > reset. The purpose of the reset here is to prevent transaction hangs,
> > as much from server processing as from client processing. So the
> > primary trigger reset is not the amount of data written, but rather the
> > trigger that occurs every time a command is processed. A command being
> > processed indicates that the transaction is proceeding. As this
> > information is not available to the stream (it has no idea when a
> > command has completed), the stream cannot be the observable in this
> > situation. The stream data is crucial for commands that potentially
> > involve large transfers of data, so the handler can't be the observable.
> > So the pattern doesn't fit.
> >
> >
> >
> >>[Harmeet]
> >>The observer-observable is a clean and standard pattern way. It allows
> >
> > an
> >
> >>observer to monitor and decide on timeout reset.
> >>
> >
> >
> > It is a clean and standard pattern. It's just the wrong one for this
> > situation. See above.
> >
> > --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>
--
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
Posted by Danny Angus <da...@apache.org>.
not quite sure if I get this, cant see how related it is to the scheduler question, perhaps someone will enlighten me..
but if the discussion is about should we have listener->despatcher->worker architecture with a pool of workers, then yes from me, if it is should we instatiate new workers with "pre-built" configurations, then I guess thats better than instantiating new workers from scratch.
I cant see any alternative to listener->despatcher->worker , hence my confusion about the question..
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 10 October 2002 22:01
> To: James Developers List
> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> Nathan,
>
> Seems to me that A (not THE) model might look something like:
>
> Server
> Interacts with underlying server platform.
>
> Parses service configuration information,
> and prepares configuration necessary for
> handlers.
>
> Responsible for providing a handler to
> handle each incoming connection. This
> is a factory function, regardless of
> whether the objects are pooled or
> constructed per use. The latter is an
> implementation issue, not an interface
> issue, although if pooling is used, at
> some point you need to provide a means
> for returning objects to the pool.
>
> Logs information related to service startup.
>
> ConnectionManager
> Listens for connections.
>
> When a new connection arrives, it
> interacts with a server to associate
> a handler, connection and thread.
>
> Connection
> Data transport
>
> Handler
> Given a connection (transport), it
> implements the semantics of a given
> protocol.
>
> Protocol (semantic) logging.
>
> Needs configuration information, but
> information that isn't per-connnection
> shouldn't be re-processed each time.
>
> Config
> This is service specific, but is it
> even an object? Where does the
> notion of "config" exist? Some of
> it is part of the contract between
> Server and ConnectionManager, e.g.,
> number of simultaneous connections.
> Some of it is part of the contract
> between the Handler and the Handler
> Factory. That could be implemented
> with a service specific object, or
> implemented with bean properties.
>
> Watchdog
> Lightweight timeout.
>
> This is just off-the-cuff. Reaction?
>
> --- Noel
>
> -----Original Message-----
> From: Nathan Carter [mailto:nathancarter@gmx.net]
> Sent: Thursday, October 10, 2002 13:50
> To: James Developers List
> Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> Peter et al,
>
> 1) This thread is quite interesting because I've asked many of these
> same questions in beginning to look at the IMAP stuff, which in many
> cases (at least the listener and handler code) seems to be based on old
> versions of the POP equivalents (i.e., they are missing august and
> september changes by danny and peter to the POP code).
>
> 2) In your initial post, you mention doing some "basic" and "load"
> testing to further quantify the memory/robustness/scalability issues and
> show how your patch solves them. What about (and I'd be happy to donate
> time for this):
>
> a)using a profiling tool to see how much time is actually being
> wasted by configuring each Handler instead of more tightly coupling them
> to the server listener.
>
> b)Do you have before/after metrics for your load tests? A 2X
> improvement will be a strong argument in itself. JMeter doesn't seem to
> support email server load testing - is there anything better than this
> (e.g. PushToTest,
> http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
>
> Again, I'd be more than happy to help in testing because this
> significantly affects what I'm doing in IMAP, and I'm going to have to
> perform this kind of testing on IMAP due to its complexity and higher
> overhead.
>
> Nathan Carter
>
>
> Peter M. Goldstein wrote:
> > Harmeet et al,
> >
> >
> >>Because the scheduler is the wrong abstraction. This is not a
> >
> > scheduler
> >
> >>problem - it's a timeout. A timeout is far simpler than a scheduler.
> >>And that's the core issue.
> >>
> >>
> >>[Harmeet]
> >>One time timer task rather than repeated timer tasks is the same thing
> >
> > as
> >
> >>Watchdog timeout. It is property of implementation.
> >>
> >
> >
> > See Noel's comments on this.
> >
> > I also want to add that this situation is directly analogous to the
> > AuthService issue. The interface itself defines a contract. In the
> > case of the Scheduler, that contract requires support for multi-threaded
> > lookup of targets on each reset. This requires lock contention
> > (assuming the implementation properly implements the contract) on each
> > reset. Lock contention which is both unnecessary, since no handler is
> > interested in the target of any other timeout and potentially expensive
> > (multi-way lock contentions cost ~50x uncontested locks/volatiles in
> > modern JVMs). The interface contract puts restrictions on the
> > implementation.
> >
> > I'm not going to respond to the rest of the specific scheduler comments,
> > because they all labor under the same confusion of interface contract
> > and implementation. Noel nailed the crucial point.
> >
> >
> >>[Harmeet]
> >>A Config object can take care of this. Handlers don't need to
> >>expose themselves to lifecycle. What you are describing is
> >
> > configuration
> >
> >>per
> >>handler and as you pointed out that is not needed. You are also saying
> >>configuration is spread out, that can be centralized too in a config
> >>object.
> >>
> >
> >
> > This is not correct.
> >
> > There are a couple of real problems with this proposal, some of them
> > highlighted in Noel's reply, some not.
> >
> > Let's start with the situation. We have a block definition in Phoenix
> > that represents a service. This class representing this block
> > (NNTPServer, SMTPServer, etc.) is instantiated by Phoenix (or any other
> > Avalon container) and is passed a read-only Configuration object (see
> > the comments for the Configuration interface). What happens now?
> >
> > In the current code base the following behavior occurs. Some parameters
> > (port, isSSL, enabled) are read out of the configuration, validated, and
> > set to defaults if they are not present. The parameters that are read
> > and validated are logged, the rest are not. Note that even this
> > functionality requires customized Server classes for each service.
> >
> > A child of the Configuration is then passed to the superclass
> > AbstractService. There is no clear distinction between the elements
> > that are in the top level Configuration object and its child class.
> > When the first connection (and every subsequent connection) is made, the
> > remainder of the Configuration parameters are read and validated. This
> > expense is incurred on each connection. Note that the server may fail
> > because of bad configuration upon first connection, which may be hours
> > or even days after the server was started.
> >
> > Changes to the handler which add additional component dependencies now
> > require alteration to the supposedly independent server configuration,
> > both in the .xinfo and in the assembly.xml. This is totally non-obvious
> > from the "decoupled" listener/handler model.
> >
> > Now consider the situation with the changed code. The server starts and
> > all service configuration parameters are read, validated, and set to
> > defaults if they are not present. Any fatal misconfiguration will be
> > detected here and cause server failure. All service configuration
> > information is logged, so an administrator can simply look at the
> > startup log and see how the service was configured. There is no extra
> > per-connection logging to that prints a config parameter that doesn't
> > change over the life of the server. It's stated just once in the log.
> >
> > Since the handler is viewed as tightly coupled to the listener, and
> > dependency checking is understood to be a function of the listener
> > block, it is obvious that changes to the handler that introduce new
> > dependencies will require modification of the listener configuration
> > files.
> >
> > Personally I much prefer the second scenario. It's cleaner from both an
> > administrator and a developer point of view. See below for reasons why
> > the potential third scenario - the suggestion to "cache" configuration
> > information - is badly flawed.
> >
> >
> >>[Harmeet]
> >>Listener-dispactch(handler) is the pattern followed in current code.
> >
> > It is
> >
> >>more flexible than server class hierarchy. The missing piece is
> >
> > confusing
> >
> >>and repeated configuration of the handler not a problem with the
> >
> > pattern
> >
> >>iteself. Most other servers try to separate the listeners from
> >
> > dispatch
> >
> >>workers/handlers.
> >
> >
> > The current code is a listener-dispatch pattern. It is a
> > listener-dispatch pattern, and would remain so after the changes I
> > propose.
> >
> > I don't think you quite understand what a listener-dispatch pattern
> > implies. There is absolutely no requirement in that pattern (and
> > certainly it doesn't hold true in generic implementations) that the
> > listener be generic. In general, the listener is specific to the
> > particular service being implemented. Usually there is a common
> > interface that describes the listener-handler (in this case
> > ConnectionHandlerFactory / ConnectionHandler) but there is certainly no
> > requirement (nor is it desirable) that either part of the pattern be
> > generic. This pattern is all about a division of responsibility, not
> > about the ability to swap in and out different partners. The division
> > of responsibility is clarified in my proposal, as all the configuration
> > is moved to the listener and the handler can focus on its purpose -
> > describing the logic for a particular transaction type (NNTP, SMTP,
> > etc.).
> >
> > As I stated before, neither side is generic in the current code base.
> > The server or listener side inherits from a reasonably heavyweight
> > AbstractService class - about the same weight as the
> > AbstractJamesService class, but with fewer features.
> >
> >
> >>[Harmeet]
> >>Params/Config need not require revalidation and if they do there will
> >
> > be
> >
> >>the
> >>overhead that you are avoiding by server class hierarchy.
> >>
> >
> >
> > Again, this is not correct. You need to validate your config
> > parameters. You need to do it somewhere. If you load and parse the
> > parameters in the handler, you do it in the handler. If you load and
> > parse the parameters in the server class, you do it in the server class.
> >
> >
> >>[Harmeet]
> >>Cache the config. Precalculation for handlers, isn't that the only
> >
> > gain in
> >
> >>having a server class hierarchy. Maybe that idea can be abstracted and
> >>used
> >>with current model.
> >>
> >
> >
> > No, this isn't the only gain in having a server class hierarchy. See
> > this email and the previous one for a discussion of gains. They
> > include, but aren't limited to, better error handling, clearer logging,
> > simpler configuration, and simpler code.
> >
> > Moreover this caching idea you suggest is even worse than the current
> > code. Consider the situation. Since you object to distinguishing
> > between the server objects, presumably you're going to have the "first"
> > handler for the service initialize the configuration and all others will
> > access it. That's because someone has to initialize the config. If
> > you've got a generic server with no ability to interpret the content of
> > the configuration, it has to be the handler. This is a classic server
> > design anti-pattern. Because what you've done is introduced a mutable
> > (because the handler has to do the initial parsing and setting to
> > defaults), shared configuration object. Access to this object will
> > require a lock on every call, because the handler has to check if the
> > config is initialized and, if not, initialize it. This becomes a
> > heavily contested lock. Very expensive, destroys performance.
> >
> > Now, let's imagine that we admit that the natural place for the
> > configuration parsing is in the server class. But we still want to
> > stick with this notion of "generic" arguments passed to the handler.
> > What's wrong with this? The basic problem with it is that you don't
> > gain anything over the approach I suggest and you lose type safety. The
> > server class still needs to know what type of service it represents in
> > order to parse and validate the configuration parameters. In addition,
> > if we restrict ourselves to the Avalon configuration rather than some
> > Properties object, we lose even more. Configuration parameters that
> > aren't easily represented as Strings become difficult to pass to the
> > handler. We have to put some String key in place, and give the handler
> > the Configuration. It pulls out the String, and looks up the non-String
> > thing. Ugh.
> >
> > This is simple?
> >
> >
> >>>>This leads to tighter coupling between the
> >>>>Handlers and the corresponding server classes, but that's simply
> >>>>recognition of a pre-existing reality. These classes are
> >>>
> > extremely
> >
> >>>>tightly coupled.
> >>>
> >>>Server is a listener. Handler contains protocol specific stuff. Why
> >>
> >>would
> >>
> >>>there be a (tight) coupling ?
> >>>It is a listen-dispatch mechanism. Shouldn't it be as loosely
> >>
> > coupled
> >
> >>as
> >>
> >>>possible ?
> >>
> >>This is a somewhat nave view of a service architecture. Servers
> >
> > aren't
> >
> >>generic. If they were, we'd need only one server class period. But
> >>servers are different from one another, so we need separate server
> >>classes. You can see how the servers differ by examining the diffs
> >
> > for
> >
> >>the assorted server classes that were submitted with this patch.
> >>
> >>
> >>
> >>[Harmeet]
> >>No I am saying listeners are generic. Handlers/Workers are specific. A
> >
> > mix
> >
> >>of two makes service and servers.
> >>
> >
> >
> > Listeners are not generic. Not even close. They aren't now, they can't
> > be for the reasons I outlined in my last email, and there's been no
> > compelling reason presented for them to be generic.
> >
> >
> >
> >>[Harmeet]
> >>But a socket listener associated with SMTP handler makes an SMTP
> >
> > Service.
> >
> >>That is the current state.
> >>An incremental and better system would be Socket Listener with Config
> >>Object
> >>and Handler makes a Service.
> >>
> >>A Bad State would be a server class hierarchy that couples Listener,
> >>Config
> >>and Handler.
> >>
> >>-------------------------------
> >
> >
> > I couldn't disagree more with this statement.
> >
> > It's a typical expression of extensibility at any cost. The trick to
> > writing extensible code is to pick your extension points. The
> > Configuration object is generic, so the class itself is not coupled to
> > the server or the handler. Of course the specific values stored in that
> > Configuration object ARE tightly coupled to the SMTP server. They have
> > to be, as they're the values that configure how the SMTP server runs.
> >
> > The Handler and Listener should be tightly coupled. There is no reason
> > why an NNTPServer should work with a SMTPHandler. That wouldn't make
> > any sense. Even in the proposed solution they wouldn't work together -
> > they'd just fail miserably on each connection because the SMTPHandler
> > wouldn't have the parameters it needed. The handler and listener are
> > tightly coupled precisely because they are implementations of a service
> > - a service that has configuration, server specific details, and a
> > protocol.
> >
> >
> >>[Harmeet]
> >>Port, queus size etc are the only listener concerns.
> >>
> >
> >
> > Port, queue, etc.? What's hidden in the etc.?
> >
> > Trivializing the listener concerns like this is just hiding the issue.
> > The listener is responsible for socket and connection management, so it
> > needs to be able to specify the ConnectionManager and socket type. As
> > the ConnectionManager needs a thread group to invoke a server
> > connection, it needs a thread group. For certain services there will be
> > configuration restriction logic related to the socket types (imagine
> > publishing an HTTPS service with TCP/IP sockets). This all belongs in
> > the listener. The handler can't deal with any of it, because by the
> > time the handler is invoked this needs to have been already dealt with.
> > So the listener has to have a very non-trivial configuration.
> >
> >
> >>-------------------------------
> >>
> >>Second, there are resources provided by the server that depend on the
> >>configuration. Yes, it's possible to re-read the configuration on a
> >
> > per
> >
> >>handler invocation basis. But that's a bad idea for the reasons
> >>described above.
> >>
> >>[Harmeet]
> >>That is why I am suggesting params or configuration object, cached for
> >
> > a
> >
> >>class of handlers.
> >
> >
> > See above why a param (lose type safety) or configuration object (can
> > only hold Stringifiable objects) is a bad idea.
> >
> >
> >>[Harmeet]
> >>Are you saying Avalon is too complicated. Avalon complexity or user
> >>friendliness is not a reason to change a fairly standard
> >
> > listener-dispatch
> >
> >>model. If there are problems with Phoenix, would it be better to not
> >
> > use
> >
> >>it
> >>? That is a different topic. Complexity in one part should ideally not
> >
> > be
> >
> >>reason a rearchitect another part.
> >
> >
> > This is just silly. What's being critiqued here as over-complex is a
> > vast simplification of one of the most difficult aspects of server
> > design.
> >
> > Let me be clear - this is one of the best parts of Phoenix. It's
> > incredibly well designed and well thought out and it takes one of the
> > most annoying parts of server design (getting all your dependency
> > checking right) and makes it trivial.
> >
> > Avalon in general, and Phoenix as a specific container is based around
> > the idea of component oriented programming. Each of the services we
> > define - the listener classes - comprises a component. It's a component
> > because it can be uniquely defined by a name, provides one or more
> > interfaces, exists for the life of the container, and can be looked up
> > by the other components running in the container. These characteristics
> > are all necessary to establish a dependency chain and ensure that each
> > component can both declare what it needs to function and be evaluated as
> > part of a dependency chain.
> >
> > The handler instances cannot be components. There are some arbitrary
> > number of them, they don't have unique names, they can't be accessed by
> > other components, and they have very limited lifetimes. Thus they don't
> > meet the minimum requirements.
> >
> > Avalon is great, and Phoenix is a great container. Chucking it is
> > really out of the question. This is not a fault in the Avalon
> > framework, but rather a fault in your proposal. Your proposal violates
> > basic principles of component oriented design.
> >
> >
> >
> >>-------------------------------
> >>
> >>[Harmeet]
> >>You can have different services. POP3 and POP3 Secure. Doesn't that
> >
> > achive
> >
> >>what you are describing. If you POP3 is a service, POP3 (plain) and
> >
> > POP3
> >
> >>Secure are 2 instances of it. It depends on what you mean by a
> >
> > service.
> >
> >>Effectiely if you want different listereners/threadgroups for a
> >
> > protocol,
> >
> >>that exists.
> >
> >
> > No, it doesn't. You are misunderstanding the problem. The ability to
> > configure different socket types and different thread groups is not
> > present in the current code. Period. The configuration doesn't look
> > for it. All it can do is "plain" sockets vs. "ssl". That's it. And
> > the thread pool is always the default thread pool. There is no way to
> > configure the server to use different thread pools for different
> > services.
> >
> >
> >
> >>-------------------------------
> >>
> >>As far as the ability to handle multiple socket types, that wasn'tb
> >>there. The socket type was one of two hard coded strings, and the SSL
> >>selection was Boolean. So if you wanted to have two different SSL
> >>socket types, one for use by the NNTP server and another for use by
> >
> > the
> >
> >>SMTP server (a very common configuration), then you would have to run
> >>two separate servers. Very bad.
> >>
> >>[Harmeet]
> >>It is pretty standard. Take a look at tomcat. They do the same thing.
> >>
> >
> >
> > No, it isn't. Almost nobody writes production servers that handle SSL
> > for multiple services without providing the ability to have multiple SSL
> > connection types.
> >
> > This is also a misunderstanding of the standard recommended production
> > deployment of Tomcat.
> >
> > Tomcat is a reference implementation of the Servlet/JSP specs. As such
> > it was an explicit decision to focus on the Servlet/JSP processing in
> > Tomcat. The network interface was left uber-simple on purpose. The
> > static page delivery wasn't tuned. Why? Because the developers wanted
> > to focus on the core functionality.
> >
> > And that's why the recommended deployment of Tomcat is in a reverse
> > proxy environment. Apache in front to handle complex connection
> > management and configuration (and it certainly does allow multiple SSL
> > connection types) and to handle static page delivery. And then Apache
> > proxies Servlet and JSP requests to the Tomcat server. That allows the
> > production environment to take advantage of Apache's strong connection
> > management.
> >
> > This is a recognized weakness of the Tomcat implementation. That's why
> > there is always a lot of discussion about embedding Tomcat in Avalon
> > containers, etc. on the Avalon mailing lists. Because a container that
> > implements the Avalon framework would provide all of the complex
> > connection management features that the Tomcat implementation lacks and
> > allow you to run more complex systems in non-reverse proxy environments.
> >
> > I don't see any reason to hobble ourselves with an unnecessary flaw.
> >
> >
> >>[Harmeet]
> >>Basically if n lines have been written out, observer resets the timer.
> >>rather than only after all the lines have been written out.
> >>
> >
> >
> > And this won't work. Why? Because it ignores the distinction between
> > observer and observable as well as the conditions under which we want a
> > reset. The purpose of the reset here is to prevent transaction hangs,
> > as much from server processing as from client processing. So the
> > primary trigger reset is not the amount of data written, but rather the
> > trigger that occurs every time a command is processed. A command being
> > processed indicates that the transaction is proceeding. As this
> > information is not available to the stream (it has no idea when a
> > command has completed), the stream cannot be the observable in this
> > situation. The stream data is crucial for commands that potentially
> > involve large transfers of data, so the handler can't be the observable.
> > So the pattern doesn't fit.
> >
> >
> >
> >>[Harmeet]
> >>The observer-observable is a clean and standard pattern way. It allows
> >
> > an
> >
> >>observer to monitor and decide on timeout reset.
> >>
> >
> >
> > It is a clean and standard pattern. It's just the wrong one for this
> > situation. See above.
> >
> > --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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nathan,
Seems to me that A (not THE) model might look something like:
Server
Interacts with underlying server platform.
Parses service configuration information,
and prepares configuration necessary for
handlers.
Responsible for providing a handler to
handle each incoming connection. This
is a factory function, regardless of
whether the objects are pooled or
constructed per use. The latter is an
implementation issue, not an interface
issue, although if pooling is used, at
some point you need to provide a means
for returning objects to the pool.
Logs information related to service startup.
ConnectionManager
Listens for connections.
When a new connection arrives, it
interacts with a server to associate
a handler, connection and thread.
Connection
Data transport
Handler
Given a connection (transport), it
implements the semantics of a given
protocol.
Protocol (semantic) logging.
Needs configuration information, but
information that isn't per-connnection
shouldn't be re-processed each time.
Config
This is service specific, but is it
even an object? Where does the
notion of "config" exist? Some of
it is part of the contract between
Server and ConnectionManager, e.g.,
number of simultaneous connections.
Some of it is part of the contract
between the Handler and the Handler
Factory. That could be implemented
with a service specific object, or
implemented with bean properties.
Watchdog
Lightweight timeout.
This is just off-the-cuff. Reaction?
--- Noel
-----Original Message-----
From: Nathan Carter [mailto:nathancarter@gmx.net]
Sent: Thursday, October 10, 2002 13:50
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
Peter et al,
1) This thread is quite interesting because I've asked many of these
same questions in beginning to look at the IMAP stuff, which in many
cases (at least the listener and handler code) seems to be based on old
versions of the POP equivalents (i.e., they are missing august and
september changes by danny and peter to the POP code).
2) In your initial post, you mention doing some "basic" and "load"
testing to further quantify the memory/robustness/scalability issues and
show how your patch solves them. What about (and I'd be happy to donate
time for this):
a)using a profiling tool to see how much time is actually being
wasted by configuring each Handler instead of more tightly coupling them
to the server listener.
b)Do you have before/after metrics for your load tests? A 2X
improvement will be a strong argument in itself. JMeter doesn't seem to
support email server load testing - is there anything better than this
(e.g. PushToTest,
http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
Again, I'd be more than happy to help in testing because this
significantly affects what I'm doing in IMAP, and I'm going to have to
perform this kind of testing on IMAP due to its complexity and higher
overhead.
Nathan Carter
Peter M. Goldstein wrote:
> Harmeet et al,
>
>
>>Because the scheduler is the wrong abstraction. This is not a
>
> scheduler
>
>>problem - it's a timeout. A timeout is far simpler than a scheduler.
>>And that's the core issue.
>>
>>
>>[Harmeet]
>>One time timer task rather than repeated timer tasks is the same thing
>
> as
>
>>Watchdog timeout. It is property of implementation.
>>
>
>
> See Noel's comments on this.
>
> I also want to add that this situation is directly analogous to the
> AuthService issue. The interface itself defines a contract. In the
> case of the Scheduler, that contract requires support for multi-threaded
> lookup of targets on each reset. This requires lock contention
> (assuming the implementation properly implements the contract) on each
> reset. Lock contention which is both unnecessary, since no handler is
> interested in the target of any other timeout and potentially expensive
> (multi-way lock contentions cost ~50x uncontested locks/volatiles in
> modern JVMs). The interface contract puts restrictions on the
> implementation.
>
> I'm not going to respond to the rest of the specific scheduler comments,
> because they all labor under the same confusion of interface contract
> and implementation. Noel nailed the crucial point.
>
>
>>[Harmeet]
>>A Config object can take care of this. Handlers don't need to
>>expose themselves to lifecycle. What you are describing is
>
> configuration
>
>>per
>>handler and as you pointed out that is not needed. You are also saying
>>configuration is spread out, that can be centralized too in a config
>>object.
>>
>
>
> This is not correct.
>
> There are a couple of real problems with this proposal, some of them
> highlighted in Noel's reply, some not.
>
> Let's start with the situation. We have a block definition in Phoenix
> that represents a service. This class representing this block
> (NNTPServer, SMTPServer, etc.) is instantiated by Phoenix (or any other
> Avalon container) and is passed a read-only Configuration object (see
> the comments for the Configuration interface). What happens now?
>
> In the current code base the following behavior occurs. Some parameters
> (port, isSSL, enabled) are read out of the configuration, validated, and
> set to defaults if they are not present. The parameters that are read
> and validated are logged, the rest are not. Note that even this
> functionality requires customized Server classes for each service.
>
> A child of the Configuration is then passed to the superclass
> AbstractService. There is no clear distinction between the elements
> that are in the top level Configuration object and its child class.
> When the first connection (and every subsequent connection) is made, the
> remainder of the Configuration parameters are read and validated. This
> expense is incurred on each connection. Note that the server may fail
> because of bad configuration upon first connection, which may be hours
> or even days after the server was started.
>
> Changes to the handler which add additional component dependencies now
> require alteration to the supposedly independent server configuration,
> both in the .xinfo and in the assembly.xml. This is totally non-obvious
> from the "decoupled" listener/handler model.
>
> Now consider the situation with the changed code. The server starts and
> all service configuration parameters are read, validated, and set to
> defaults if they are not present. Any fatal misconfiguration will be
> detected here and cause server failure. All service configuration
> information is logged, so an administrator can simply look at the
> startup log and see how the service was configured. There is no extra
> per-connection logging to that prints a config parameter that doesn't
> change over the life of the server. It's stated just once in the log.
>
> Since the handler is viewed as tightly coupled to the listener, and
> dependency checking is understood to be a function of the listener
> block, it is obvious that changes to the handler that introduce new
> dependencies will require modification of the listener configuration
> files.
>
> Personally I much prefer the second scenario. It's cleaner from both an
> administrator and a developer point of view. See below for reasons why
> the potential third scenario - the suggestion to "cache" configuration
> information - is badly flawed.
>
>
>>[Harmeet]
>>Listener-dispactch(handler) is the pattern followed in current code.
>
> It is
>
>>more flexible than server class hierarchy. The missing piece is
>
> confusing
>
>>and repeated configuration of the handler not a problem with the
>
> pattern
>
>>iteself. Most other servers try to separate the listeners from
>
> dispatch
>
>>workers/handlers.
>
>
> The current code is a listener-dispatch pattern. It is a
> listener-dispatch pattern, and would remain so after the changes I
> propose.
>
> I don't think you quite understand what a listener-dispatch pattern
> implies. There is absolutely no requirement in that pattern (and
> certainly it doesn't hold true in generic implementations) that the
> listener be generic. In general, the listener is specific to the
> particular service being implemented. Usually there is a common
> interface that describes the listener-handler (in this case
> ConnectionHandlerFactory / ConnectionHandler) but there is certainly no
> requirement (nor is it desirable) that either part of the pattern be
> generic. This pattern is all about a division of responsibility, not
> about the ability to swap in and out different partners. The division
> of responsibility is clarified in my proposal, as all the configuration
> is moved to the listener and the handler can focus on its purpose -
> describing the logic for a particular transaction type (NNTP, SMTP,
> etc.).
>
> As I stated before, neither side is generic in the current code base.
> The server or listener side inherits from a reasonably heavyweight
> AbstractService class - about the same weight as the
> AbstractJamesService class, but with fewer features.
>
>
>>[Harmeet]
>>Params/Config need not require revalidation and if they do there will
>
> be
>
>>the
>>overhead that you are avoiding by server class hierarchy.
>>
>
>
> Again, this is not correct. You need to validate your config
> parameters. You need to do it somewhere. If you load and parse the
> parameters in the handler, you do it in the handler. If you load and
> parse the parameters in the server class, you do it in the server class.
>
>
>>[Harmeet]
>>Cache the config. Precalculation for handlers, isn't that the only
>
> gain in
>
>>having a server class hierarchy. Maybe that idea can be abstracted and
>>used
>>with current model.
>>
>
>
> No, this isn't the only gain in having a server class hierarchy. See
> this email and the previous one for a discussion of gains. They
> include, but aren't limited to, better error handling, clearer logging,
> simpler configuration, and simpler code.
>
> Moreover this caching idea you suggest is even worse than the current
> code. Consider the situation. Since you object to distinguishing
> between the server objects, presumably you're going to have the "first"
> handler for the service initialize the configuration and all others will
> access it. That's because someone has to initialize the config. If
> you've got a generic server with no ability to interpret the content of
> the configuration, it has to be the handler. This is a classic server
> design anti-pattern. Because what you've done is introduced a mutable
> (because the handler has to do the initial parsing and setting to
> defaults), shared configuration object. Access to this object will
> require a lock on every call, because the handler has to check if the
> config is initialized and, if not, initialize it. This becomes a
> heavily contested lock. Very expensive, destroys performance.
>
> Now, let's imagine that we admit that the natural place for the
> configuration parsing is in the server class. But we still want to
> stick with this notion of "generic" arguments passed to the handler.
> What's wrong with this? The basic problem with it is that you don't
> gain anything over the approach I suggest and you lose type safety. The
> server class still needs to know what type of service it represents in
> order to parse and validate the configuration parameters. In addition,
> if we restrict ourselves to the Avalon configuration rather than some
> Properties object, we lose even more. Configuration parameters that
> aren't easily represented as Strings become difficult to pass to the
> handler. We have to put some String key in place, and give the handler
> the Configuration. It pulls out the String, and looks up the non-String
> thing. Ugh.
>
> This is simple?
>
>
>>>>This leads to tighter coupling between the
>>>>Handlers and the corresponding server classes, but that's simply
>>>>recognition of a pre-existing reality. These classes are
>>>
> extremely
>
>>>>tightly coupled.
>>>
>>>Server is a listener. Handler contains protocol specific stuff. Why
>>
>>would
>>
>>>there be a (tight) coupling ?
>>>It is a listen-dispatch mechanism. Shouldn't it be as loosely
>>
> coupled
>
>>as
>>
>>>possible ?
>>
>>This is a somewhat naïve view of a service architecture. Servers
>
> aren't
>
>>generic. If they were, we'd need only one server class period. But
>>servers are different from one another, so we need separate server
>>classes. You can see how the servers differ by examining the diffs
>
> for
>
>>the assorted server classes that were submitted with this patch.
>>
>>
>>
>>[Harmeet]
>>No I am saying listeners are generic. Handlers/Workers are specific. A
>
> mix
>
>>of two makes service and servers.
>>
>
>
> Listeners are not generic. Not even close. They aren't now, they can't
> be for the reasons I outlined in my last email, and there's been no
> compelling reason presented for them to be generic.
>
>
>
>>[Harmeet]
>>But a socket listener associated with SMTP handler makes an SMTP
>
> Service.
>
>>That is the current state.
>>An incremental and better system would be Socket Listener with Config
>>Object
>>and Handler makes a Service.
>>
>>A Bad State would be a server class hierarchy that couples Listener,
>>Config
>>and Handler.
>>
>>-------------------------------
>
>
> I couldn't disagree more with this statement.
>
> It's a typical expression of extensibility at any cost. The trick to
> writing extensible code is to pick your extension points. The
> Configuration object is generic, so the class itself is not coupled to
> the server or the handler. Of course the specific values stored in that
> Configuration object ARE tightly coupled to the SMTP server. They have
> to be, as they're the values that configure how the SMTP server runs.
>
> The Handler and Listener should be tightly coupled. There is no reason
> why an NNTPServer should work with a SMTPHandler. That wouldn't make
> any sense. Even in the proposed solution they wouldn't work together -
> they'd just fail miserably on each connection because the SMTPHandler
> wouldn't have the parameters it needed. The handler and listener are
> tightly coupled precisely because they are implementations of a service
> - a service that has configuration, server specific details, and a
> protocol.
>
>
>>[Harmeet]
>>Port, queus size etc are the only listener concerns.
>>
>
>
> Port, queue, etc.? What's hidden in the etc.?
>
> Trivializing the listener concerns like this is just hiding the issue.
> The listener is responsible for socket and connection management, so it
> needs to be able to specify the ConnectionManager and socket type. As
> the ConnectionManager needs a thread group to invoke a server
> connection, it needs a thread group. For certain services there will be
> configuration restriction logic related to the socket types (imagine
> publishing an HTTPS service with TCP/IP sockets). This all belongs in
> the listener. The handler can't deal with any of it, because by the
> time the handler is invoked this needs to have been already dealt with.
> So the listener has to have a very non-trivial configuration.
>
>
>>-------------------------------
>>
>>Second, there are resources provided by the server that depend on the
>>configuration. Yes, it's possible to re-read the configuration on a
>
> per
>
>>handler invocation basis. But that's a bad idea for the reasons
>>described above.
>>
>>[Harmeet]
>>That is why I am suggesting params or configuration object, cached for
>
> a
>
>>class of handlers.
>
>
> See above why a param (lose type safety) or configuration object (can
> only hold Stringifiable objects) is a bad idea.
>
>
>>[Harmeet]
>>Are you saying Avalon is too complicated. Avalon complexity or user
>>friendliness is not a reason to change a fairly standard
>
> listener-dispatch
>
>>model. If there are problems with Phoenix, would it be better to not
>
> use
>
>>it
>>? That is a different topic. Complexity in one part should ideally not
>
> be
>
>>reason a rearchitect another part.
>
>
> This is just silly. What's being critiqued here as over-complex is a
> vast simplification of one of the most difficult aspects of server
> design.
>
> Let me be clear - this is one of the best parts of Phoenix. It's
> incredibly well designed and well thought out and it takes one of the
> most annoying parts of server design (getting all your dependency
> checking right) and makes it trivial.
>
> Avalon in general, and Phoenix as a specific container is based around
> the idea of component oriented programming. Each of the services we
> define - the listener classes - comprises a component. It's a component
> because it can be uniquely defined by a name, provides one or more
> interfaces, exists for the life of the container, and can be looked up
> by the other components running in the container. These characteristics
> are all necessary to establish a dependency chain and ensure that each
> component can both declare what it needs to function and be evaluated as
> part of a dependency chain.
>
> The handler instances cannot be components. There are some arbitrary
> number of them, they don't have unique names, they can't be accessed by
> other components, and they have very limited lifetimes. Thus they don't
> meet the minimum requirements.
>
> Avalon is great, and Phoenix is a great container. Chucking it is
> really out of the question. This is not a fault in the Avalon
> framework, but rather a fault in your proposal. Your proposal violates
> basic principles of component oriented design.
>
>
>
>>-------------------------------
>>
>>[Harmeet]
>>You can have different services. POP3 and POP3 Secure. Doesn't that
>
> achive
>
>>what you are describing. If you POP3 is a service, POP3 (plain) and
>
> POP3
>
>>Secure are 2 instances of it. It depends on what you mean by a
>
> service.
>
>>Effectiely if you want different listereners/threadgroups for a
>
> protocol,
>
>>that exists.
>
>
> No, it doesn't. You are misunderstanding the problem. The ability to
> configure different socket types and different thread groups is not
> present in the current code. Period. The configuration doesn't look
> for it. All it can do is "plain" sockets vs. "ssl". That's it. And
> the thread pool is always the default thread pool. There is no way to
> configure the server to use different thread pools for different
> services.
>
>
>
>>-------------------------------
>>
>>As far as the ability to handle multiple socket types, that wasn'tb
>>there. The socket type was one of two hard coded strings, and the SSL
>>selection was Boolean. So if you wanted to have two different SSL
>>socket types, one for use by the NNTP server and another for use by
>
> the
>
>>SMTP server (a very common configuration), then you would have to run
>>two separate servers. Very bad.
>>
>>[Harmeet]
>>It is pretty standard. Take a look at tomcat. They do the same thing.
>>
>
>
> No, it isn't. Almost nobody writes production servers that handle SSL
> for multiple services without providing the ability to have multiple SSL
> connection types.
>
> This is also a misunderstanding of the standard recommended production
> deployment of Tomcat.
>
> Tomcat is a reference implementation of the Servlet/JSP specs. As such
> it was an explicit decision to focus on the Servlet/JSP processing in
> Tomcat. The network interface was left uber-simple on purpose. The
> static page delivery wasn't tuned. Why? Because the developers wanted
> to focus on the core functionality.
>
> And that's why the recommended deployment of Tomcat is in a reverse
> proxy environment. Apache in front to handle complex connection
> management and configuration (and it certainly does allow multiple SSL
> connection types) and to handle static page delivery. And then Apache
> proxies Servlet and JSP requests to the Tomcat server. That allows the
> production environment to take advantage of Apache's strong connection
> management.
>
> This is a recognized weakness of the Tomcat implementation. That's why
> there is always a lot of discussion about embedding Tomcat in Avalon
> containers, etc. on the Avalon mailing lists. Because a container that
> implements the Avalon framework would provide all of the complex
> connection management features that the Tomcat implementation lacks and
> allow you to run more complex systems in non-reverse proxy environments.
>
> I don't see any reason to hobble ourselves with an unnecessary flaw.
>
>
>>[Harmeet]
>>Basically if n lines have been written out, observer resets the timer.
>>rather than only after all the lines have been written out.
>>
>
>
> And this won't work. Why? Because it ignores the distinction between
> observer and observable as well as the conditions under which we want a
> reset. The purpose of the reset here is to prevent transaction hangs,
> as much from server processing as from client processing. So the
> primary trigger reset is not the amount of data written, but rather the
> trigger that occurs every time a command is processed. A command being
> processed indicates that the transaction is proceeding. As this
> information is not available to the stream (it has no idea when a
> command has completed), the stream cannot be the observable in this
> situation. The stream data is crucial for commands that potentially
> involve large transfers of data, so the handler can't be the observable.
> So the pattern doesn't fit.
>
>
>
>>[Harmeet]
>>The observer-observable is a clean and standard pattern way. It allows
>
> an
>
>>observer to monitor and decide on timeout reset.
>>
>
>
> It is a clean and standard pattern. It's just the wrong one for this
> situation. See above.
>
> --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
Posted by Nathan Carter <na...@gmx.net>.
Peter,
Peter M. Goldstein wrote:
> Nathan,
>
>
>>1) This thread is quite interesting because I've asked many of these
>>same questions in beginning to look at the IMAP stuff, which in many
>>cases (at least the listener and handler code) seems to be based on
>
> old
>
>> versions of the POP equivalents (i.e., they are missing august and
>>september changes by danny and peter to the POP code).
>
>
> Yep. Same issues apply. For the most part, these are overarching
> architecture issues. If and when this patch is applied, it would make
> sense for the IMAP server class to extend AbstractJamesService (which
> would give it enabled/disabled, thread group control, all the code for
> starting a server socket and delegating to a ConnectionManager, etc.).
> And for the IMAPHandler to be suitably simplified so it concerns itself
> solely with IMAP protocol issues.
>
Sounds good.
> One of the most abstract, but fairly compelling, reasons for the patch
> I've proposed is that it makes rolling out new services fairly easy.
> The person rolling out the new service basically needs to understand the
> Avalon Configuration object, and then they can go to town. The current
> code base would require them to either understand the whole of the
> Server classes or to cut and paste them. The latter is especially
> likely to induce errors (as the one which seems to have existed since
> the beginning of the NNTP server project which disabled SSL).
>
>
>>2) In your initial post, you mention doing some "basic" and "load"
>>testing to further quantify the memory/robustness/scalability issues
>
> and
>
>>show how your patch solves them. What about (and I'd be happy to
>
> donate
>
>>time for this):
>>
>> a)using a profiling tool to see how much time is actually being
>>wasted by configuring each Handler instead of more tightly coupling
>
> them
>
>>to the server listener.
>
>
> This would be fine, although as I've emphasized in my other posts, this
> is more a fundamental architecture problem than a performance problem.
> There are issues with configuration, logging, and division of
> responsibility. I'd be happy to see the performance numbers, especially
> when graphed against load. Since we know the scheduler crashed the
> system under even moderate load, it's pretty clear that no one to date
> could've collected statistics on performance under heavy load. And
> that's where changes like this one have their highest performance
> impact.
>
>
>> b)Do you have before/after metrics for your load tests? A 2X
>>improvement will be a strong argument in itself. JMeter doesn't seem
>
> to
>
>>support email server load testing - is there anything better than this
>>(e.g. PushToTest,
>>http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
>
>
> Before - crashed. After - didn't crash. :)
>
That is pretty compelling :)
> There's been a recent discussion of this on the James users list, as
> well as much earlier discussion by Andrei Ivanov. The crash/not crash
> scenario, which is obviously the dominant effect, is due to the
> Scheduler->Watchdog change. I haven't
I've spent more than a few hours reading through the james-dev archives,
but the earlier history of this problem somehow escaped me. I'm sorry
if I seemed belligerant in pressing for more testing when the evidence
was already quite clear.
>
> I've been writing some of my own test scripts - nothing fancy, just
> simple Java programs that push at the server.
>
>
>>Again, I'd be more than happy to help in testing because this
>>significantly affects what I'm doing in IMAP, and I'm going to have to
>>perform this kind of testing on IMAP due to its complexity and higher
>>overhead.
>
>
> It certainly does. Once we get things stabilized for 2.1, I was
> intending to port over the code changes to the IMAP proposal. As I
> mentioned in my reply to Sascha a couple of weeks ago, merge of the 2.1
> release into the IMAP code is (IMHO) a necessary precondition for moving
> the IMAP code. I would be very happy to participate in that effort.
>
Good. Which is all the more reason for me to read and re-read the RFCs
until then and spend a lot of time looking at those parts of the
existing IMAP code (esp. the commands and test suite) which are not
affected by the proposed changes.
> --Peter
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
-Nathan
--
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Maybe, eventually . . . the IMAP SEARCH command (RFC 2060) does require
> you to be able to search text bodies as well as headers, AFAIK.
Actually, we (DevTech) already have written search code integrated with
JNDI, so if we can look at using JNDI as the high level interface to all
stores for James v3, we could look at some of that code. It would handle
mime encoded data, and understands tags as well as body content.
--- 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
Posted by Nathan Carter <na...@gmx.net>.
Harmeet Bedi wrote:
> thanks for looking this up. Do you have a search tool ? There are some
> interesting thing the lucene folks are doing. Mail indexing facility may be
> good to get from them. Does IMAP need indexing.
>
Maybe, eventually . . . the IMAP SEARCH command (RFC 2060) does require
you to be able to search text bodies as well as headers, AFAIK.
--Nathan
> About ready to post code.
> Check it out..
>
> Harmeet
> ----- Original Message -----
> From: "Noel J. Bergman" <no...@devtech.com>
> To: "James Developers List" <ja...@jakarta.apache.org>;
> <fa...@alum.mit.edu>
> Sent: Saturday, October 12, 2002 4:51 PM
> Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
>
>
>
>>Minor correction. I went back and looked. The ORIGINAL identification of
>>this problem was made by Steve Short and Shilpa Dalmia of PostX back in
>>mid-May. They raised this issue on the the Avalon Developers list on May
>>17, and on the James Developers list three days later.
>>
>>And I quote Peter Donald:
>>
>>SS: Here is why we raised this as an issue. The Apache James mail server
>>SS: project is using this timer mechanism to implement a connection
>
> timeout
>
>>on
>>SS: the SMTP port. When it receives data on the the port, it calls
>>SS: resetTrigger to resets the timer.
>>
>>PD: ouch it is not really designed for that!
>>
>>After reading through the related Avalon and James classes, I proposed a
>>watchdog on May 21. I missed one thing in terms of the magnitude of
>
> objects
>
>>created, which Serge corrected, but he did note on May 22 that: "Looks
>>rather serious... like you said, perhaps building our own trigger
>
> mechanism
>
>>is the way to go."
>>
>>Andrei Ivanov reported load test problems with James on May 30, and then
>>submitted the first version of the re-factored classes on June 3,
>
> reporting
>
>>that he was able to successfully load test with the changes ("from 6req/s
>>and crash -> 26req/s no crash").
>>
>>It was Andrei who did the basic re-factoring, including: "I replaced
>>BaseConnectionHandler with AbstractServer which implements
>>ConnectionHandlerFactory. Every other server class can now inherit from
>
> new
>
>>AbstractServer by implementing its 'public abstract
>>createConnectionHandler()'." He re-submitted in late July when they still
>>hadn't been committed (both Serge and Danny knew about them, but neither
>
> had
>
>>time to deal with them, as Danny apologized), and then again in
>
> mid-August.
>
>>At that point, Peter said that he'd take care of picking up Andrei's code,
>>re-doing all of the services to use it (Andrei had only done SMTP), and
>>hoped to have it in the code base about a week later. Unfortunately,
>
> Peter
>
>>got side tracked on all sorts of other Committer responsibilities (e.g.,
>>testing and committing other fixes that needed to be done), but this
>
> change
>
>>is finally ready for the CVS.
>>
>>That pretty much covers the long history of these two change areas.
>>
>>--- Noel
>>
>>
>>--
>>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>
>
>
--
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
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
This is what I got running postal against your server:
./postal -m 1 -p 10 -c 1000 24.102.230.223 userlist -
time,messages,data(K),errors,connections,SSL connections
01:20,560,452,5,10,0
01:21,556,454,0,0,0
01:22,529,432,0,0,0
01:23,533,436,0,2,0
01:24,496,406,0,0,0
01:20,560,452,5,10,0
01:21,556,454,0,0,0
Server error:Connection timeout. Closing connection
Server error:Connection timeout. Closing connection
Server error:Connection timeout. Closing connection
Server error:Connection timeout. Closing connection
Server error:Connection timeout. Closing connection
I was still able to telnet into it, though, so it didn't completely die.
What we see is that with 10 threads sending 1000 1K messages per connection,
we get 550 or so messages per minute aggregate. I have no idea why there is
a discrepency between messages and K (I'll ask Russell about that oddity).
Mind you, that is using the current CVS code, since SMTP wasn't changed.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Sunday, October 13, 2002 4:11
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
----- Original Message -----
> I have postal running to do load testing. If you want me to run a load
> test directly on your server send me the address off-list and an username
> you want me to send to (so that you can put:
I have opened up port 110, 25, 4555(for remote manager). My home IP Is
24.102.230.223.
I'll keep the server running. But may not around for long. Too late at night
and wife is ready to kill me.
Did a clean build with my patches. Only POP3 has scheduler patches.
There are 11 users - harmeet, user1, user2, user3, user4, user5, user6,
user7, user8, user9, and userA
My bandwidth and machine are not too powerful, so you may not get the best
results.. but please give it shot. Would love to see the results.
thanks,
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Saturday, October 12, 2002 9:50 PM
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> Harmeet,
>
> Not a problem. If I were new or newly returned to a project and had
> questions, I'd want someone to help me catch up, too. I just searched the
> archives using their search tool.
I have used Lucene a bit, would be nice to do something with it again.
Pretty good stuff. Orig. author contributed significantly to a major search
engine. There are sites that use lucene for mail indexing/search.
When IMAP is there, maybe we can have on IMAP folders exposed and
searchable. IMAP folder could be say 'james-dev' or 'james-dev-removing
scheduler.....' :-)
>
> I have postal running to do load testing. If you want me to run a load
test
> directly on your server send me the address off-list and an username you
> want me to send to (so that you can put:
I have opened up port 110, 25, 4555(for remote manager). My home IP Is
24.102.230.223.
I'll keep the server running. But may not around for long. Too late at night
and wife is ready to kill me.
Did a clean build with my patches. Only POP3 has scheduler patches.
There are 11 users - harmeet, user1, user2, user3, user4, user5, user6,
user7, user8, user9, and userA
My bandwidth and machine are not too powerful, so you may not get the best
results.. but please give it shot. Would love to see the results.
thanks,
Harmeet
>
> <mailet match="RecipientIs=<username>" class="Null" />
>
> in your config.xml file.
>
> --- Noel
>
> -----Original Message-----
> From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
> Sent: Sunday, October 13, 2002 3:31
> To: James Developers List
> Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
> code
>
>
> thanks for looking this up. Do you have a search tool ? There are some
> interesting thing the lucene folks are doing. Mail indexing facility may
be
> good to get from them. Does IMAP need indexing.
>
> About ready to post code.
> Check it out..
>
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
Harmeet,
Not a problem. If I were new or newly returned to a project and had
questions, I'd want someone to help me catch up, too. I just searched the
archives using their search tool.
I have postal running to do load testing. If you want me to run a load test
directly on your server send me the address off-list and an username you
want me to send to (so that you can put:
<mailet match="RecipientIs=<username>" class="Null" />
in your config.xml file.
--- Noel
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@kodemuse.com]
Sent: Sunday, October 13, 2002 3:31
To: James Developers List
Subject: Re: [PATCH] Removing Scheduler dependency, refactoring service
code
thanks for looking this up. Do you have a search tool ? There are some
interesting thing the lucene folks are doing. Mail indexing facility may be
good to get from them. Does IMAP need indexing.
About ready to post code.
Check it out..
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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
thanks for looking this up. Do you have a search tool ? There are some
interesting thing the lucene folks are doing. Mail indexing facility may be
good to get from them. Does IMAP need indexing.
About ready to post code.
Check it out..
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>;
<fa...@alum.mit.edu>
Sent: Saturday, October 12, 2002 4:51 PM
Subject: RE: [PATCH] Removing Scheduler dependency, refactoring service code
> Minor correction. I went back and looked. The ORIGINAL identification of
> this problem was made by Steve Short and Shilpa Dalmia of PostX back in
> mid-May. They raised this issue on the the Avalon Developers list on May
> 17, and on the James Developers list three days later.
>
> And I quote Peter Donald:
>
> SS: Here is why we raised this as an issue. The Apache James mail server
> SS: project is using this timer mechanism to implement a connection
timeout
> on
> SS: the SMTP port. When it receives data on the the port, it calls
> SS: resetTrigger to resets the timer.
>
> PD: ouch it is not really designed for that!
>
> After reading through the related Avalon and James classes, I proposed a
> watchdog on May 21. I missed one thing in terms of the magnitude of
objects
> created, which Serge corrected, but he did note on May 22 that: "Looks
> rather serious... like you said, perhaps building our own trigger
mechanism
> is the way to go."
>
> Andrei Ivanov reported load test problems with James on May 30, and then
> submitted the first version of the re-factored classes on June 3,
reporting
> that he was able to successfully load test with the changes ("from 6req/s
> and crash -> 26req/s no crash").
>
> It was Andrei who did the basic re-factoring, including: "I replaced
> BaseConnectionHandler with AbstractServer which implements
> ConnectionHandlerFactory. Every other server class can now inherit from
new
> AbstractServer by implementing its 'public abstract
> createConnectionHandler()'." He re-submitted in late July when they still
> hadn't been committed (both Serge and Danny knew about them, but neither
had
> time to deal with them, as Danny apologized), and then again in
mid-August.
> At that point, Peter said that he'd take care of picking up Andrei's code,
> re-doing all of the services to use it (Andrei had only done SMTP), and
> hoped to have it in the code base about a week later. Unfortunately,
Peter
> got side tracked on all sorts of other Committer responsibilities (e.g.,
> testing and committing other fixes that needed to be done), but this
change
> is finally ready for the CVS.
>
> That pretty much covers the long history of these two change areas.
>
> --- Noel
>
>
> --
> 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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Noel J. Bergman" <no...@devtech.com>.
Minor correction. I went back and looked. The ORIGINAL identification of
this problem was made by Steve Short and Shilpa Dalmia of PostX back in
mid-May. They raised this issue on the the Avalon Developers list on May
17, and on the James Developers list three days later.
And I quote Peter Donald:
SS: Here is why we raised this as an issue. The Apache James mail server
SS: project is using this timer mechanism to implement a connection timeout
on
SS: the SMTP port. When it receives data on the the port, it calls
SS: resetTrigger to resets the timer.
PD: ouch it is not really designed for that!
After reading through the related Avalon and James classes, I proposed a
watchdog on May 21. I missed one thing in terms of the magnitude of objects
created, which Serge corrected, but he did note on May 22 that: "Looks
rather serious... like you said, perhaps building our own trigger mechanism
is the way to go."
Andrei Ivanov reported load test problems with James on May 30, and then
submitted the first version of the re-factored classes on June 3, reporting
that he was able to successfully load test with the changes ("from 6req/s
and crash -> 26req/s no crash").
It was Andrei who did the basic re-factoring, including: "I replaced
BaseConnectionHandler with AbstractServer which implements
ConnectionHandlerFactory. Every other server class can now inherit from new
AbstractServer by implementing its 'public abstract
createConnectionHandler()'." He re-submitted in late July when they still
hadn't been committed (both Serge and Danny knew about them, but neither had
time to deal with them, as Danny apologized), and then again in mid-August.
At that point, Peter said that he'd take care of picking up Andrei's code,
re-doing all of the services to use it (Andrei had only done SMTP), and
hoped to have it in the code base about a week later. Unfortunately, Peter
got side tracked on all sorts of other Committer responsibilities (e.g.,
testing and committing other fixes that needed to be done), but this change
is finally ready for the CVS.
That pretty much covers the long history of these two change areas.
--- 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
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Nathan,
> 1) This thread is quite interesting because I've asked many of these
> same questions in beginning to look at the IMAP stuff, which in many
> cases (at least the listener and handler code) seems to be based on
old
> versions of the POP equivalents (i.e., they are missing august and
> september changes by danny and peter to the POP code).
Yep. Same issues apply. For the most part, these are overarching
architecture issues. If and when this patch is applied, it would make
sense for the IMAP server class to extend AbstractJamesService (which
would give it enabled/disabled, thread group control, all the code for
starting a server socket and delegating to a ConnectionManager, etc.).
And for the IMAPHandler to be suitably simplified so it concerns itself
solely with IMAP protocol issues.
One of the most abstract, but fairly compelling, reasons for the patch
I've proposed is that it makes rolling out new services fairly easy.
The person rolling out the new service basically needs to understand the
Avalon Configuration object, and then they can go to town. The current
code base would require them to either understand the whole of the
Server classes or to cut and paste them. The latter is especially
likely to induce errors (as the one which seems to have existed since
the beginning of the NNTP server project which disabled SSL).
> 2) In your initial post, you mention doing some "basic" and "load"
> testing to further quantify the memory/robustness/scalability issues
and
> show how your patch solves them. What about (and I'd be happy to
donate
> time for this):
>
> a)using a profiling tool to see how much time is actually being
> wasted by configuring each Handler instead of more tightly coupling
them
> to the server listener.
This would be fine, although as I've emphasized in my other posts, this
is more a fundamental architecture problem than a performance problem.
There are issues with configuration, logging, and division of
responsibility. I'd be happy to see the performance numbers, especially
when graphed against load. Since we know the scheduler crashed the
system under even moderate load, it's pretty clear that no one to date
could've collected statistics on performance under heavy load. And
that's where changes like this one have their highest performance
impact.
> b)Do you have before/after metrics for your load tests? A 2X
> improvement will be a strong argument in itself. JMeter doesn't seem
to
> support email server load testing - is there anything better than this
> (e.g. PushToTest,
> http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
Before - crashed. After - didn't crash. :)
There's been a recent discussion of this on the James users list, as
well as much earlier discussion by Andrei Ivanov. The crash/not crash
scenario, which is obviously the dominant effect, is due to the
Scheduler->Watchdog change. I haven't
I've been writing some of my own test scripts - nothing fancy, just
simple Java programs that push at the server.
> Again, I'd be more than happy to help in testing because this
> significantly affects what I'm doing in IMAP, and I'm going to have to
> perform this kind of testing on IMAP due to its complexity and higher
> overhead.
It certainly does. Once we get things stabilized for 2.1, I was
intending to port over the code changes to the IMAP proposal. As I
mentioned in my reply to Sascha a couple of weeks ago, merge of the 2.1
release into the IMAP code is (IMHO) a necessary precondition for moving
the IMAP code. I would be very happy to participate in that effort.
--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
Posted by Nathan Carter <na...@gmx.net>.
Peter et al,
1) This thread is quite interesting because I've asked many of these
same questions in beginning to look at the IMAP stuff, which in many
cases (at least the listener and handler code) seems to be based on old
versions of the POP equivalents (i.e., they are missing august and
september changes by danny and peter to the POP code).
2) In your initial post, you mention doing some "basic" and "load"
testing to further quantify the memory/robustness/scalability issues and
show how your patch solves them. What about (and I'd be happy to donate
time for this):
a)using a profiling tool to see how much time is actually being
wasted by configuring each Handler instead of more tightly coupling them
to the server listener.
b)Do you have before/after metrics for your load tests? A 2X
improvement will be a strong argument in itself. JMeter doesn't seem to
support email server load testing - is there anything better than this
(e.g. PushToTest,
http://www.etestinglabs.com/benchmarks/svrtools/email/t1intro.asp)?
Again, I'd be more than happy to help in testing because this
significantly affects what I'm doing in IMAP, and I'm going to have to
perform this kind of testing on IMAP due to its complexity and higher
overhead.
Nathan Carter
Peter M. Goldstein wrote:
> Harmeet et al,
>
>
>>Because the scheduler is the wrong abstraction. This is not a
>
> scheduler
>
>>problem - it's a timeout. A timeout is far simpler than a scheduler.
>>And that's the core issue.
>>
>>
>>[Harmeet]
>>One time timer task rather than repeated timer tasks is the same thing
>
> as
>
>>Watchdog timeout. It is property of implementation.
>>
>
>
> See Noel's comments on this.
>
> I also want to add that this situation is directly analogous to the
> AuthService issue. The interface itself defines a contract. In the
> case of the Scheduler, that contract requires support for multi-threaded
> lookup of targets on each reset. This requires lock contention
> (assuming the implementation properly implements the contract) on each
> reset. Lock contention which is both unnecessary, since no handler is
> interested in the target of any other timeout and potentially expensive
> (multi-way lock contentions cost ~50x uncontested locks/volatiles in
> modern JVMs). The interface contract puts restrictions on the
> implementation.
>
> I'm not going to respond to the rest of the specific scheduler comments,
> because they all labor under the same confusion of interface contract
> and implementation. Noel nailed the crucial point.
>
>
>>[Harmeet]
>>A Config object can take care of this. Handlers don't need to
>>expose themselves to lifecycle. What you are describing is
>
> configuration
>
>>per
>>handler and as you pointed out that is not needed. You are also saying
>>configuration is spread out, that can be centralized too in a config
>>object.
>>
>
>
> This is not correct.
>
> There are a couple of real problems with this proposal, some of them
> highlighted in Noel's reply, some not.
>
> Let's start with the situation. We have a block definition in Phoenix
> that represents a service. This class representing this block
> (NNTPServer, SMTPServer, etc.) is instantiated by Phoenix (or any other
> Avalon container) and is passed a read-only Configuration object (see
> the comments for the Configuration interface). What happens now?
>
> In the current code base the following behavior occurs. Some parameters
> (port, isSSL, enabled) are read out of the configuration, validated, and
> set to defaults if they are not present. The parameters that are read
> and validated are logged, the rest are not. Note that even this
> functionality requires customized Server classes for each service.
>
> A child of the Configuration is then passed to the superclass
> AbstractService. There is no clear distinction between the elements
> that are in the top level Configuration object and its child class.
> When the first connection (and every subsequent connection) is made, the
> remainder of the Configuration parameters are read and validated. This
> expense is incurred on each connection. Note that the server may fail
> because of bad configuration upon first connection, which may be hours
> or even days after the server was started.
>
> Changes to the handler which add additional component dependencies now
> require alteration to the supposedly independent server configuration,
> both in the .xinfo and in the assembly.xml. This is totally non-obvious
> from the "decoupled" listener/handler model.
>
> Now consider the situation with the changed code. The server starts and
> all service configuration parameters are read, validated, and set to
> defaults if they are not present. Any fatal misconfiguration will be
> detected here and cause server failure. All service configuration
> information is logged, so an administrator can simply look at the
> startup log and see how the service was configured. There is no extra
> per-connection logging to that prints a config parameter that doesn't
> change over the life of the server. It's stated just once in the log.
>
> Since the handler is viewed as tightly coupled to the listener, and
> dependency checking is understood to be a function of the listener
> block, it is obvious that changes to the handler that introduce new
> dependencies will require modification of the listener configuration
> files.
>
> Personally I much prefer the second scenario. It's cleaner from both an
> administrator and a developer point of view. See below for reasons why
> the potential third scenario - the suggestion to "cache" configuration
> information - is badly flawed.
>
>
>>[Harmeet]
>>Listener-dispactch(handler) is the pattern followed in current code.
>
> It is
>
>>more flexible than server class hierarchy. The missing piece is
>
> confusing
>
>>and repeated configuration of the handler not a problem with the
>
> pattern
>
>>iteself. Most other servers try to separate the listeners from
>
> dispatch
>
>>workers/handlers.
>
>
> The current code is a listener-dispatch pattern. It is a
> listener-dispatch pattern, and would remain so after the changes I
> propose.
>
> I don't think you quite understand what a listener-dispatch pattern
> implies. There is absolutely no requirement in that pattern (and
> certainly it doesn't hold true in generic implementations) that the
> listener be generic. In general, the listener is specific to the
> particular service being implemented. Usually there is a common
> interface that describes the listener-handler (in this case
> ConnectionHandlerFactory / ConnectionHandler) but there is certainly no
> requirement (nor is it desirable) that either part of the pattern be
> generic. This pattern is all about a division of responsibility, not
> about the ability to swap in and out different partners. The division
> of responsibility is clarified in my proposal, as all the configuration
> is moved to the listener and the handler can focus on its purpose -
> describing the logic for a particular transaction type (NNTP, SMTP,
> etc.).
>
> As I stated before, neither side is generic in the current code base.
> The server or listener side inherits from a reasonably heavyweight
> AbstractService class - about the same weight as the
> AbstractJamesService class, but with fewer features.
>
>
>>[Harmeet]
>>Params/Config need not require revalidation and if they do there will
>
> be
>
>>the
>>overhead that you are avoiding by server class hierarchy.
>>
>
>
> Again, this is not correct. You need to validate your config
> parameters. You need to do it somewhere. If you load and parse the
> parameters in the handler, you do it in the handler. If you load and
> parse the parameters in the server class, you do it in the server class.
>
>
>>[Harmeet]
>>Cache the config. Precalculation for handlers, isn't that the only
>
> gain in
>
>>having a server class hierarchy. Maybe that idea can be abstracted and
>>used
>>with current model.
>>
>
>
> No, this isn't the only gain in having a server class hierarchy. See
> this email and the previous one for a discussion of gains. They
> include, but aren't limited to, better error handling, clearer logging,
> simpler configuration, and simpler code.
>
> Moreover this caching idea you suggest is even worse than the current
> code. Consider the situation. Since you object to distinguishing
> between the server objects, presumably you're going to have the "first"
> handler for the service initialize the configuration and all others will
> access it. That's because someone has to initialize the config. If
> you've got a generic server with no ability to interpret the content of
> the configuration, it has to be the handler. This is a classic server
> design anti-pattern. Because what you've done is introduced a mutable
> (because the handler has to do the initial parsing and setting to
> defaults), shared configuration object. Access to this object will
> require a lock on every call, because the handler has to check if the
> config is initialized and, if not, initialize it. This becomes a
> heavily contested lock. Very expensive, destroys performance.
>
> Now, let's imagine that we admit that the natural place for the
> configuration parsing is in the server class. But we still want to
> stick with this notion of "generic" arguments passed to the handler.
> What's wrong with this? The basic problem with it is that you don't
> gain anything over the approach I suggest and you lose type safety. The
> server class still needs to know what type of service it represents in
> order to parse and validate the configuration parameters. In addition,
> if we restrict ourselves to the Avalon configuration rather than some
> Properties object, we lose even more. Configuration parameters that
> aren't easily represented as Strings become difficult to pass to the
> handler. We have to put some String key in place, and give the handler
> the Configuration. It pulls out the String, and looks up the non-String
> thing. Ugh.
>
> This is simple?
>
>
>>>>This leads to tighter coupling between the
>>>>Handlers and the corresponding server classes, but that's simply
>>>>recognition of a pre-existing reality. These classes are
>>>
> extremely
>
>>>>tightly coupled.
>>>
>>>Server is a listener. Handler contains protocol specific stuff. Why
>>
>>would
>>
>>>there be a (tight) coupling ?
>>>It is a listen-dispatch mechanism. Shouldn't it be as loosely
>>
> coupled
>
>>as
>>
>>>possible ?
>>
>>This is a somewhat naïve view of a service architecture. Servers
>
> aren't
>
>>generic. If they were, we'd need only one server class period. But
>>servers are different from one another, so we need separate server
>>classes. You can see how the servers differ by examining the diffs
>
> for
>
>>the assorted server classes that were submitted with this patch.
>>
>>
>>
>>[Harmeet]
>>No I am saying listeners are generic. Handlers/Workers are specific. A
>
> mix
>
>>of two makes service and servers.
>>
>
>
> Listeners are not generic. Not even close. They aren't now, they can't
> be for the reasons I outlined in my last email, and there's been no
> compelling reason presented for them to be generic.
>
>
>
>>[Harmeet]
>>But a socket listener associated with SMTP handler makes an SMTP
>
> Service.
>
>>That is the current state.
>>An incremental and better system would be Socket Listener with Config
>>Object
>>and Handler makes a Service.
>>
>>A Bad State would be a server class hierarchy that couples Listener,
>>Config
>>and Handler.
>>
>>-------------------------------
>
>
> I couldn't disagree more with this statement.
>
> It's a typical expression of extensibility at any cost. The trick to
> writing extensible code is to pick your extension points. The
> Configuration object is generic, so the class itself is not coupled to
> the server or the handler. Of course the specific values stored in that
> Configuration object ARE tightly coupled to the SMTP server. They have
> to be, as they're the values that configure how the SMTP server runs.
>
> The Handler and Listener should be tightly coupled. There is no reason
> why an NNTPServer should work with a SMTPHandler. That wouldn't make
> any sense. Even in the proposed solution they wouldn't work together -
> they'd just fail miserably on each connection because the SMTPHandler
> wouldn't have the parameters it needed. The handler and listener are
> tightly coupled precisely because they are implementations of a service
> - a service that has configuration, server specific details, and a
> protocol.
>
>
>>[Harmeet]
>>Port, queus size etc are the only listener concerns.
>>
>
>
> Port, queue, etc.? What's hidden in the etc.?
>
> Trivializing the listener concerns like this is just hiding the issue.
> The listener is responsible for socket and connection management, so it
> needs to be able to specify the ConnectionManager and socket type. As
> the ConnectionManager needs a thread group to invoke a server
> connection, it needs a thread group. For certain services there will be
> configuration restriction logic related to the socket types (imagine
> publishing an HTTPS service with TCP/IP sockets). This all belongs in
> the listener. The handler can't deal with any of it, because by the
> time the handler is invoked this needs to have been already dealt with.
> So the listener has to have a very non-trivial configuration.
>
>
>>-------------------------------
>>
>>Second, there are resources provided by the server that depend on the
>>configuration. Yes, it's possible to re-read the configuration on a
>
> per
>
>>handler invocation basis. But that's a bad idea for the reasons
>>described above.
>>
>>[Harmeet]
>>That is why I am suggesting params or configuration object, cached for
>
> a
>
>>class of handlers.
>
>
> See above why a param (lose type safety) or configuration object (can
> only hold Stringifiable objects) is a bad idea.
>
>
>>[Harmeet]
>>Are you saying Avalon is too complicated. Avalon complexity or user
>>friendliness is not a reason to change a fairly standard
>
> listener-dispatch
>
>>model. If there are problems with Phoenix, would it be better to not
>
> use
>
>>it
>>? That is a different topic. Complexity in one part should ideally not
>
> be
>
>>reason a rearchitect another part.
>
>
> This is just silly. What's being critiqued here as over-complex is a
> vast simplification of one of the most difficult aspects of server
> design.
>
> Let me be clear - this is one of the best parts of Phoenix. It's
> incredibly well designed and well thought out and it takes one of the
> most annoying parts of server design (getting all your dependency
> checking right) and makes it trivial.
>
> Avalon in general, and Phoenix as a specific container is based around
> the idea of component oriented programming. Each of the services we
> define - the listener classes - comprises a component. It's a component
> because it can be uniquely defined by a name, provides one or more
> interfaces, exists for the life of the container, and can be looked up
> by the other components running in the container. These characteristics
> are all necessary to establish a dependency chain and ensure that each
> component can both declare what it needs to function and be evaluated as
> part of a dependency chain.
>
> The handler instances cannot be components. There are some arbitrary
> number of them, they don't have unique names, they can't be accessed by
> other components, and they have very limited lifetimes. Thus they don't
> meet the minimum requirements.
>
> Avalon is great, and Phoenix is a great container. Chucking it is
> really out of the question. This is not a fault in the Avalon
> framework, but rather a fault in your proposal. Your proposal violates
> basic principles of component oriented design.
>
>
>
>>-------------------------------
>>
>>[Harmeet]
>>You can have different services. POP3 and POP3 Secure. Doesn't that
>
> achive
>
>>what you are describing. If you POP3 is a service, POP3 (plain) and
>
> POP3
>
>>Secure are 2 instances of it. It depends on what you mean by a
>
> service.
>
>>Effectiely if you want different listereners/threadgroups for a
>
> protocol,
>
>>that exists.
>
>
> No, it doesn't. You are misunderstanding the problem. The ability to
> configure different socket types and different thread groups is not
> present in the current code. Period. The configuration doesn't look
> for it. All it can do is "plain" sockets vs. "ssl". That's it. And
> the thread pool is always the default thread pool. There is no way to
> configure the server to use different thread pools for different
> services.
>
>
>
>>-------------------------------
>>
>>As far as the ability to handle multiple socket types, that wasn'tb
>>there. The socket type was one of two hard coded strings, and the SSL
>>selection was Boolean. So if you wanted to have two different SSL
>>socket types, one for use by the NNTP server and another for use by
>
> the
>
>>SMTP server (a very common configuration), then you would have to run
>>two separate servers. Very bad.
>>
>>[Harmeet]
>>It is pretty standard. Take a look at tomcat. They do the same thing.
>>
>
>
> No, it isn't. Almost nobody writes production servers that handle SSL
> for multiple services without providing the ability to have multiple SSL
> connection types.
>
> This is also a misunderstanding of the standard recommended production
> deployment of Tomcat.
>
> Tomcat is a reference implementation of the Servlet/JSP specs. As such
> it was an explicit decision to focus on the Servlet/JSP processing in
> Tomcat. The network interface was left uber-simple on purpose. The
> static page delivery wasn't tuned. Why? Because the developers wanted
> to focus on the core functionality.
>
> And that's why the recommended deployment of Tomcat is in a reverse
> proxy environment. Apache in front to handle complex connection
> management and configuration (and it certainly does allow multiple SSL
> connection types) and to handle static page delivery. And then Apache
> proxies Servlet and JSP requests to the Tomcat server. That allows the
> production environment to take advantage of Apache's strong connection
> management.
>
> This is a recognized weakness of the Tomcat implementation. That's why
> there is always a lot of discussion about embedding Tomcat in Avalon
> containers, etc. on the Avalon mailing lists. Because a container that
> implements the Avalon framework would provide all of the complex
> connection management features that the Tomcat implementation lacks and
> allow you to run more complex systems in non-reverse proxy environments.
>
> I don't see any reason to hobble ourselves with an unnecessary flaw.
>
>
>>[Harmeet]
>>Basically if n lines have been written out, observer resets the timer.
>>rather than only after all the lines have been written out.
>>
>
>
> And this won't work. Why? Because it ignores the distinction between
> observer and observable as well as the conditions under which we want a
> reset. The purpose of the reset here is to prevent transaction hangs,
> as much from server processing as from client processing. So the
> primary trigger reset is not the amount of data written, but rather the
> trigger that occurs every time a command is processed. A command being
> processed indicates that the transaction is proceeding. As this
> information is not available to the stream (it has no idea when a
> command has completed), the stream cannot be the observable in this
> situation. The stream data is crucial for commands that potentially
> involve large transfers of data, so the handler can't be the observable.
> So the pattern doesn't fit.
>
>
>
>>[Harmeet]
>>The observer-observable is a clean and standard pattern way. It allows
>
> an
>
>>observer to monitor and decide on timeout reset.
>>
>
>
> It is a clean and standard pattern. It's just the wrong one for this
> situation. See above.
>
> --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: [PATCH] Removing Scheduler dependency, refactoring service code
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Harmeet et al,
> Because the scheduler is the wrong abstraction. This is not a
scheduler
> problem - it's a timeout. A timeout is far simpler than a scheduler.
> And that's the core issue.
>
>
> [Harmeet]
> One time timer task rather than repeated timer tasks is the same thing
as
> Watchdog timeout. It is property of implementation.
>
See Noel's comments on this.
I also want to add that this situation is directly analogous to the
AuthService issue. The interface itself defines a contract. In the
case of the Scheduler, that contract requires support for multi-threaded
lookup of targets on each reset. This requires lock contention
(assuming the implementation properly implements the contract) on each
reset. Lock contention which is both unnecessary, since no handler is
interested in the target of any other timeout and potentially expensive
(multi-way lock contentions cost ~50x uncontested locks/volatiles in
modern JVMs). The interface contract puts restrictions on the
implementation.
I'm not going to respond to the rest of the specific scheduler comments,
because they all labor under the same confusion of interface contract
and implementation. Noel nailed the crucial point.
> [Harmeet]
> A Config object can take care of this. Handlers don't need to
> expose themselves to lifecycle. What you are describing is
configuration
> per
> handler and as you pointed out that is not needed. You are also saying
> configuration is spread out, that can be centralized too in a config
> object.
>
This is not correct.
There are a couple of real problems with this proposal, some of them
highlighted in Noel's reply, some not.
Let's start with the situation. We have a block definition in Phoenix
that represents a service. This class representing this block
(NNTPServer, SMTPServer, etc.) is instantiated by Phoenix (or any other
Avalon container) and is passed a read-only Configuration object (see
the comments for the Configuration interface). What happens now?
In the current code base the following behavior occurs. Some parameters
(port, isSSL, enabled) are read out of the configuration, validated, and
set to defaults if they are not present. The parameters that are read
and validated are logged, the rest are not. Note that even this
functionality requires customized Server classes for each service.
A child of the Configuration is then passed to the superclass
AbstractService. There is no clear distinction between the elements
that are in the top level Configuration object and its child class.
When the first connection (and every subsequent connection) is made, the
remainder of the Configuration parameters are read and validated. This
expense is incurred on each connection. Note that the server may fail
because of bad configuration upon first connection, which may be hours
or even days after the server was started.
Changes to the handler which add additional component dependencies now
require alteration to the supposedly independent server configuration,
both in the .xinfo and in the assembly.xml. This is totally non-obvious
from the "decoupled" listener/handler model.
Now consider the situation with the changed code. The server starts and
all service configuration parameters are read, validated, and set to
defaults if they are not present. Any fatal misconfiguration will be
detected here and cause server failure. All service configuration
information is logged, so an administrator can simply look at the
startup log and see how the service was configured. There is no extra
per-connection logging to that prints a config parameter that doesn't
change over the life of the server. It's stated just once in the log.
Since the handler is viewed as tightly coupled to the listener, and
dependency checking is understood to be a function of the listener
block, it is obvious that changes to the handler that introduce new
dependencies will require modification of the listener configuration
files.
Personally I much prefer the second scenario. It's cleaner from both an
administrator and a developer point of view. See below for reasons why
the potential third scenario - the suggestion to "cache" configuration
information - is badly flawed.
> [Harmeet]
> Listener-dispactch(handler) is the pattern followed in current code.
It is
> more flexible than server class hierarchy. The missing piece is
confusing
> and repeated configuration of the handler not a problem with the
pattern
> iteself. Most other servers try to separate the listeners from
dispatch
> workers/handlers.
The current code is a listener-dispatch pattern. It is a
listener-dispatch pattern, and would remain so after the changes I
propose.
I don't think you quite understand what a listener-dispatch pattern
implies. There is absolutely no requirement in that pattern (and
certainly it doesn't hold true in generic implementations) that the
listener be generic. In general, the listener is specific to the
particular service being implemented. Usually there is a common
interface that describes the listener-handler (in this case
ConnectionHandlerFactory / ConnectionHandler) but there is certainly no
requirement (nor is it desirable) that either part of the pattern be
generic. This pattern is all about a division of responsibility, not
about the ability to swap in and out different partners. The division
of responsibility is clarified in my proposal, as all the configuration
is moved to the listener and the handler can focus on its purpose -
describing the logic for a particular transaction type (NNTP, SMTP,
etc.).
As I stated before, neither side is generic in the current code base.
The server or listener side inherits from a reasonably heavyweight
AbstractService class - about the same weight as the
AbstractJamesService class, but with fewer features.
> [Harmeet]
> Params/Config need not require revalidation and if they do there will
be
> the
> overhead that you are avoiding by server class hierarchy.
>
Again, this is not correct. You need to validate your config
parameters. You need to do it somewhere. If you load and parse the
parameters in the handler, you do it in the handler. If you load and
parse the parameters in the server class, you do it in the server class.
> [Harmeet]
> Cache the config. Precalculation for handlers, isn't that the only
gain in
> having a server class hierarchy. Maybe that idea can be abstracted and
> used
> with current model.
>
No, this isn't the only gain in having a server class hierarchy. See
this email and the previous one for a discussion of gains. They
include, but aren't limited to, better error handling, clearer logging,
simpler configuration, and simpler code.
Moreover this caching idea you suggest is even worse than the current
code. Consider the situation. Since you object to distinguishing
between the server objects, presumably you're going to have the "first"
handler for the service initialize the configuration and all others will
access it. That's because someone has to initialize the config. If
you've got a generic server with no ability to interpret the content of
the configuration, it has to be the handler. This is a classic server
design anti-pattern. Because what you've done is introduced a mutable
(because the handler has to do the initial parsing and setting to
defaults), shared configuration object. Access to this object will
require a lock on every call, because the handler has to check if the
config is initialized and, if not, initialize it. This becomes a
heavily contested lock. Very expensive, destroys performance.
Now, let's imagine that we admit that the natural place for the
configuration parsing is in the server class. But we still want to
stick with this notion of "generic" arguments passed to the handler.
What's wrong with this? The basic problem with it is that you don't
gain anything over the approach I suggest and you lose type safety. The
server class still needs to know what type of service it represents in
order to parse and validate the configuration parameters. In addition,
if we restrict ourselves to the Avalon configuration rather than some
Properties object, we lose even more. Configuration parameters that
aren't easily represented as Strings become difficult to pass to the
handler. We have to put some String key in place, and give the handler
the Configuration. It pulls out the String, and looks up the non-String
thing. Ugh.
This is simple?
>
> > > This leads to tighter coupling between the
> > > Handlers and the corresponding server classes, but that's simply
> > > recognition of a pre-existing reality. These classes are
extremely
> > > tightly coupled.
> >
> > Server is a listener. Handler contains protocol specific stuff. Why
> would
> > there be a (tight) coupling ?
> > It is a listen-dispatch mechanism. Shouldn't it be as loosely
coupled
> as
> > possible ?
>
> This is a somewhat naïve view of a service architecture. Servers
aren't
> generic. If they were, we'd need only one server class period. But
> servers are different from one another, so we need separate server
> classes. You can see how the servers differ by examining the diffs
for
> the assorted server classes that were submitted with this patch.
>
>
>
> [Harmeet]
> No I am saying listeners are generic. Handlers/Workers are specific. A
mix
> of two makes service and servers.
>
Listeners are not generic. Not even close. They aren't now, they can't
be for the reasons I outlined in my last email, and there's been no
compelling reason presented for them to be generic.
> [Harmeet]
> But a socket listener associated with SMTP handler makes an SMTP
Service.
> That is the current state.
> An incremental and better system would be Socket Listener with Config
> Object
> and Handler makes a Service.
>
> A Bad State would be a server class hierarchy that couples Listener,
> Config
> and Handler.
>
> -------------------------------
I couldn't disagree more with this statement.
It's a typical expression of extensibility at any cost. The trick to
writing extensible code is to pick your extension points. The
Configuration object is generic, so the class itself is not coupled to
the server or the handler. Of course the specific values stored in that
Configuration object ARE tightly coupled to the SMTP server. They have
to be, as they're the values that configure how the SMTP server runs.
The Handler and Listener should be tightly coupled. There is no reason
why an NNTPServer should work with a SMTPHandler. That wouldn't make
any sense. Even in the proposed solution they wouldn't work together -
they'd just fail miserably on each connection because the SMTPHandler
wouldn't have the parameters it needed. The handler and listener are
tightly coupled precisely because they are implementations of a service
- a service that has configuration, server specific details, and a
protocol.
> [Harmeet]
> Port, queus size etc are the only listener concerns.
>
Port, queue, etc.? What's hidden in the etc.?
Trivializing the listener concerns like this is just hiding the issue.
The listener is responsible for socket and connection management, so it
needs to be able to specify the ConnectionManager and socket type. As
the ConnectionManager needs a thread group to invoke a server
connection, it needs a thread group. For certain services there will be
configuration restriction logic related to the socket types (imagine
publishing an HTTPS service with TCP/IP sockets). This all belongs in
the listener. The handler can't deal with any of it, because by the
time the handler is invoked this needs to have been already dealt with.
So the listener has to have a very non-trivial configuration.
> -------------------------------
>
> Second, there are resources provided by the server that depend on the
> configuration. Yes, it's possible to re-read the configuration on a
per
> handler invocation basis. But that's a bad idea for the reasons
> described above.
>
> [Harmeet]
> That is why I am suggesting params or configuration object, cached for
a
> class of handlers.
See above why a param (lose type safety) or configuration object (can
only hold Stringifiable objects) is a bad idea.
> [Harmeet]
> Are you saying Avalon is too complicated. Avalon complexity or user
> friendliness is not a reason to change a fairly standard
listener-dispatch
> model. If there are problems with Phoenix, would it be better to not
use
> it
> ? That is a different topic. Complexity in one part should ideally not
be
> reason a rearchitect another part.
This is just silly. What's being critiqued here as over-complex is a
vast simplification of one of the most difficult aspects of server
design.
Let me be clear - this is one of the best parts of Phoenix. It's
incredibly well designed and well thought out and it takes one of the
most annoying parts of server design (getting all your dependency
checking right) and makes it trivial.
Avalon in general, and Phoenix as a specific container is based around
the idea of component oriented programming. Each of the services we
define - the listener classes - comprises a component. It's a component
because it can be uniquely defined by a name, provides one or more
interfaces, exists for the life of the container, and can be looked up
by the other components running in the container. These characteristics
are all necessary to establish a dependency chain and ensure that each
component can both declare what it needs to function and be evaluated as
part of a dependency chain.
The handler instances cannot be components. There are some arbitrary
number of them, they don't have unique names, they can't be accessed by
other components, and they have very limited lifetimes. Thus they don't
meet the minimum requirements.
Avalon is great, and Phoenix is a great container. Chucking it is
really out of the question. This is not a fault in the Avalon
framework, but rather a fault in your proposal. Your proposal violates
basic principles of component oriented design.
> -------------------------------
>
> [Harmeet]
> You can have different services. POP3 and POP3 Secure. Doesn't that
achive
> what you are describing. If you POP3 is a service, POP3 (plain) and
POP3
> Secure are 2 instances of it. It depends on what you mean by a
service.
> Effectiely if you want different listereners/threadgroups for a
protocol,
> that exists.
No, it doesn't. You are misunderstanding the problem. The ability to
configure different socket types and different thread groups is not
present in the current code. Period. The configuration doesn't look
for it. All it can do is "plain" sockets vs. "ssl". That's it. And
the thread pool is always the default thread pool. There is no way to
configure the server to use different thread pools for different
services.
> -------------------------------
>
> As far as the ability to handle multiple socket types, that wasn'tb
> there. The socket type was one of two hard coded strings, and the SSL
> selection was Boolean. So if you wanted to have two different SSL
> socket types, one for use by the NNTP server and another for use by
the
> SMTP server (a very common configuration), then you would have to run
> two separate servers. Very bad.
>
> [Harmeet]
> It is pretty standard. Take a look at tomcat. They do the same thing.
>
No, it isn't. Almost nobody writes production servers that handle SSL
for multiple services without providing the ability to have multiple SSL
connection types.
This is also a misunderstanding of the standard recommended production
deployment of Tomcat.
Tomcat is a reference implementation of the Servlet/JSP specs. As such
it was an explicit decision to focus on the Servlet/JSP processing in
Tomcat. The network interface was left uber-simple on purpose. The
static page delivery wasn't tuned. Why? Because the developers wanted
to focus on the core functionality.
And that's why the recommended deployment of Tomcat is in a reverse
proxy environment. Apache in front to handle complex connection
management and configuration (and it certainly does allow multiple SSL
connection types) and to handle static page delivery. And then Apache
proxies Servlet and JSP requests to the Tomcat server. That allows the
production environment to take advantage of Apache's strong connection
management.
This is a recognized weakness of the Tomcat implementation. That's why
there is always a lot of discussion about embedding Tomcat in Avalon
containers, etc. on the Avalon mailing lists. Because a container that
implements the Avalon framework would provide all of the complex
connection management features that the Tomcat implementation lacks and
allow you to run more complex systems in non-reverse proxy environments.
I don't see any reason to hobble ourselves with an unnecessary flaw.
> [Harmeet]
> Basically if n lines have been written out, observer resets the timer.
> rather than only after all the lines have been written out.
>
And this won't work. Why? Because it ignores the distinction between
observer and observable as well as the conditions under which we want a
reset. The purpose of the reset here is to prevent transaction hangs,
as much from server processing as from client processing. So the
primary trigger reset is not the amount of data written, but rather the
trigger that occurs every time a command is processed. A command being
processed indicates that the transaction is proceeding. As this
information is not available to the stream (it has no idea when a
command has completed), the stream cannot be the observable in this
situation. The stream data is crucial for commands that potentially
involve large transfers of data, so the handler can't be the observable.
So the pattern doesn't fit.
> [Harmeet]
> The observer-observable is a clean and standard pattern way. It allows
an
> observer to monitor and decide on timeout reset.
>
It is a clean and standard pattern. It's just the wrong one for this
situation. See above.
--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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
> > Basically this code is designed to address a bunch of
> > memory/robustness/scalability issues. These issues were, at least
in
> > part, due to problems with the Cornerstone TimeScheduler.
Dependence on
> > the global TimeScheduler, previously used to handle idle timeouts,
has
> > been removed. Instead, James now uses the classes of the new
> > org.apache.james.util.Watchdog package to provide this
functionality.
>
> I have been using a scheduler implementation for 1+ year without any
> issues.
> If you don't trust a scheduler implementation why not replace that
with
> another one ? At least one has already been posted.
> One of the advantages of Avalon is that you can replace an impl. I
thought
> the scheduler is a good abstration and widely used.
>
> What are the advantages of picking another abstraction to solve the
same
> problem ?
Because the scheduler is the wrong abstraction. This is not a scheduler
problem - it's a timeout. A timeout is far simpler than a scheduler.
And that's the core issue.
[Harmeet]
One time timer task rather than repeated timer tasks is the same thing as
Watchdog timeout. It is property of implementation.
-------------------------------
A scheduler is required to keep track of a number of possible events,
each of which may trigger at an arbitrary time. It is centralized, and
has complex synchronization issues when large numbers of events are
added or deleted frequently. Schedulers are generally intended for
events that are long lived and are expected to actually occur.
[Harmeet]
Depends on how the scheduler is used. Centralized-complex etc. are
properties of implementation. Schedulers can work like one-time alarm
clocks.
-------------------------------
A timeout is the opposite problem. The connections and the
corresponding handlers are extremely short lived - on the average they
live for milliseconds. Under load hundreds of events will be added or
deleted per second. In the overwhelming majority of cases the timeout
should not trigger. It is designed to handle the exceptional case, not
the general one.
[Harmeet]
If you have an object that monitors timeout on lots of events, it would have
the same property and load. It may be called a watchdog or a scheduler.
You can have a scheduler implementation with the same properties as
watchdog.
-------------------------------
Thus a timeout should be cheap to invoke (lightweight, involving just a
couple of small objects and drawing from an efficient thread pool) and
it should be optimized for the general case (the timeout thread waits
for the timeout period, rather than consuming resources by context
switches and unnecessary loops). There should be minimal contention
between different handlers, as their timeout events are independent. So
rather than using a globally shared scheduler resource with frequent
invocations, you grab a thread from a shared pool and then face no
potential contention with other handlers for the life of the watchdog.
The scheduler model fails on all of the above.
[Harmeet]
lightweight-effiicient etc. are properties of implementation. The scheduler
abstraction cannot enforce or avoid any of these. The point is that it may
be better to change the scheduler implementation and use(one scheduler per
class of handlers) than to invent another mechanism. If another mechanism is
needed, can it fit inside the same abstraction ?
To me scheduler/Watchdog and JDK Timer Task are very similar. The difference
is mostly in the implementation.
If you have one scheduler implemented for a class of handlers, that would do
the trick equally well.
If you reset a scheduler before it is fired, the trigger would not occur.
-------------------------------
> >
> > In addition, there was substantial rearchitecting of the service
> > structure. James services are now subclasses of the new
> > AbstractJamesService class. This class serves to unify the common
> > functionality of the services. BaseConnectionHandler is removed,
> > because the functionality once provided by that class has been moved
> > into AbstractJamesService. The Configurable interface (and the
>
> Earlier the intent was to have thin server and move towards a base
handler
> class. I don't see the benefit in rearchitecture. Did the current
system
> not
> meet a requirement ?
> In the past there has been conversation about removing derived Servers
> classes and making do with handlers.
There were a number of very serious problems with the handler heavy
approach.
First, there was the simple expense. Server objects are created once
per service, handler objects are created, fed through the lifecycle, and
destroyed multiple times a second. Thus it is advantageous to move as
much of the lifecycle expense into the server code.
Second, there's a bizarre division of configuration information. Not
only was the configuration information divided between handler and
server in some bizarre fashion (why does helloName belong to the handler
and not to the server?), but common configuration between the servers
was duplicated (and may I add, duplicated incorrectly, leading to yet
another long standing NNTP bug). The addition of the
AbstractJamesService class correctly handled that common server
configuration (extracting socket type, port, enabled, etc. in a uniform
fashion) while allowing custom per-server type configuration. The
BaseConnectionHandler class attempted to encapsulate some of that common
behavior, but by the very fact it was a handler class rather than a
server class it couldn't encapsulate the port #, socket type, connection
type, and thread pool used for connection. Those have to be in the
class that provides the service. So why should the helloName and the
timeout be in the BaseConnectionHandler as opposed to being in the
aforementioned server class?
[Harmeet]
A Config object can take care of this. Handlers don't need to
expose themselves to lifecycle. What you are describing is configuration per
handler and as you pointed out that is not needed. You are also saying
configuration is spread out, that can be centralized too in a config object.
-------------------------------
Third, the sheer conceptual weight. For the reasons described above,
the BaseConnectionHandler class cannot be the end-all/be-all class.
Thus, why is it necessary? The answer - it isn't. It just further
confuses the architecture. And it perpetuates the idea that you can
mate any ConnectionHandler to any service. As that idea is false (see
below), it just serves as a point of confusion in the code base.
[Harmeet]
Listener-dispactch(handler) is the pattern followed in current code. It is
more flexible than server class hierarchy. The missing piece is confusing
and repeated configuration of the handler not a problem with the pattern
iteself. Most other servers try to separate the listeners from dispatch
workers/handlers.
-------------------------------
> > corresponding behavior) has been removed from all the
ConnectionHandler
> > children, in recognition that configuration is really on a
per-server,
> > not per-handler, basis.
>
> A far simpler solution would have been to have a single params object
per
> handler or optimize configuration code. This would have delivered the
> speed
> gain without a new architecture. Each philosophy would have holes and
I
> don't see big enough of a hole in the hander mechanism to require a
redo.
No, that wouldn't work. The solution described is not simple at all.
Adding a "params" object would either require re-validation and
defaulting in each handler invocation (resulting in the original
expense), or would basically be a non-type safe (and hence inferior)
version of the changes already introduced. The servers are different
(and the handlers are not interchangeable) for precisely this reason.
Different handlers require different param values/services.
[Harmeet]
Params/Config need not require revalidation and if they do there will be the
overhead that you are avoiding by server class hierarchy.
-------------------------------
As for optimizing the configuration code, there is nothing to optimize.
The pre-existing Configuration code was basically as optimized as
possible. It was just getting invoked hundreds of times per second
rather than once per the lifetime of the server. There's no way to beat
that math.
[Harmeet]
Cache the config. Precalculation for handlers, isn't that the only gain in
having a server class hierarchy. Maybe that idea can be abstracted and used
with current model.
-------------------------------
> > This leads to tighter coupling between the
> > Handlers and the corresponding server classes, but that's simply
> > recognition of a pre-existing reality. These classes are extremely
> > tightly coupled.
>
> Server is a listener. Handler contains protocol specific stuff. Why
would
> there be a (tight) coupling ?
> It is a listen-dispatch mechanism. Shouldn't it be as loosely coupled
as
> possible ?
This is a somewhat naïve view of a service architecture. Servers aren't
generic. If they were, we'd need only one server class period. But
servers are different from one another, so we need separate server
classes. You can see how the servers differ by examining the diffs for
the assorted server classes that were submitted with this patch.
[Harmeet]
No I am saying listeners are generic. Handlers/Workers are specific. A mix
of two makes service and servers.
-------------------------------
In addition, a service is not simply the protocol. Specifically, a
handler that implements the SMTP protocol does not an SMTP service make.
There are two additional constraints.
[Harmeet]
But a socket listener associated with SMTP handler makes an SMTP Service.
That is the current state.
An incremental and better system would be Socket Listener with Config Object
and Handler makes a Service.
A Bad State would be a server class hierarchy that couples Listener, Config
and Handler.
-------------------------------
First, there are service specific details that are not described by the
protocol. These generally must be accessed and invoked before any
handler is created. The obvious example is the default port for the
service. You need the default port when you're getting the config to
open the socket.
[Harmeet]
Port, queus size etc are the only listener concerns.
-------------------------------
Second, there are resources provided by the server that depend on the
configuration. Yes, it's possible to re-read the configuration on a per
handler invocation basis. But that's a bad idea for the reasons
described above.
[Harmeet]
That is why I am suggesting params or configuration object, cached for a
class of handlers.
-------------------------------
Also, the very design of the Phoenix server makes this complicated. Try
changing the handler so that it has a new dependency. You'll find that
you need to alter the .xinfo for the server class as well as its
assembly descriptor. That's part of what I mean by a tight coupling.
Phoenix knows about, loads, and determines dependencies from the server
class (which is a Phoenix block). The handler class is unknown to the
underlying server. It can't be a block, because it's invocation and
lifecycle is not controlled by Phoenix. So it can't publish
dependencies to Phoenix.
[Harmeet]
Are you saying Avalon is too complicated. Avalon complexity or user
friendliness is not a reason to change a fairly standard listener-dispatch
model. If there are problems with Phoenix, would it be better to not use it
? That is a different topic. Complexity in one part should ideally not be
reason a rearchitect another part.
-------------------------------
> >
> > The config.xml entries were not modified to remove the
> > <handler></handler> tags, to maximize backwards compatibility.
These
> > tags don't really make sense, even before this set of changes, and
> > should be removed in a future version.
> >
> > Some enhancements, including the ability to specify a thread group
for
> > use by a particular service and the ability to do more fine-grained
> > connection management (i.e. to have more than one set of SSL
> > connections, each for use by different services) have been added.
These
> > will be further documented, but are basically encapsulated in the
> > AbstractJamesService class.
>
> I thought the capability to create n listeners for each service
already
> existed.
No, it doesn't. And never did. There is no capacity, either in the
implemented services or their abstract base class, to have multiple
handlers for a given service. Even if the code was there, the
configuration and implementation would preclude it as there is only a
single port entry for each service (so you can't distinguish between
handlers based on port) and the connection handler is created and
invoked by the connection manager sans parameters.
[Harmeet]
You can have different services. POP3 and POP3 Secure. Doesn't that achive
what you are describing. If you POP3 is a service, POP3 (plain) and POP3
Secure are 2 instances of it. It depends on what you mean by a service.
Effectiely if you want different listereners/threadgroups for a protocol,
that exists.
-------------------------------
As far as the ability to handle multiple socket types, that wasn't
there. The socket type was one of two hard coded strings, and the SSL
selection was Boolean. So if you wanted to have two different SSL
socket types, one for use by the NNTP server and another for use by the
SMTP server (a very common configuration), then you would have to run
two separate servers. Very bad.
[Harmeet]
It is pretty standard. Take a look at tomcat. They do the same thing.
-------------------------------
> >
> > There was some change to the behavior of the SMTP server -
specifically,
> > the number of bytes required to reset the idle timer is now measured
> > against the total number of bytes read off the socket, not simply
those
> > read in the DATA command. This substantially neatens the code and
in
> > real life scenarios doesn't make a whole lot of difference.
> >
> > There is also a partial redress of bug #13316 in the NNTP code,
which
> > will reset the watchdog every 100 headers it transmits.
>
>
> observer-observable model would be a good fix.
I don't think so. This is not really a problem of observer/observable.
I mean do you want the handler to register itself as an observer of the
stream? The stream contains the information of how many bytes it has
transmitted. The handler knows how many headers it has written. The
handler knows how long its idle timeout is. The handler knows when it
has written a complete command. The handler has the socket which is to
be closed on timeout. So which is the observer and which is the
observable? Both the handler and stream have data that would be
associated with the observable (i.e. how long is the timeout and when to
reset).
[Harmeet]
Basically if n lines have been written out, observer resets the timer.
rather than only after all the lines have been written out.
-------------------------------
The problem here is really architectural - the NNTP server should solve
this problem in the same way the POP3 and SMTP servers solve the
problem. But I really don't want to spend any more time doing NNTP
reworking. The partial redress is just a quick hack because there is no
Writer that handles counting bytes and timing out.
[Harmeet]
The observer-observable is a clean and standard pattern way. It allows an
observer to monitor and decide on timeout reset.
-------------------------------
> >
> > I've done basic testing on this code, and I am now doing further
load
> > testing. I will continue to do testing before submission.
> >
> > The code is attached as a set of diffs, and a collection of newly
added
> > files.
> >
> > As always, comments, critiques, and questions are welcome.
>
> I don't follow the need for a new scheduler abstraction or re design
of
> server-handler interaction. Maybe a bit of pro-con or a discussion on
> different options and what makes one better than other would help.
See the above.
--
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
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Harmeet,
> > Basically this code is designed to address a bunch of
> > memory/robustness/scalability issues. These issues were, at least
> > in part, due to problems with the Cornerstone TimeScheduler.
> > Dependence on the global TimeScheduler, previously used to handle
> > idle timeouts, has been removed. Instead, James now uses the
> > classes of the new org.apache.james.util.Watchdog package to provide
> > this functionality.
>
> I have been using a scheduler implementation for 1+ year without any
> issues. If you don't trust a scheduler implementation why not replace
> that with another one ? At least one has already been posted.
> One of the advantages of Avalon is that you can replace an impl. I
thought
> the scheduler is a good abstration and widely used.
>
> What are the advantages of picking another abstraction to solve the
> same problem ?
Because the scheduler is the wrong abstraction. This is not a scheduler
problem - it's a timeout. A timeout is far simpler than a scheduler.
And that's the core issue.
A scheduler is required to keep track of a number of possible events,
each of which may trigger at an arbitrary time. It is centralized, and
has complex synchronization issues when large numbers of events are
added or deleted frequently. Schedulers are generally intended for
events that are long lived and are expected to actually occur.
A timeout is the opposite problem. The connections and the
corresponding handlers are extremely short lived - on the average they
live for milliseconds. Under load hundreds of events will be added or
deleted per second. In the overwhelming majority of cases the timeout
should not trigger. It is designed to handle the exceptional case, not
the general one.
Thus a timeout should be cheap to invoke (lightweight, involving just a
couple of small objects and drawing from an efficient thread pool) and
it should be optimized for the general case (the timeout thread waits
for the timeout period, rather than consuming resources by context
switches and unnecessary loops). There should be minimal contention
between different handlers, as their timeout events are independent. So
rather than using a globally shared scheduler resource with frequent
invocations, you grab a thread from a shared pool and then face no
potential contention with other handlers for the life of the watchdog.
The scheduler model fails on all of the above.
> >
> > In addition, there was substantial rearchitecting of the service
> > structure. James services are now subclasses of the new
> > AbstractJamesService class. This class serves to unify the common
> > functionality of the services. BaseConnectionHandler is removed,
> > because the functionality once provided by that class has been moved
> > into AbstractJamesService. The Configurable interface (and the
>
> Earlier the intent was to have thin server and move towards a base
> handler class. I don't see the benefit in rearchitecture. Did the
> current system not meet a requirement ?
> In the past there has been conversation about removing derived Servers
> classes and making do with handlers.
There were a number of very serious problems with the handler heavy
approach.
First, there was the simple expense. Server objects are created once
per service, handler objects are created, fed through the lifecycle, and
destroyed multiple times a second. Thus it is advantageous to move as
much of the lifecycle expense into the server code.
Second, there's a bizarre division of configuration information. Not
only was the configuration information divided between handler and
server in some bizarre fashion (why does helloName belong to the handler
and not to the server?), but common configuration between the servers
was duplicated (and may I add, duplicated incorrectly, leading to yet
another long standing NNTP bug). The addition of the
AbstractJamesService class correctly handled that common server
configuration (extracting socket type, port, enabled, etc. in a uniform
fashion) while allowing custom per-server type configuration. The
BaseConnectionHandler class attempted to encapsulate some of that common
behavior, but by the very fact it was a handler class rather than a
server class it couldn't encapsulate the port #, socket type, connection
type, and thread pool used for connection. Those have to be in the
class that provides the service. So why should the helloName and the
timeout be in the BaseConnectionHandler as opposed to being in the
aforementioned server class?
Third, the sheer conceptual weight. For the reasons described above,
the BaseConnectionHandler class cannot be the end-all/be-all class.
Thus, why is it necessary? The answer - it isn't. It just further
confuses the architecture. And it perpetuates the idea that you can
mate any ConnectionHandler to any service. As that idea is false (see
below), it just serves as a point of confusion in the code base.
> > corresponding behavior) has been removed from all the
> > ConnectionHandler children, in recognition that configuration is
> > really on a per-server, not per-handler, basis.
>
> A far simpler solution would have been to have a single params object
> per handler or optimize configuration code. This would have delivered
> the speed gain without a new architecture. Each philosophy would have
> holes and I don't see big enough of a hole in the hander mechanism to
> require a redo.
No, that wouldnt work. The solution described is not simple at all.
Adding a "params" object would either require re-validation and
defaulting in each handler invocation (resulting in the original
expense), or would basically be a non-type safe (and hence inferior)
version of the changes already introduced. The servers are different
(and the handlers are not interchangeable) for precisely this reason.
Different handlers require different param values/services.
As for optimizing the configuration code, there is nothing to optimize.
The pre-existing Configuration code was basically as optimized as
possible. It was just getting invoked hundreds of times per second
rather than once per the lifetime of the server. There's no way to beat
that math.
> > This leads to tighter coupling between the
> > Handlers and the corresponding server classes, but that's simply
> > recognition of a pre-existing reality. These classes are extremely
> > tightly coupled.
>
> Server is a listener. Handler contains protocol specific stuff. Why
> would there be a (tight) coupling ? It is a listen-dispatch mechanism.
> Shouldn't it be as loosely coupled as possible ?
This is a somewhat naïve view of a service architecture. Servers aren't
generic. If they were, we'd need only one server class period. But
servers are different from one another, so we need separate server
classes. You can see how the servers differ by examining the diffs for
the assorted server classes that were submitted with this patch.
In addition, a service is not simply the protocol. Specifically, a
handler that implements the SMTP protocol does not an SMTP service make.
There are two additional constraints.
First, there are service specific details that are not described by the
protocol. These generally must be accessed and invoked before any
handler is created. The obvious example is the default port for the
service. You need the default port when you're getting the config to
open the socket.
Second, there are resources provided by the server that depend on the
configuration. Yes, it's possible to re-read the configuration on a per
handler invocation basis. But that's a bad idea for the reasons
described above.
Also, the very design of the Phoenix server makes this complicated. Try
changing the handler so that it has a new dependency. You'll find that
you need to alter the .xinfo for the server class as well as its
assembly descriptor. That's part of what I mean by a tight coupling.
Phoenix knows about, loads, and determines dependencies from the server
class (which is a Phoenix block). The handler class is unknown to the
underlying server. It can't be a block, because it's invocation and
lifecycle is not controlled by Phoenix. So it can't publish
dependencies to Phoenix.
> >
> > The config.xml entries were not modified to remove the
> > <handler></handler> tags, to maximize backwards compatibility.
> > These tags don't really make sense, even before this set of changes,
> > and should be removed in a future version.
> >
> > Some enhancements, including the ability to specify a thread group
> > for use by a particular service and the ability to do more
> > fine-grained connection management (i.e. to have more than one set
> > of SSL connections, each for use by different services) have been
> > added. These will be further documented, but are basically
> > encapsulated in the AbstractJamesService class.
>
> I thought the capability to create n listeners for each service
> already existed.
No, it doesn't. And never did. There is no capacity, either in the
implemented services or their abstract base class, to have multiple
handlers for a given service. Even if the code was there, the
configuration and implementation would preclude it as there is only a
single port entry for each service (so you can't distinguish between
handlers based on port) and the connection handler is created and
invoked by the connection manager sans parameters.
As far as the ability to handle multiple socket types, that wasn't
there. The socket type was one of two hard coded strings, and the SSL
selection was Boolean. So if you wanted to have two different SSL
socket types, one for use by the NNTP server and another for use by the
SMTP server (a very common configuration), then you would have to run
two separate servers. Very bad.
> >
> > There was some change to the behavior of the SMTP server -
> > specifically, the number of bytes required to reset the idle timer
> > is now measured against the total number of bytes read off the
> > socket, not simply those read in the DATA command. This
> > substantially neatens the code and in real life scenarios doesn't
> > make a whole lot of difference.
> >
> > There is also a partial redress of bug #13316 in the NNTP code,
> > which will reset the watchdog every 100 headers it transmits.
>
>
> observer-observable model would be a good fix.
I don't think so. This is not really a problem of observer/observable.
I mean do you want the handler to register itself as an observer of the
stream? The stream contains the information of how many bytes it has
transmitted. The handler knows how many headers it has written. The
handler knows how long its idle timeout is. The handler knows when it
has written a complete command. The handler has the socket which is to
be closed on timeout. So which is the observer and which is the
observable? Both the handler and stream have data that would be
associated with the observable (i.e. how long is the timeout and when to
reset).
The problem here is really architectural - the NNTP server should solve
this problem in the same way the POP3 and SMTP servers solve the
problem. But I really don't want to spend any more time doing NNTP
reworking. The partial redress is just a quick hack because there is no
Writer that handles counting bytes and timing out.
> >
> > I've done basic testing on this code, and I am now doing further
> > load testing. I will continue to do testing before submission.
> >
> > The code is attached as a set of diffs, and a collection of newly
> > added files.
> >
> > As always, comments, critiques, and questions are welcome.
>
> I don't follow the need for a new scheduler abstraction or re design
> of server-handler interaction. Maybe a bit of pro-con or a discussion
> on different options and what makes one better than other would help.
See the above.
--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
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > These issues were, at least in part, due to problems with the
> > Cornerstone TimeScheduler. Dependence on the global
> > TimeScheduler, previously used to handle idle timeouts, has
> > been removed. Instead, James now uses the classes of the new
> > org.apache.james.util.Watchdog package to provide this functionality.
> I have been using a scheduler implementation for 1+ year without any
issues.
> If you don't trust a scheduler implementation why not replace that with
> another one?
> What are the advantages of picking another abstraction to solve the same
> problem ?
As I recall, this was discussed by a half dozen or more folks over several
discussion cycles since late Spring. The problem is that a Scheduler has a
lot more responsibility and overhead than a lightweight timeout watchdog. I
had looked at a lightweight Scheduler implementation a month or two ago, but
the interface doesn't lend itself to a truely lightweight implementation.
For example, if I recall correctly, the interface takes a String that
requires a lookup.
> In the past there has been conversation about removing derived Servers
> classes and making do with handlers.
I suppose that one of the problems is that without a good architecture
document, if developers have undocumented intents and they aren't around to
discuss them, things can shift. Even if there is an architecture document,
architectures can change (as I mentioned in an earlier message).
It might be elegant to have a single generic Server class that dispatches
incoming connections on a given port to handlers for that port. However, as
I see it, there is server behavior that is not part of the protocol handler,
e.g., server configuration, which I'm not convinced is entirely generic.
Therefore, although the subclassing may be minimal, there is a case for some
server related code that is not part of the handler code, which should be
related to implementing the protocol.
Regardless, handlers should be pooled so that performance is more optimal
than reconfiguring them for each connection. And I agree that configuration
is per server, not per connection. Mind you, I'd like to be able to setup
multiple instances of a single server type, but with different configured
properties, so long as they were listening different ports and/or addresses.
> I don't follow the need for a new scheduler abstraction or re design of
> server-handler interaction.
I don't think that the Scheduler interface is amenable to a truely
lightweight implementation, which is necessary for a watchdog that could be
invoked 1000s of times per second. I'm more than willing to bat around
ideas related to server-handler interaction, which I do think should be
documented as a clear, reusabe, scalable, architecture. What do you see as
the abstract behavior for a server? For a handler? As I said, I believe
that there are some server behaviors that don't share implementation, but
perhaps you have other ideas.
--- 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
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
>
> All,
>
> This code is being posted almost a week after I'd originally intended to
> post it. For that I can only apologize - I got held up by a bunch of
> things.
>
> Basically this code is designed to address a bunch of
> memory/robustness/scalability issues. These issues were, at least in
> part, due to problems with the Cornerstone TimeScheduler. Dependence on
> the global TimeScheduler, previously used to handle idle timeouts, has
> been removed. Instead, James now uses the classes of the new
> org.apache.james.util.Watchdog package to provide this functionality.
I have been using a scheduler implementation for 1+ year without any issues.
If you don't trust a scheduler implementation why not replace that with
another one ? At least one has already been posted.
One of the advantages of Avalon is that you can replace an impl. I thought
the scheduler is a good abstration and widely used.
What are the advantages of picking another abstraction to solve the same
problem ?
>
> In addition, there was substantial rearchitecting of the service
> structure. James services are now subclasses of the new
> AbstractJamesService class. This class serves to unify the common
> functionality of the services. BaseConnectionHandler is removed,
> because the functionality once provided by that class has been moved
> into AbstractJamesService. The Configurable interface (and the
Earlier the intent was to have thin server and move towards a base handler
class. I don't see the benefit in rearchitecture. Did the current system not
meet a requirement ?
In the past there has been conversation about removing derived Servers
classes and making do with handlers.
> corresponding behavior) has been removed from all the ConnectionHandler
> children, in recognition that configuration is really on a per-server,
> not per-handler, basis.
A far simpler solution would have been to have a single params object per
handler or optimize configuration code. This would have delivered the speed
gain without a new architecture. Each philosophy would have holes and I
don't see big enough of a hole in the hander mechanism to require a redo.
> This leads to tighter coupling between the
> Handlers and the corresponding server classes, but that's simply
> recognition of a pre-existing reality. These classes are extremely
> tightly coupled.
Server is a listener. Handler contains protocol specific stuff. Why would
there be a (tight) coupling ?
It is a listen-dispatch mechanism. Shouldn't it be as loosely coupled as
possible ?
>
> The config.xml entries were not modified to remove the
> <handler></handler> tags, to maximize backwards compatibility. These
> tags don't really make sense, even before this set of changes, and
> should be removed in a future version.
>
> Some enhancements, including the ability to specify a thread group for
> use by a particular service and the ability to do more fine-grained
> connection management (i.e. to have more than one set of SSL
> connections, each for use by different services) have been added. These
> will be further documented, but are basically encapsulated in the
> AbstractJamesService class.
I thought the capability to create n listeners for each service already
existed.
>
> There was some change to the behavior of the SMTP server - specifically,
> the number of bytes required to reset the idle timer is now measured
> against the total number of bytes read off the socket, not simply those
> read in the DATA command. This substantially neatens the code and in
> real life scenarios doesn't make a whole lot of difference.
>
> There is also a partial redress of bug #13316 in the NNTP code, which
> will reset the watchdog every 100 headers it transmits.
observer-observable model would be a good fix.
>
> I've done basic testing on this code, and I am now doing further load
> testing. I will continue to do testing before submission.
>
> The code is attached as a set of diffs, and a collection of newly added
> files.
>
> As always, comments, critiques, and questions are welcome.
I don't follow the need for a new scheduler abstraction or re design of
server-handler interaction. Maybe a bit of pro-con or a discussion on
different options and what makes one better than other would help.
thanks,
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>