geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: [jmx] Duplicate notifications
Date Sun, 16 Nov 2003 00:23:20 GMT
Simone,

I've taken your suggestion and turned up the mx4j logging level and 
produced some awesomely verbose logs :-)

However, after playing around with this for a week now, I just can't 
make any progress.

I've attached the log of the last run. Its a bit confusing as it 
contains debug for all of the other geronimo services that are also 
deployed, but to make it easier, I've marked up the important sections 
with lines like:


************ BLAH is SENT it's OWN UNREGISTRATION EVENT, TRIES TO
              UNREGISTER AS A NOTIFICATION LISTENER

The sequence of events was:

blah service (and all the standard geronimo services) are deployed
blah service is undeployed

The blah object registers itself as a Notification Listener in it's
postRegister() method, and deregisters itself as a Notification Listener 
in it's postDeregister() method.

As you can see from the log, the blah object never finds its own 
Notification Listener when it tries to remove it. I've included the 
hashCode of the Blah object for significant events, like object 
creation, mbean registration, notification listener addition/removal etc 
and it seems like the object being operated on is indeed the one expected.

I don't understand why the blah object cannot remove itself as a 
notification listener? The stack trace of the mx4j error may be more 
meaningful to you.

Thanks so much in advance for any help you can give me with this, it is 
driving me insane!


Jan

Bordet, Simone wrote:
> Hi Jan,
> 
> 
>>I've been testing hot deploying and undeploying Geronimo services and 
>>something odd is going on. I've spent most of the weekend looking at 
>>this and not getting any further, so any JMX/MX4J experts out 
>>there feel free to respond :-)
> 
> 
> I guess I qualify for this ;)
> 
> 
>>Essentially, the situation is this:
> 
> 
> Hmm, the example is quite complicated, and unfortunately my firewall blocks access to
geronimo's CVS (and I don't tell you about the lack of time...): can't try it.
> 
> It seems too trivial to ask, but are you sure you're removing the listener from the right
MBean (using the right ObjectName) ?
> 
> Have you tried to set the system property mx4j.log.priority=trace ? If not, please do
so and post the output.
> 
> I think you choose the correct approach when registering listener(s) in preRegister and
removing it in preDeregister().
> 
> [snip]
> 
> 
>>The truly freaky thing is that once any service has been thru the 
>>deploy/undeploy/redeploy cycle, any OTHER service that is 
>>subsequently 
>>deployed also receives duplicate notifications, even if it has never 
>>previously been deployed!!!
> 
> 
> That sounds really strange and smells of listeners not unregistered.
> I would check if there are no long-lived objects that holds listeners around (like the
MBeanServerDelegate), and be sure to unregister the same listener (same as in object identity
using ==) that was registered.
> 
> Hope helps; ping on me if it does not, I'll try to figure this out with your help.
> 
> Cheers
> 
> Simon


Mime
View raw message