Jaroslav,
I am not sure that it is a good idea to add simply
InvalidObjectException into the catching list. I remember that we
carefully analyzed and tested the catching list, in order to avoid
no-needed call of "fetchOneNotif", and to avoid fetching on a dead
connection. Look at
javax.management.remote.rmi.RMIConnector$RMINotifClient.fetchNotifs, we
carefully retrieve an original exception wrapped in a
UnmarshalException, with different protocol to allow
ClientNotifForwarder to do right catching.
What I am afraid is that InvalidObjectException would be thrown with
other situations, like the connection was cut in the middle way of
fetching, then the fix would make ClientNotifForwarder fail to stop
fetching.
Shanliang
Jaroslav Bachorik wrote:
Please, review the change.
http://cr.openjdk.java.net/~jbachorik/8019584/webrev.00/
The combination of the fix for JDK-8014085 and
ObjectInputStream.readFields() not throwing CNFE when trying to
deserialize an object graph containing references to non-available
classes makes an InvalidObjectException being thrown instead of the CNFE
when processing JMX notifications.
The patch makes the ClientNotificationForwarder ready for
InvalidObjectException - it will correctly report lost notifications but
will not cause the notification processing loop to fail with unhandled
exception.
Thanks,
-JB-
