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 Robert Burrell Donkin <ro...@gmail.com> on 2008/12/27 11:17:45 UTC
[server] Management
i'm starting to get irratated by management on trunk. it's preventing
my system booting on my main system (1.6 with JMX on) after upgrading
and debugging is a PITA. i understand the restrictions that the code
was developer under but maybe it's time to take a fresh look and pick
some different trade offs.
RemoteManager is coupled to just about everything in the system. JMX
introduces a huge number of interfaces. phoenix insists on management
services. taken together these introduce a large number of finely
grained optional management interfaces. this increases code
complixity. it's also fragile. whether an installation requires a
service or not, it's management interface must be presented. this adds
up to a major maintenance problem.
here's my suggested principles:
1. services should manage themselves
2. RemoteManager should discover management methods by dynamic
inspection of services
3. services should be dynamically registered and unregistered with
RemoteManager by a listener
4. management should be unified (any method available to JMX should be
available to RemoteManager and vice-versa)
5. management interfaces should be replaced by annotations
opinions? alternatives? objections?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server] Management
Posted by Bernd Fondermann <be...@googlemail.com>.
+1, sounds good.
On Fri, Jan 2, 2009 at 13:23, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Jan 1, 2009 at 3:33 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On 2008-12-28, Robert Burrell Donkin <ro...@gmail.com> wrote:
>>> On Sun, Dec 28, 2008 at 5:17 AM, David Jencks <da...@yahoo.com> wrote:
>>> >
>>> > On Dec 27, 2008, at 2:17 AM, Robert Burrell Donkin wrote:
>>> >
>>> >> i'm starting to get irratated by management on trunk. it's preventing
>>> >> my system booting on my main system (1.6 with JMX on) after upgrading
>>> >> and debugging is a PITA. i understand the restrictions that the code
>>> >> was developer under but maybe it's time to take a fresh look and pick
>>> >> some different trade offs.
>>
>> I'm not aware of JMX migration issues from 1.5 to 1.6. There are
>> issues in using Phoenix + JMX in Java 1.5+, though.
>>
>> What are your problems?
>
> it turned out to be an ordering issue: i needed to ensure that the JMX
> exposed methods were safe to call before initialisation by the
> container. in general, it would be best not to enable any management
> interfaces (JMX or CLI) before a component is initialised by the
> container.
>
>>> >> RemoteManager is coupled to just about everything in the system.
>>
>> This is the foundational problem and it is bad. And the subject lines
>> suggests this.
>
> yes
>
>>> JMX
>>> >> introduces a huge number of interfaces. phoenix insists on management
>>> >> services. taken together these introduce a large number of finely
>>> >> grained optional management interfaces. this increases code
>>> >> complixity. it's also fragile. whether an installation requires a
>>> >> service or not, it's management interface must be presented. this adds
>>> >> up to a major maintenance problem.
>>
>> I thought that management features should be independent of the type
>> of console you use to access it (RM/telnet vs. JMX console). If this
>> could be achieved with less interfaces, great. But defining a contract
>> for implementing a console seemed neccessary to align management
>> features along all console types.
>
> my argument is simply about the type of contract. IMHO a discovery
> based contract would be better than one based on shared administration
> interfaces.
>
>>> >> here's my suggested principles:
>>> >>
>>> >> 1. services should manage themselves
>>> >> 2. RemoteManager should discover management methods by dynamic
>>> >> inspection of services
>>> >> 3. services should be dynamically registered and unregistered with
>>> >> RemoteManager by a listener
>>
>> 1-3: +1
>>
>>> >> 4. management should be unified (any method available to JMX should be
>>> >> available to RemoteManager and vice-versa)
>>
>> Mmh. While this seems to be a good thing naivly, it might be
>> cumbersome or even impossible to apply what's appropriate as a JMX
>> function in a command line interface. Just think of JMX's notification
>> listeners. But in general: +1
>
> true
>
> different administrative interfaces may well have different
> capabilities and some functions may only be available through some
> interfaces. i think it would be reasonable to unify and reuse the
> administration objects.
>
>>> >> 5. management interfaces should be replaced by annotations
>>
>> Ok. But keep in mind that some JMX beans are created dynamically per
>> instance (mailet, matcher) instead of per class. And they may as well
>> change over time, if we introduce reconfiguration of sorts.
>
> yes
>
>> I don't know, this is just an idea... but as JMX is broken in Phoenix
>> on 1.5+ anyway we could actually try to remove JMX specifics
>> altogether and use Spring's decorational approach to JMX. This would
>> be an experiment, though. The gain would be that we would get rid of
>> JMX in James core.
>
> sounds good :-)
>
> using POJOs for management appeals to me. they could be packaged
> together with the implementations they instrument. remote manager
> could use reflection (following the spring rules) to dynamically
> discover the operations available on each management POJO. remote
> manager would still need to discover which POJOs are available. for
> phoenix, i suggest using a marker annotation (on the service
> implementation) and reflection in a listener. for example:
>
> @Admin
> public XYZManagement createXYZManagement()...
>
> each service implementation would then be responsible for creating
> it's own management interface allowing each to vary with the
> implementation.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server] Management
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jan 1, 2009 at 3:33 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On 2008-12-28, Robert Burrell Donkin <ro...@gmail.com> wrote:
>> On Sun, Dec 28, 2008 at 5:17 AM, David Jencks <da...@yahoo.com> wrote:
>> >
>> > On Dec 27, 2008, at 2:17 AM, Robert Burrell Donkin wrote:
>> >
>> >> i'm starting to get irratated by management on trunk. it's preventing
>> >> my system booting on my main system (1.6 with JMX on) after upgrading
>> >> and debugging is a PITA. i understand the restrictions that the code
>> >> was developer under but maybe it's time to take a fresh look and pick
>> >> some different trade offs.
>
> I'm not aware of JMX migration issues from 1.5 to 1.6. There are
> issues in using Phoenix + JMX in Java 1.5+, though.
>
> What are your problems?
it turned out to be an ordering issue: i needed to ensure that the JMX
exposed methods were safe to call before initialisation by the
container. in general, it would be best not to enable any management
interfaces (JMX or CLI) before a component is initialised by the
container.
>> >> RemoteManager is coupled to just about everything in the system.
>
> This is the foundational problem and it is bad. And the subject lines
> suggests this.
yes
>> JMX
>> >> introduces a huge number of interfaces. phoenix insists on management
>> >> services. taken together these introduce a large number of finely
>> >> grained optional management interfaces. this increases code
>> >> complixity. it's also fragile. whether an installation requires a
>> >> service or not, it's management interface must be presented. this adds
>> >> up to a major maintenance problem.
>
> I thought that management features should be independent of the type
> of console you use to access it (RM/telnet vs. JMX console). If this
> could be achieved with less interfaces, great. But defining a contract
> for implementing a console seemed neccessary to align management
> features along all console types.
my argument is simply about the type of contract. IMHO a discovery
based contract would be better than one based on shared administration
interfaces.
>> >> here's my suggested principles:
>> >>
>> >> 1. services should manage themselves
>> >> 2. RemoteManager should discover management methods by dynamic
>> >> inspection of services
>> >> 3. services should be dynamically registered and unregistered with
>> >> RemoteManager by a listener
>
> 1-3: +1
>
>> >> 4. management should be unified (any method available to JMX should be
>> >> available to RemoteManager and vice-versa)
>
> Mmh. While this seems to be a good thing naivly, it might be
> cumbersome or even impossible to apply what's appropriate as a JMX
> function in a command line interface. Just think of JMX's notification
> listeners. But in general: +1
true
different administrative interfaces may well have different
capabilities and some functions may only be available through some
interfaces. i think it would be reasonable to unify and reuse the
administration objects.
>> >> 5. management interfaces should be replaced by annotations
>
> Ok. But keep in mind that some JMX beans are created dynamically per
> instance (mailet, matcher) instead of per class. And they may as well
> change over time, if we introduce reconfiguration of sorts.
yes
> I don't know, this is just an idea... but as JMX is broken in Phoenix
> on 1.5+ anyway we could actually try to remove JMX specifics
> altogether and use Spring's decorational approach to JMX. This would
> be an experiment, though. The gain would be that we would get rid of
> JMX in James core.
sounds good :-)
using POJOs for management appeals to me. they could be packaged
together with the implementations they instrument. remote manager
could use reflection (following the spring rules) to dynamically
discover the operations available on each management POJO. remote
manager would still need to discover which POJOs are available. for
phoenix, i suggest using a marker annotation (on the service
implementation) and reflection in a listener. for example:
@Admin
public XYZManagement createXYZManagement()...
each service implementation would then be responsible for creating
it's own management interface allowing each to vary with the
implementation.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server] Management
Posted by Bernd Fondermann <be...@googlemail.com>.
On 2008-12-28, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On Sun, Dec 28, 2008 at 5:17 AM, David Jencks <da...@yahoo.com> wrote:
> >
> > On Dec 27, 2008, at 2:17 AM, Robert Burrell Donkin wrote:
> >
> >> i'm starting to get irratated by management on trunk. it's preventing
> >> my system booting on my main system (1.6 with JMX on) after upgrading
> >> and debugging is a PITA. i understand the restrictions that the code
> >> was developer under but maybe it's time to take a fresh look and pick
> >> some different trade offs.
I'm not aware of JMX migration issues from 1.5 to 1.6. There are
issues in using Phoenix + JMX in Java 1.5+, though.
What are your problems?
> >> RemoteManager is coupled to just about everything in the system.
This is the foundational problem and it is bad. And the subject lines
suggests this.
> JMX
> >> introduces a huge number of interfaces. phoenix insists on management
> >> services. taken together these introduce a large number of finely
> >> grained optional management interfaces. this increases code
> >> complixity. it's also fragile. whether an installation requires a
> >> service or not, it's management interface must be presented. this adds
> >> up to a major maintenance problem.
I thought that management features should be independent of the type
of console you use to access it (RM/telnet vs. JMX console). If this
could be achieved with less interfaces, great. But defining a contract
for implementing a console seemed neccessary to align management
features along all console types.
> >>
> >> here's my suggested principles:
> >>
> >> 1. services should manage themselves
> >> 2. RemoteManager should discover management methods by dynamic
> >> inspection of services
> >> 3. services should be dynamically registered and unregistered with
> >> RemoteManager by a listener
1-3: +1
> >> 4. management should be unified (any method available to JMX should be
> >> available to RemoteManager and vice-versa)
Mmh. While this seems to be a good thing naivly, it might be
cumbersome or even impossible to apply what's appropriate as a JMX
function in a command line interface. Just think of JMX's notification
listeners. But in general: +1
> >> 5. management interfaces should be replaced by annotations
Ok. But keep in mind that some JMX beans are created dynamically per
instance (mailet, matcher) instead of per class. And they may as well
change over time, if we introduce reconfiguration of sorts.
I don't know, this is just an idea... but as JMX is broken in Phoenix
on 1.5+ anyway we could actually try to remove JMX specifics
altogether and use Spring's decorational approach to JMX. This would
be an experiment, though. The gain would be that we would get rid of
JMX in James core.
<snip/>
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server] Management
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Dec 28, 2008 at 5:17 AM, David Jencks <da...@yahoo.com> wrote:
>
> On Dec 27, 2008, at 2:17 AM, Robert Burrell Donkin wrote:
>
>> i'm starting to get irratated by management on trunk. it's preventing
>> my system booting on my main system (1.6 with JMX on) after upgrading
>> and debugging is a PITA. i understand the restrictions that the code
>> was developer under but maybe it's time to take a fresh look and pick
>> some different trade offs.
>>
>> RemoteManager is coupled to just about everything in the system. JMX
>> introduces a huge number of interfaces. phoenix insists on management
>> services. taken together these introduce a large number of finely
>> grained optional management interfaces. this increases code
>> complixity. it's also fragile. whether an installation requires a
>> service or not, it's management interface must be presented. this adds
>> up to a major maintenance problem.
>>
>> here's my suggested principles:
>>
>> 1. services should manage themselves
>> 2. RemoteManager should discover management methods by dynamic
>> inspection of services
>> 3. services should be dynamically registered and unregistered with
>> RemoteManager by a listener
>> 4. management should be unified (any method available to JMX should be
>> available to RemoteManager and vice-versa)
>> 5. management interfaces should be replaced by annotations
>>
>> opinions? alternatives? objections?
>
> Offhand this sounds good but I don't actually have a clear idea of what you
> are suggesting. Could you come up with an example of an irritating class
> (possibly a simple fake example) and what it would look like with all the
> changes you are suggesting?
good plan :-)
the spool asynchronously processes mail. let's take spool management
as motivating example 1:
in org.apache.james.management
ProcessorManagementMBean for JMX
ProcessorManagementService for injection
SpoolManagementMBean for JMX
SpoolManagementService for injection
and in org.apache.james.management.impl:
ProcessorManagement JMX administration glue plus JMX only operations
SpoolManagement JMX administration glue plus JMX only operations
RemoteManager service depends on SpoolManagementService and
ProcessorManagementService services. typical usage in RemoteManager
is:
<code>
private boolean doLISTPROCESSORS(String argument) {
String[] processorNames =
theConfigData.getProcessorManagement().getProcessorNames();
helper.writeLoggedResponse("Existing processors: " +
processorNames.length);
for (int i = 0; i < processorNames.length; i++) {
helper.writeLoggedResponse("\t" + processorNames[i]);
}
return true;
}
</code>
i would much rather remove all this complexity. start by moving the
management methods in the service and enabling discovery. for example
(using a hypothetical annotation):
@Management
public String listProcessors()
...
}
services with administration APIs would be registered with
RemoteManager. for example (by injecting a dependency by an
administration interface)
@Resource
setAdministrator(Administrator admin) {
admin.register(this)
}
this is just a motivational example. the effect could also be
accumplished by using a listener in the container.
this complexity makes the code fragile. when running on a JMX enabled
1.6 JVM, it broke James on boot and had to find and fix the problem.
it turned out to be lifecycle related. i found this irratating.
motivating example 2 - BayesianAnalyzer. this trains the Bayes spam
filter used by the Bayes mailet. complex setup as above. the direct
coupling between RemoteManager means that the analyzer service must
always be available and the data sources configured. i find it
irratating that extra services have to be run and configured whether
or or not they will actually be used.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server] Management
Posted by David Jencks <da...@yahoo.com>.
On Dec 27, 2008, at 2:17 AM, Robert Burrell Donkin wrote:
> i'm starting to get irratated by management on trunk. it's preventing
> my system booting on my main system (1.6 with JMX on) after upgrading
> and debugging is a PITA. i understand the restrictions that the code
> was developer under but maybe it's time to take a fresh look and pick
> some different trade offs.
>
> RemoteManager is coupled to just about everything in the system. JMX
> introduces a huge number of interfaces. phoenix insists on management
> services. taken together these introduce a large number of finely
> grained optional management interfaces. this increases code
> complixity. it's also fragile. whether an installation requires a
> service or not, it's management interface must be presented. this adds
> up to a major maintenance problem.
>
> here's my suggested principles:
>
> 1. services should manage themselves
> 2. RemoteManager should discover management methods by dynamic
> inspection of services
> 3. services should be dynamically registered and unregistered with
> RemoteManager by a listener
> 4. management should be unified (any method available to JMX should be
> available to RemoteManager and vice-versa)
> 5. management interfaces should be replaced by annotations
>
> opinions? alternatives? objections?
Offhand this sounds good but I don't actually have a clear idea of
what you are suggesting. Could you come up with an example of an
irritating class (possibly a simple fake example) and what it would
look like with all the changes you are suggesting?
If everyone else knows what you mean feel free to ignore this :-)
thanks
david jencks
>
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org