Hi Aaron, > Okay, I added equals and hashCode in the filter, and now > everything seems to be groovy! (Oops, perhaps the wrong word to use > around here). I did discover that if I add a > NotificationListener with a > NotificationFilter, I also have to pass the same filter to the remove > call. It's curious that you can't just remove the listener > and have it > figure out that it should remove that listener regardless of > whether it > was registered with a filter or not.
It's because JMX allows to register the same listener with different filters. > IMHO, we have to get MX4J changed so it uses at most 1 thread > per client (or equivalently per listener), not one thread per > notification per client. In the time it takes a call to > timeout, you may have had easily 100 notifications for the > missing client... And then you're treated to a > stack trace for each one, while the next 100 calls have already been > launched. Not following here. The listener stays on the client, and in JSR 160 semantic is not a remote object: it is burden of the "framework" to handle these details (JSR 160 does it, or another remoting framework not based on JSR 160 semantic should do IMHO). Can you expand why you there is 1 thread per notification ? BTW, MX4J does not use 1 thread per notification; perhaps the remoting framework does ? Having written such a remoting framework once, and then having implemented JSR 160, I think that the JSR 160 approach is simpler and still almost equally powerful. For example, I would not make anymore my listeners to be Remote in the RMI sense so that when a notification is to be sent to that listener, the server calls the client via RMI. That was the old MX4J remoting style of sending remote notifications. I have to say that I like JSR 160's more. Sorry if I am way out of path here, just wanted to throw in my 0.02 EUR. Cheers Simon
