james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: [server] Management
Date Thu, 01 Jan 2009 15:33:32 GMT
On 2008-12-28, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
> On Sun, Dec 28, 2008 at 5:17 AM, David Jencks <david_jencks@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.

> >> 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.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message