>From Jaroslav's description it sounds as if RMI/IIOP is not following the expected semantics of RMI. In "plain" RMI (RMI/JRMP), unexporting an object on the server does not prevent already-received operations on that object from running to completion and sending their results back to the client. If RMI/IIOP doesn't work that way, then I think there are three options: (a) fix RMI/IIOP so it works as expected; (b) work around the problem as Jaroslav suggestions; or (c) ignore the problem. Probably (a) is impossible because I don't think there's anyone left with the necessary expertise, and poking around the dark caverns of the RMI/IIOP code seems inadvisable. A workaround is possible, though I agree that it would be a pity to pollute the JMX code with workarounds like this. Changing the generated RMI/IIOP code so that it no longer causes this exception, or so that it catches it and rethrows a RemoteException, sounds as if it ought to be fairly straightforward, and that's probably what I would do if it were up to me. Disabling this test for the IIOP case, and probably other failing JMX tests that involve IIOP, is an option if it is judged that nobody uses the RMI/IIOP connector any more so it is all right to let it rot. That judgement is a non-technical one that I don't have an informed opinion on.
Éamonn On 19 September 2012 06:39, Alan Bateman <alan.bate...@oracle.com> wrote: > On 19/09/2012 14:16, Jaroslav Bachorik wrote: >> >> : >> >> Not really - the NPE is thrown within the IIOP generated TIE class. I >> really don't feel like sticking my fingers into the CORBA code. The >> application code just receives the NPE. >> > For the record I think it would be better to address the real issue rather > than putting a hack in the JMX code I realize this may not be possible in > the short term. Eamonn might have some insight into this issue as it looks > like it has been causing intermittent failures in the JMX remote tests for > some time. > > -Alan
