Aaron Mulder wrote:
Okay, with the latest changes, the extraneous connections and OOM error are gone (thanks Hiram!). It turns out I was mistaken about the
Cool!
original NotificationFilter issue. I have made my filter serailizable, and it gets applied on the server side.Thanks for updating the test case.. It made it easy to track down the problem. It turns out that the reason that the NotificationListener is not properly removed is because the filters are being passed by value in the addNotificationListener and removeNotificationListener method calls. This means the server side gets two different copies of the filter which are != to each other. The fix is to implement the equals() and hashCode() so that the two copies can be compared properly.
However, I've now got a different problem. The NotificationListener does not seem to be removed properly. It may be related to the fact that I have a Serializable NotificationFilter set, whereas the test case had no filter. I've updated the test case (JMXRemotingTestMain), though you'll have to jar up the test classes under modules/remoting/test-classes into some JAR under target/geronimo-DEV/lib so the server can see the class for the Serializable NotificationFilter in order for the Serializable filter to work.
I guess as a side effect of this, a while after the client quits
(either the test class or the JSR-88 client), the server starts vomiting
stack traces -- I guess this is when the connect timeout has expired or
something. Once the remove problem is fixed, we may be able to work
around this in the case of JSR-88 by keeping a registry of listeners, and
adding a shutdown hook to unregister any listeners that are still there. How does that sound? We have to find *some* way around it, because the
logs will go berserk if we put out hundreds of lines of exceptions every 3
seconds until you restart the server...
I agree.. we need a more robust solution. A small hiccup of the client should not take down the server.
Regards, Hiram
Aaron
