You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Achim Huegen <ah...@gmx-topmail.de> on 2004/12/06 22:51:47 UTC
JMX Support
Hi,
I invested time in building jmx support into hivemind.
Some documentation and links to a working prototype are available
here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
I'm interested in feedback especially about the 'metadata' support.
Bye
Achim Huegen
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Howard Lewis Ship <hl...@gmail.com>.
I took a quick look at your live site and was impressed. This is
something that could easily be rolled into HiveMInd's library.
On Mon, 06 Dec 2004 22:51:47 +0100, Achim Huegen <ah...@gmx-topmail.de> wrote:
> Hi,
>
> I invested time in building jmx support into hivemind.
> Some documentation and links to a working prototype are available
> here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
>
> I'm interested in feedback especially about the 'metadata' support.
>
> Bye
> Achim Huegen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El Lun 06 Dic 2004 18:51, Achim Huegen escribió:
> Hi,
>
> I invested time in building jmx support into hivemind.
> Some documentation and links to a working prototype are available
> here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
Wow! Great job! We were about to implement something a little like that...
looks great!
Is there a way to get the code?
We can cooperate with this since in this right moment we have to solve JMX
support for our app if that's ok with you.
--
Pablo I. Lalloni <pl...@afip.gov.ar>
Teléfono +54 (11) 4347-3177
Proyecto Pampa
Dirección Informática Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There's no time like the pleasant.
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Eric Yung <er...@jspectrum.com>.
Pablo Lalloni wrote:
>Ejem... Have I said something unapropriate?
>
>I'm not very good with english so here are my apologies if that's the case....
>sorry.
>
>
I am thinking about it this few days.
>El Jue 09 Dic 2004 11:50, Pablo Lalloni escribió:
>
>
>>Shouldn't the ServiceModel itself be exposed/used for managing the
>>corresponding pool?
>>
>>I think MBean interfaces should be keep clean an mapping 1:1 on the exposed
>>service-point.
>>
>>
If the core service implementation of a pooled service point defines its
MBean interface, each instance should have its MBean registered in JMX.
But the service point itself should be registered as one MBean as other
kinds of service point.
Like Achim's current implementation, the JMX addition to Hivemind should
include the following MBeans.
1) MBean for configuration points - the current implementation looks ok.
2) MBean for service points - one MBean per service point should be
used. The basic MBean interface of a service point should be the same as
its service model. Primitive / Singleton service model provides little
information (e.g. service interface classname, whether the service has
been instantiated in the singleton service model, the MBean of the core
service instance if found, etc.), while Pooled service model provides
additional information for the pool's statistics (number of active /
created instances, etc.) If a user would like to provide additional
managed attributes / operations, he must specify the managed interface
in the contribution. If the given interface is the same or a sub-class
of the service interface, we can use the service proxy / instance as the
MBean. Otherwise, we should define a way how to wire the operation from
the managed interface to the service interface.
3) MBean for the core service instance - we need Hivemind's internal
support to register the MBean of a core service instance after its
instantiation (may be as an Observer / EventListener).
4) MBean for the interceptor - we should generalize the idea of
PerformanceMonitor <http://wiki.apache.org/jakarta-hivemind/JmxPreview>
to allow the interceptor factory to access the JMX server or add a new
JMX enable interceptor factory.
>>Our previous thinking about this was like this:
>>
>>JMX publisher service should expose a service-point (as-is) as an MBean,
>>keeping its interface as possible and the MBean should just delegate to the
>>proxied service as any other client code.
>>
>>We didn't want to mix business interface with management interface of
>>services and for this we planned to make a separate service-point for each.
>>
>>We have done previously for other uses a delegator service factory which
>>receives on its parameters schema a mapping of interface methods to other
>>services methods... this'll be clear with an example:
>>
>><service-point id="Delegator1"
>>interface="gov.afip.pampa.services.delegator.Delegator1">
>> <invoke-factory service-id="pampa.delegator.DelegatorFactory">
>> <construct
>>base-class="gov.afip.pampa.services.AbstractBusinessService">
>> <delegate service-id="Delegate1">
>> <implement method="method"
>>delegate-method="method"/>
>> <implement method="methodString"/>
>> </delegate>
>> <delegate service-id="Delegate2">
>> <implement method="get*"/>
>> </delegate>
>> </construct>
>> </invoke-factory>
>> <interceptor service-id="hivemind.LoggingInterceptor"/>
>></service-point>
>>
>>We implemented this for security, constructing a MZ with delegators. But
>>now we were looking at using the same (or a similar) approach for the
>>management interface of manageable services. If there's interest in this
>>code I can post it somewhere.
>>
>>Now with this separation of "business"/management interfaces in two
>>different service/points, the bussiness service can be registered as a
>>"listener" of the management service so the last will be able to collect
>>references to every instance, also this management service just becomes a
>>multiple-dispatch proxy a-la pico. (Yes, I see the current problem of never
>>releasing references to threaded or pooled service instances that has been
>>discarded by HiveMind, but this coould be worked out).
>>
>>
I agree with you that the separation of "business / management"
interface is a good point, but the implementation must be simple and can
handle all service models.
>>I think we should implement all this stuff as different constructing blocks
>>/ tools: delegator factory, dispatcher proxy factory, whatever... and a jmx
>>publisher that only puts a service-point as MBean.
>>
>>Of course this JMX publisher could receive (as the delegator factory above)
>>which methods to put in the MBean.
>>
>>This way we can keep everything simpler and we give the possibility to mix
>>and match as needed.
>>
>>
>
>
>
Re: JMX Support
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
Ejem... Have I said something unapropriate?
I'm not very good with english so here are my apologies if that's the case....
sorry.
El Jue 09 Dic 2004 11:50, Pablo Lalloni escribió:
> Shouldn't the ServiceModel itself be exposed/used for managing the
> corresponding pool?
>
> I think MBean interfaces should be keep clean an mapping 1:1 on the exposed
> service-point.
>
> Our previous thinking about this was like this:
>
> JMX publisher service should expose a service-point (as-is) as an MBean,
> keeping its interface as possible and the MBean should just delegate to the
> proxied service as any other client code.
>
> We didn't want to mix business interface with management interface of
> services and for this we planned to make a separate service-point for each.
>
> We have done previously for other uses a delegator service factory which
> receives on its parameters schema a mapping of interface methods to other
> services methods... this'll be clear with an example:
>
> <service-point id="Delegator1"
> interface="gov.afip.pampa.services.delegator.Delegator1">
> <invoke-factory service-id="pampa.delegator.DelegatorFactory">
> <construct
> base-class="gov.afip.pampa.services.AbstractBusinessService">
> <delegate service-id="Delegate1">
> <implement method="method"
> delegate-method="method"/>
> <implement method="methodString"/>
> </delegate>
> <delegate service-id="Delegate2">
> <implement method="get*"/>
> </delegate>
> </construct>
> </invoke-factory>
> <interceptor service-id="hivemind.LoggingInterceptor"/>
> </service-point>
>
> We implemented this for security, constructing a MZ with delegators. But
> now we were looking at using the same (or a similar) approach for the
> management interface of manageable services. If there's interest in this
> code I can post it somewhere.
>
> Now with this separation of "business"/management interfaces in two
> different service/points, the bussiness service can be registered as a
> "listener" of the management service so the last will be able to collect
> references to every instance, also this management service just becomes a
> multiple-dispatch proxy a-la pico. (Yes, I see the current problem of never
> releasing references to threaded or pooled service instances that has been
> discarded by HiveMind, but this coould be worked out).
>
> I think we should implement all this stuff as different constructing blocks
> / tools: delegator factory, dispatcher proxy factory, whatever... and a jmx
> publisher that only puts a service-point as MBean.
>
> Of course this JMX publisher could receive (as the delegator factory above)
> which methods to put in the MBean.
>
> This way we can keep everything simpler and we give the possibility to mix
> and match as needed.
--
Pablo I. Lalloni <pl...@afip.gov.ar>
Teléfono +54 (11) 4347-3177
Proyecto Pampa
Dirección Informática Tributaria
AFIP
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nothing I do is my fault.
-- Calvin
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Pablo Lalloni <pl...@afip.gov.ar>.
El Jue 09 Dic 2004 09:15, Achim Huegen escribió:
> Eric Yung wrote:
> > And for the pooled service model, I think we should threat all instances
> > of a pooled service as one MBean. If the user would like to change an
> > attribute of a pooled service, the new value should apply to all
> > instances. For the operations, we should only list the operations
> > defined in its service interface in the MBean. Other operations defined
> > in its MBean service (if has) should be hided as we cannot know if those
> > operations should be invoked in one of the instances or all instances.
> > And the MBean of the pooled service should include pool attributes such
> > as the # of active instances, the # of pooled instances, etc. What do
> > you think?
Shouldn't the ServiceModel itself be exposed/used for managing the
corresponding pool?
I think MBean interfaces should be keep clean an mapping 1:1 on the exposed
service-point.
>
> An idea that came to my mind too. We would need a service instance
> creation event, that is dispatched by the servicePoint or model to
> get references to all service instances.
> But the the amount of operations that can be called automatically on
> all instances is small. Getters can't be handled reasonably.
> Even non-void methods in general are problematic.
>
> Another option would be to build some infrastructure that allows easy
> creation of custom mbeans that handle multiple services instances:
> - automatic registration of service instances in the mbean
> - support for calling methods in all instances
> - support for calling getter/non-void methods in all instances and
> getting an array of result objects
>
> Of course it is more work to implement a custom mbean, but it is the
> easiest way to decide which methods are called which way.
> For example the mbean could calculate the sum or average of all the
> values that are returned by a certain getter method.
>
Our previous thinking about this was like this:
JMX publisher service should expose a service-point (as-is) as an MBean,
keeping its interface as possible and the MBean should just delegate to the
proxied service as any other client code.
We didn't want to mix business interface with management interface of services
and for this we planned to make a separate service-point for each.
We have done previously for other uses a delegator service factory which
receives on its parameters schema a mapping of interface methods to other
services methods... this'll be clear with an example:
<service-point id="Delegator1"
interface="gov.afip.pampa.services.delegator.Delegator1">
<invoke-factory service-id="pampa.delegator.DelegatorFactory">
<construct
base-class="gov.afip.pampa.services.AbstractBusinessService">
<delegate service-id="Delegate1">
<implement method="method"
delegate-method="method"/>
<implement method="methodString"/>
</delegate>
<delegate service-id="Delegate2">
<implement method="get*"/>
</delegate>
</construct>
</invoke-factory>
<interceptor service-id="hivemind.LoggingInterceptor"/>
</service-point>
We implemented this for security, constructing a MZ with delegators. But now
we were looking at using the same (or a similar) approach for the management
interface of manageable services. If there's interest in this code I can post
it somewhere.
Now with this separation of "business"/management interfaces in two different
service/points, the bussiness service can be registered as a "listener" of
the management service so the last will be able to collect references to
every instance, also this management service just becomes a multiple-dispatch
proxy a-la pico. (Yes, I see the current problem of never releasing
references to threaded or pooled service instances that has been discarded by
HiveMind, but this coould be worked out).
I think we should implement all this stuff as different constructing blocks /
tools: delegator factory, dispatcher proxy factory, whatever... and a jmx
publisher that only puts a service-point as MBean.
Of course this JMX publisher could receive (as the delegator factory above)
which methods to put in the MBean.
This way we can keep everything simpler and we give the possibility to mix and
match as needed.
--
Pablo I. Lalloni <pl...@afip.gov.ar>
Teléfono +54 (11) 4347-3177
Proyecto Pampa
Dirección Informática Tributaria
AFIP
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Achim Huegen <ah...@gmx-topmail.de>.
Eric Yung wrote:
> And for the pooled service model, I think we should threat all instances
> of a pooled service as one MBean. If the user would like to change an
> attribute of a pooled service, the new value should apply to all
> instances. For the operations, we should only list the operations
> defined in its service interface in the MBean. Other operations defined
> in its MBean service (if has) should be hided as we cannot know if those
> operations should be invoked in one of the instances or all instances.
> And the MBean of the pooled service should include pool attributes such
> as the # of active instances, the # of pooled instances, etc. What do
> you think?
>
An idea that came to my mind too. We would need a service instance
creation event, that is dispatched by the servicePoint or model to
get references to all service instances.
But the the amount of operations that can be called automatically on
all instances is small. Getters can't be handled reasonably.
Even non-void methods in general are problematic.
Another option would be to build some infrastructure that allows easy
creation of custom mbeans that handle multiple services instances:
- automatic registration of service instances in the mbean
- support for calling methods in all instances
- support for calling getter/non-void methods in all instances and
getting an array of result objects
Of course it is more work to implement a custom mbean, but it is the
easiest way to decide which methods are called which way.
For example the mbean could calculate the sum or average of all the
values that are returned by a certain getter method.
Achim Huegen
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Eric Yung <er...@jspectrum.com>.
Achim Huegen wrote:
> At first we should discuss if it makes sense to publish threaded or
> pooled services as Mbeans. IMO the answer is clearly negative for
> threaded services, since their lifetime
> is much to short to manage them.
> What about pooled services? Are there management use cases for them?
>
You are right. We can ignore the threaded service model.
And for the pooled service model, I think we should threat all instances
of a pooled service as one MBean. If the user would like to change an
attribute of a pooled service, the new value should apply to all
instances. For the operations, we should only list the operations
defined in its service interface in the MBean. Other operations defined
in its MBean service (if has) should be hided as we cannot know if those
operations should be invoked in one of the instances or all instances.
And the MBean of the pooled service should include pool attributes such
as the # of active instances, the # of pooled instances, etc. What do
you think?
> If we concentrate on singletons it would be rather easy to keep a
> reference
> to the core service implementation in the servicePoint.
>
> Regarding the publishing of 'all attributes of a service object' I can
> imagine multiple ways of registering a singleton service as mbean:
> - specify the management interface in the mbeans contribution
> - if no management interface is specified: automatically detect whether
> the DynamicMBean or a standard mbean interface is supported
> - specify that all attributes and operations of the service should
> be exposed in the mbean. This will require a special mbean that uses
> introspection.
>
The special MBean can either be a DynamicMBean or a ModelMBean (optional
in 1.1 and manadatory in 1.2).
Eric
> Achim Huegen
>
>> Hi,
>>
>> Your prototype is quite impressive as they can show both the
>> configuration points & service points as MBeans.
>>
>> But as your remark says, we need to find a way to expose the core
>> service object as MBean because the core service object can have more
>> attributes and operations than its interface. And we should be able
>> to access all attributes of a service object defined in the
>> hivemind.xml file, not just the ones defined by its interface.
>>
>> I would suggest to add an attribute to the service point MBean and
>> this attribute should store the ObjectName of the core service MBean.
>> And we can navigate from the service point MBean to its core service
>> MBean. In order to do this, we need to have Hivemind's support to get
>> the core service object of a service. The ServicePoint interface will
>> be the appropriate place to get the core service object. But this
>> changes also involve the ServiceModel objects as the ServicePointImpl
>> object gets the service from one of the ServiceModel. It becomes
>> rather complicate for the pooled and threaded service model and I
>> have NO ideas how to do that.
>>
>> BTW, I have extended HiveMind (using AspectJ) to register the core
>> service objects as MBean after their instantiation (only for the
>> primitive & singleton service model). But this extension only works
>> for the core services, it does not include its interceptors.
>>
>>
>> Eric
>>
>> Achim Huegen wrote:
>>
>>> Hi,
>>>
>>> I invested time in building jmx support into hivemind.
>>> Some documentation and links to a working prototype are available
>>> here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
>>>
>>> I'm interested in feedback especially about the 'metadata' support.
>>>
>>> Bye
>>> Achim Huegen
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Achim Huegen <ah...@gmx-topmail.de>.
At first we should discuss if it makes sense to publish threaded or pooled
services as Mbeans. IMO the answer is clearly negative for threaded
services, since their lifetime
is much to short to manage them.
What about pooled services? Are there management use cases for them?
If we concentrate on singletons it would be rather easy to keep a reference
to the core service implementation in the servicePoint.
Regarding the publishing of 'all attributes of a service object' I can
imagine multiple ways of registering a singleton service as mbean:
- specify the management interface in the mbeans contribution
- if no management interface is specified: automatically detect whether
the DynamicMBean or a standard mbean interface is supported
- specify that all attributes and operations of the service should
be exposed in the mbean. This will require a special mbean that uses
introspection.
Achim Huegen
> Hi,
>
> Your prototype is quite impressive as they can show both the
> configuration points & service points as MBeans.
>
> But as your remark says, we need to find a way to expose the core
> service object as MBean because the core service object can have more
> attributes and operations than its interface. And we should be able to
> access all attributes of a service object defined in the hivemind.xml
> file, not just the ones defined by its interface.
>
> I would suggest to add an attribute to the service point MBean and this
> attribute should store the ObjectName of the core service MBean. And we
> can navigate from the service point MBean to its core service MBean. In
> order to do this, we need to have Hivemind's support to get the core
> service object of a service. The ServicePoint interface will be the
> appropriate place to get the core service object. But this changes also
> involve the ServiceModel objects as the ServicePointImpl object gets the
> service from one of the ServiceModel. It becomes rather complicate for
> the pooled and threaded service model and I have NO ideas how to do that.
>
> BTW, I have extended HiveMind (using AspectJ) to register the core
> service objects as MBean after their instantiation (only for the
> primitive & singleton service model). But this extension only works for
> the core services, it does not include its interceptors.
>
>
> Eric
>
> Achim Huegen wrote:
>
>> Hi,
>>
>> I invested time in building jmx support into hivemind.
>> Some documentation and links to a working prototype are available
>> here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
>>
>> I'm interested in feedback especially about the 'metadata' support.
>>
>> Bye
>> Achim Huegen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: JMX Support
Posted by Eric Yung <er...@jspectrum.com>.
Hi,
Your prototype is quite impressive as they can show both the
configuration points & service points as MBeans.
But as your remark says, we need to find a way to expose the core
service object as MBean because the core service object can have more
attributes and operations than its interface. And we should be able to
access all attributes of a service object defined in the hivemind.xml
file, not just the ones defined by its interface.
I would suggest to add an attribute to the service point MBean and this
attribute should store the ObjectName of the core service MBean. And we
can navigate from the service point MBean to its core service MBean. In
order to do this, we need to have Hivemind's support to get the core
service object of a service. The ServicePoint interface will be the
appropriate place to get the core service object. But this changes also
involve the ServiceModel objects as the ServicePointImpl object gets the
service from one of the ServiceModel. It becomes rather complicate for
the pooled and threaded service model and I have NO ideas how to do that.
BTW, I have extended HiveMind (using AspectJ) to register the core
service objects as MBean after their instantiation (only for the
primitive & singleton service model). But this extension only works for
the core services, it does not include its interceptors.
Eric
Achim Huegen wrote:
> Hi,
>
> I invested time in building jmx support into hivemind.
> Some documentation and links to a working prototype are available
> here: http://wiki.apache.org/jakarta-hivemind/JmxPreview
>
> I'm interested in feedback especially about the 'metadata' support.
>
> Bye
> Achim Huegen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org