> 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: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
