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 Fri, 02 Jan 2009 19:54:35 GMT
+1, sounds good.

On Fri, Jan 2, 2009 at 13:23, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Thu, Jan 1, 2009 at 3:33 PM, Bernd Fondermann
> <bernd.fondermann@googlemail.com> wrote:
>> 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?
>
> 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


Mime
View raw message