You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/11/14 18:54:30 UTC
JMX problems
Craig, Amy - or anyone who knows JMX, I need help :-)
I just can't find any way to add an attribute change listener
in the whole JMX spec, unless I have the instance of the model
mbean. And there is no way to get that instance.
All query and get methods in MBeanServer return ObjectInstance -
i.e. name and class, but no 'instance'.
There is an 'addNotificationListener' that takes the object name -
but the spec ( and implementation ) doesn't allow this to register
attribute change listeners, and att changes are not sent to
listeners registered with this method ( there is an "all other but
attribute changes" in the PDF file ).
I'm stuck. I can add some code to the modeler mbean to work
around, but the solution won't work for other mbeans.
What I want to do is find all attribute changes done via JMX and persist
them - if you remember my old proposal. At the moment I'm not very sure
it can be implemented. The only possible solution to revive it would be
to force all attribute changes to go through a modeler-specific interface
or to require the use of the modeler for all mbeans.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX problems
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> The problem is that the ModelMBean implementation in JMX-RI and MX4J
>> don't seem to behave this way, and the spec wording is ( page 84 in the
>> 1.1 PDF ):
>
> I believe ModelMBean implementation in JMX-RI and MX4J behave this way for
> all external Notification listeners.
Not sure we are talking about the same thing here.
In MX4J, JMX-RI and modeler the model mbean will not send notifications
about attribute changes to listeners registered via
addNotificationListener(), and there is no way to register for attribute
change notifications unless you have the instance of the model mbean ( which
is not available ).
The end result is that implementing config persistence using the attribute
change notification won't work. Combined with the fact that there is no way
to make distinction between 'external' attribute changes and 'internal'
state change - my original proposal for config in 5.0 just won't work.
Right now the only way I can see to improve the config in 5.0 is to have the
admin ( or any UI/config mechanism ) use JNDI instead of JMX and operate on
the passive data.
I'm trying to find if the other way around works - i.e. use JNDI events to
keep the 2 in sync - but it makes much more sense to use jndi rather than
JNI for changing the configuration and persistence, and use JMX only to
change the runtime config and monitoring ( there is a significant
distinction between the 2 ).
> I believe this is only true for AttributeChangeNotifications generated by
> the internal mechanism that is enabled when a listener internal to the
> ModelMBean is added with addAttributeChangeNotificationListener().
The problem is there is no way to add attribute change notification
listeners to a model mbean using the current API ( unless you have the
instance ).
> I think this was intended to allow implementing persistance on a per
> ModelMBean basis and was not intended to deliver generic
> AttributeChangeNotifications.
That might work - i.e using modeler internals for persistence, or using
internal APIs ( interceptors in MX4J ) for other mbeans.
I'm still trying to find a simple solution - I'm very busy right now,
but I'll send the results to the list as soon as I'm ready. IMO going
the other way around has a number of important benefits and doesn't require
many changes in the admin code ( the APIs are very similar, and most calls
are concentrated in few utils ). In addition we can move most of the config
and instrumentation code in the 'main' code ( since we already depend on
JMX).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX problems
Posted by Amy Roh <am...@apache.org>.
> Thanks Amy !
>
> That was my initial understanding.
>
> The problem is that the ModelMBean implementation in JMX-RI and MX4J
> don't seem to behave this way, and the spec wording is ( page 84 in the
> 1.1 PDF ):
I believe ModelMBean implementation in JMX-RI and MX4J behave this way for
all external Notification listeners.
>
> "In the model MBean, AttributeChangeNotifications are sent to a separate
> set of listeners than those that other notifications would go to. All
other
> notifications should go to listeners who registered using the methods
> defined in the NotificationBroadcaster interface.
> AttributeChangeNotifications can also be sent to all notification
listeners
> simply by using the NotificationBroadcaster interface alone."
>
> Since we are using model mbeans, ACN are sent to the "separate set",
> and "all other" notifications go to listeners registered using
> NotificationBrodacaster. That's the current behavior for JMX-RI, MX4J and
> modeler.
I believe this is only true for AttributeChangeNotifications generated by
the internal mechanism that is enabled when a listener internal to the
ModelMBean is added with addAttributeChangeNotificationListener().
I think this was intended to allow implementing persistance on a per
ModelMBean basis and was not intended to deliver generic
AttributeChangeNotifications.
>
> Is there any clarification of the spec - or another part that I
overlooked?
>
> I understand that this particular restriction is only on model mbeans -
> and it would be possible for regular mbeans to send attribute changes
> to all listeners. So a possible solution would be to modify modeler
> and make it a "dynamic mbean" ( or keep it model mbean but not implement
> this separation ).
>
> Costin
>
>
>
> Amy Roh wrote:
>
> > Costin,
> >
> > Costin Manolache wrote:
> >> Craig, Amy - or anyone who knows JMX, I need help :-)
> >>
> >> I just can't find any way to add an attribute change listener
> >> in the whole JMX spec, unless I have the instance of the model
> >> mbean. And there is no way to get that instance.
> >>
> >
> > I talked to Hans Hrasna in JMX team and I got the following answers.
> >
> > It IS possible to manage all attribute changes via JMX and persist them
> > using attribute change listener using the current spec.
> >
> > It's up to the MBean owning the attribute of interest to create and send
> > attribute change notifications when the attribute change occurs. So the
> > NotificationBroadcaster interface has to be implemented by any MBean for
> > which an attribute change is of interest.
> >
> > Example: If an MBean called myMbean needs to notify registered listeners
> > when its attribute:
> >
> > String myString
> >
> > is modified, myMbean creates and emits the following notification:
> >
> > new AttributeChangeNotification(myMbean, sequenceNumber,
timeStamp,
> > msg, "myString", "String", oldValue, newValue);
> >
> >
> > One just adds a NotificationListener. AttributeChangeNotification is
> > emitted just like any other notification.
> >
> >
> >> All query and get methods in MBeanServer return ObjectInstance -
> >> i.e. name and class, but no 'instance'.
> >>
> >> There is an 'addNotificationListener' that takes the object name -
> >> but the spec ( and implementation ) doesn't allow this to register
> >> attribute change listeners, and att changes are not sent to
> >> listeners registered with this method ( there is an "all other but
> >> attribute changes" in the PDF file ).
> >
> >
> > NotificationListeners registered on an MBean will receive the
> > AttributeChangeNotifications just like any other notification. There is
> > no such special type "attribute change listeners".
> >
> > Hope this helps.
> > Amy
> >
> >>
> >> I'm stuck. I can add some code to the modeler mbean to work
> >> around, but the solution won't work for other mbeans.
> >>
> >> What I want to do is find all attribute changes done via JMX and
persist
> >> them - if you remember my old proposal. At the moment I'm not very sure
> >> it can be implemented. The only possible solution to revive it would be
> >> to force all attribute changes to go through a modeler-specific
interface
> >> or to require the use of the modeler for all mbeans.
> >>
> >> Costin
> >>
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <ma...@jakarta.apache.org> For additional
> >> commands, e-mail: <ma...@jakarta.apache.org>
> >>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX problems
Posted by Costin Manolache <cm...@yahoo.com>.
Thanks Amy !
That was my initial understanding.
The problem is that the ModelMBean implementation in JMX-RI and MX4J
don't seem to behave this way, and the spec wording is ( page 84 in the
1.1 PDF ):
"In the model MBean, AttributeChangeNotifications are sent to a separate
set of listeners than those that other notifications would go to. All other
notifications should go to listeners who registered using the methods
defined in the NotificationBroadcaster interface.
AttributeChangeNotifications can also be sent to all notification listeners
simply by using the NotificationBroadcaster interface alone."
Since we are using model mbeans, ACN are sent to the "separate set",
and "all other" notifications go to listeners registered using
NotificationBrodacaster. That's the current behavior for JMX-RI, MX4J and
modeler.
Is there any clarification of the spec - or another part that I overlooked?
I understand that this particular restriction is only on model mbeans -
and it would be possible for regular mbeans to send attribute changes
to all listeners. So a possible solution would be to modify modeler
and make it a "dynamic mbean" ( or keep it model mbean but not implement
this separation ).
Costin
Amy Roh wrote:
> Costin,
>
> Costin Manolache wrote:
>> Craig, Amy - or anyone who knows JMX, I need help :-)
>>
>> I just can't find any way to add an attribute change listener
>> in the whole JMX spec, unless I have the instance of the model
>> mbean. And there is no way to get that instance.
>>
>
> I talked to Hans Hrasna in JMX team and I got the following answers.
>
> It IS possible to manage all attribute changes via JMX and persist them
> using attribute change listener using the current spec.
>
> It's up to the MBean owning the attribute of interest to create and send
> attribute change notifications when the attribute change occurs. So the
> NotificationBroadcaster interface has to be implemented by any MBean for
> which an attribute change is of interest.
>
> Example: If an MBean called myMbean needs to notify registered listeners
> when its attribute:
>
> String myString
>
> is modified, myMbean creates and emits the following notification:
>
> new AttributeChangeNotification(myMbean, sequenceNumber, timeStamp,
> msg, "myString", "String", oldValue, newValue);
>
>
> One just adds a NotificationListener. AttributeChangeNotification is
> emitted just like any other notification.
>
>
>> All query and get methods in MBeanServer return ObjectInstance -
>> i.e. name and class, but no 'instance'.
>>
>> There is an 'addNotificationListener' that takes the object name -
>> but the spec ( and implementation ) doesn't allow this to register
>> attribute change listeners, and att changes are not sent to
>> listeners registered with this method ( there is an "all other but
>> attribute changes" in the PDF file ).
>
>
> NotificationListeners registered on an MBean will receive the
> AttributeChangeNotifications just like any other notification. There is
> no such special type "attribute change listeners".
>
> Hope this helps.
> Amy
>
>>
>> I'm stuck. I can add some code to the modeler mbean to work
>> around, but the solution won't work for other mbeans.
>>
>> What I want to do is find all attribute changes done via JMX and persist
>> them - if you remember my old proposal. At the moment I'm not very sure
>> it can be implemented. The only possible solution to revive it would be
>> to force all attribute changes to go through a modeler-specific interface
>> or to require the use of the modeler for all mbeans.
>>
>> Costin
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org> For additional
>> commands, e-mail: <ma...@jakarta.apache.org>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX problems
Posted by Amy Roh <am...@apache.org>.
Costin,
Costin Manolache wrote:
> Craig, Amy - or anyone who knows JMX, I need help :-)
>
> I just can't find any way to add an attribute change listener
> in the whole JMX spec, unless I have the instance of the model
> mbean. And there is no way to get that instance.
>
I talked to Hans Hrasna in JMX team and I got the following answers.
It IS possible to manage all attribute changes via JMX and persist them
using attribute change listener using the current spec.
It's up to the MBean owning the attribute of interest to create and send
attribute change notifications when the attribute change occurs. So the
NotificationBroadcaster interface has to be implemented by any MBean for
which an attribute change is of interest.
Example: If an MBean called myMbean needs to notify registered listeners
when its attribute:
String myString
is modified, myMbean creates and emits the following notification:
new AttributeChangeNotification(myMbean, sequenceNumber, timeStamp,
msg, "myString", "String", oldValue, newValue);
One just adds a NotificationListener. AttributeChangeNotification is
emitted just like any other notification.
> All query and get methods in MBeanServer return ObjectInstance -
> i.e. name and class, but no 'instance'.
>
> There is an 'addNotificationListener' that takes the object name -
> but the spec ( and implementation ) doesn't allow this to register
> attribute change listeners, and att changes are not sent to
> listeners registered with this method ( there is an "all other but
> attribute changes" in the PDF file ).
NotificationListeners registered on an MBean will receive the
AttributeChangeNotifications just like any other notification. There is
no such special type "attribute change listeners".
Hope this helps.
Amy
>
> I'm stuck. I can add some code to the modeler mbean to work
> around, but the solution won't work for other mbeans.
>
> What I want to do is find all attribute changes done via JMX and persist
> them - if you remember my old proposal. At the moment I'm not very sure
> it can be implemented. The only possible solution to revive it would be
> to force all attribute changes to go through a modeler-specific interface
> or to require the use of the modeler for all mbeans.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX problems
Posted by Costin Manolache <cm...@yahoo.com>.
More info:
I checked MX4J, JMX-RI and JBoss. The model mbean implementations
in the first 2 are consistent - and do not send attribute change
notifications on the 'normal' listeners ( those registered with
addNotificationListener). That's also consistent with the spec
wording "all other notifications" ( other than attribute change ).
JBoss doesn't follow the spec and sends attribute changes to
all listeners ( at least in 3.0.4 ).
One way or the other - the JMX spec seems to have a problem. IMO
jboss is doing the right thing ( since attribute change notifications
are useless if you can't register listeners - and so far I couldn't
find any method to allow that without having an mbean instance, and
I found no method to give back the mbean instance ).
The bigger problem is that without beeing able to get back the mbean
instance, a lot of the things are impossible. You can only invoke
methods and set attributes via JMX ( probably that was the intention ),
but that removes a possible optimization and makes JMX unusable ( alone)
as a 'core' component architecture. I'm still investigating how jboss
works - but it seems they also use JNDI to suplement JMX.
Costin
Costin Manolache wrote:
> Craig, Amy - or anyone who knows JMX, I need help :-)
>
> I just can't find any way to add an attribute change listener
> in the whole JMX spec, unless I have the instance of the model
> mbean. And there is no way to get that instance.
>
> All query and get methods in MBeanServer return ObjectInstance -
> i.e. name and class, but no 'instance'.
>
> There is an 'addNotificationListener' that takes the object name -
> but the spec ( and implementation ) doesn't allow this to register
> attribute change listeners, and att changes are not sent to
> listeners registered with this method ( there is an "all other but
> attribute changes" in the PDF file ).
>
> I'm stuck. I can add some code to the modeler mbean to work
> around, but the solution won't work for other mbeans.
>
> What I want to do is find all attribute changes done via JMX and persist
> them - if you remember my old proposal. At the moment I'm not very sure
> it can be implemented. The only possible solution to revive it would be
> to force all attribute changes to go through a modeler-specific interface
> or to require the use of the modeler for all mbeans.
>
> Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>