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
trace4.log.gz
Description: application/gzip
