geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Remoting Update
Date Mon, 24 Nov 2003 05:25:46 GMT
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 

>original NotificationFilter issue.  I have made my filter serailizable, 
>and it gets applied on the server side.
>	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.
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.

>	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.



View raw message