From mandy.chung at oracle.com Thu Sep 13 08:46:29 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 Sep 2012 08:46:29 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties Message-ID: <5051FFD5.8070608@oracle.com> This is to eliminate the static dependency from JMX to java.beans.ConstructorProperties. Similar work has been done in the past [1] and this fix will allow JMX to be used without the presence of java.beans. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.00/ All tests in jdk_management1 and jdk_management2 passed. Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ced99075109 From eamonn at mcmanus.net Thu Sep 13 09:48:48 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 13 Sep 2012 09:48:48 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <5051FFD5.8070608@oracle.com> References: <5051FFD5.8070608@oracle.com> Message-ID: If at all possible, it would be better to split out ConstructorProperties into a separable dependency so that JMX could depend on just that. The idea that a profile with JMX but not JavaBeans is almost but not quite exactly like a profile with both seems rather user-hostile. If it is not possible to make that separation then the method CompositeBuilderViaConstructor.applicable should return immediately if constructorPropertiesClass == null, with an explanation string like "@ConstructorProperties annotation not available". That will produce a better exception message than the "no constructor has @ConstructorProperties annotation" that the code will produce as it stands even if constructors do have that annotation. On line 1161 you could write valueMethod.invoke(a) instead of valueMethod.invoke(a, new Object[0]). We faced a similar problem in the past where standalone JMX might be running on a Java version that did not have java.beans.ConstructorProperties. At that time we considered specifying that any @ConstructorProperties annotation, regardless of what package it came from, would have the same effect. Since you are accessing the annotation by reflection anyway it might be time to resuscitate this idea. Then users could at least insulate themselves from no-JavaBeans breakage by using their own definition of @ConstructorProperties. ?amonn On 13 September 2012 08:46, Mandy Chung wrote: > > This is to eliminate the static dependency from JMX to > java.beans.ConstructorProperties. Similar work has been > done in the past [1] and this fix will allow JMX to be used > without the presence of java.beans. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.00/ > > All tests in jdk_management1 and jdk_management2 passed. > > Mandy > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ced99075109 > From mandy.chung at oracle.com Thu Sep 13 14:45:19 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 Sep 2012 14:45:19 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: References: <5051FFD5.8070608@oracle.com> Message-ID: <505253EF.6060309@oracle.com> Hi Eamonn, Thanks for the review and the information. On 9/13/2012 9:48 AM, Eamonn McManus wrote: > If at all possible, it would be better to split out > ConstructorProperties into a separable dependency so that JMX could > depend on just that. The idea that a profile with JMX but not > JavaBeans is almost but not quite exactly like a profile with both > seems rather user-hostile. The current jdk modularization is being done that way. java.beans is split between the base module and the desktop module and ConstructorProperties is included in the base. We're working on addressing the split package issue so that the platform can be modularized cleanly. That's the motivation for this bug fix. > > If it is not possible to make that separation then the method > CompositeBuilderViaConstructor.applicable should return immediately if > constructorPropertiesClass == null, with an explanation string like > "@ConstructorProperties annotation not available". That will produce a > better exception message than the "no constructor has > @ConstructorProperties annotation" that the code will produce as it > stands even if constructors do have that annotation. Good idea. I have fixed that. > On line 1161 you could write valueMethod.invoke(a) instead of > valueMethod.invoke(a, new Object[0]). Fixed and the updated webrev is at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.01/ > We faced a similar problem in the past where standalone JMX might be > running on a Java version that did not have > java.beans.ConstructorProperties. At that time we considered > specifying that any @ConstructorProperties annotation, regardless of > what package it came from, would have the same effect. Since you are > accessing the annotation by reflection anyway it might be time to > resuscitate this idea. Then users could at least insulate themselves > from no-JavaBeans breakage by using their own definition of > @ConstructorProperties. I see two scenarios: 1. the application being instrumented is running on an older version of JRE 2. the jmx client accessing the model-specific types from a JVM being managed running 2 different versions of JRE This raises an interesting question - if @CP is part of the standalone JMX (e.g. javax.management.PropertyNames), would that issue exist? Alan and I have asked ourselves if we need to bring back javax.management.PropertyNames but it wasn't clear to us. Your feedback and any information/requirement info from the past relevant to this will be valuable. I'll file a separate RFE for it once the requirement becomes clear that the jmx/serviceability team can follow up. I'd like to get the fix to eliminate the dependency into jdk8 separated from this RFE. Thanks Mandy From eamonn at mcmanus.net Thu Sep 13 14:59:59 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 13 Sep 2012 14:59:59 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <505253EF.6060309@oracle.com> References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> Message-ID: >> If at all possible, it would be better to split out >> ConstructorProperties into a separable dependency so that JMX could >> depend on just that. The idea that a profile with JMX but not >> JavaBeans is almost but not quite exactly like a profile with both >> seems rather user-hostile. > The current jdk modularization is being done that way. java.beans is > split between the base module and the desktop module and > ConstructorProperties is included in the base. We're working on addressing > the split package issue so that the platform can be modularized cleanly. > That's the motivation for this bug fix. I'm not sure I fully understand. Are there no other cases where packages are split across modules? I'm wondering how important it is to avoid this particular split since it seems to me to introduce a subtle irregularity into JMX that could make things hard for users of the API. The cross-version scenarios you describe seem very unlikely since the MXBean API and @ConstructorProperties were added to the JRE at the same time. I don't think it would help much to introduce a new @javax.management.PropertyNames or whatever, because you would still have to support existing code that uses @ConstructorProperties. ?amonn On 13 September 2012 14:45, Mandy Chung wrote: > > Hi Eamonn, > > Thanks for the review and the information. > > > On 9/13/2012 9:48 AM, Eamonn McManus wrote: >> >> If at all possible, it would be better to split out >> ConstructorProperties into a separable dependency so that JMX could >> depend on just that. The idea that a profile with JMX but not >> JavaBeans is almost but not quite exactly like a profile with both >> seems rather user-hostile. > > > The current jdk modularization is being done that way. java.beans is > split between the base module and the desktop module and > ConstructorProperties is included in the base. We're working on addressing > the split package issue so that the platform can be modularized cleanly. > That's the motivation for this bug fix. > > >> >> If it is not possible to make that separation then the method >> CompositeBuilderViaConstructor.applicable should return immediately if >> constructorPropertiesClass == null, with an explanation string like >> "@ConstructorProperties annotation not available". That will produce a >> better exception message than the "no constructor has >> @ConstructorProperties annotation" that the code will produce as it >> stands even if constructors do have that annotation. > > > Good idea. I have fixed that. > >> On line 1161 you could write valueMethod.invoke(a) instead of >> valueMethod.invoke(a, new Object[0]). > > > Fixed and the updated webrev is at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.01/ > > >> We faced a similar problem in the past where standalone JMX might be >> running on a Java version that did not have >> java.beans.ConstructorProperties. At that time we considered >> specifying that any @ConstructorProperties annotation, regardless of >> what package it came from, would have the same effect. Since you are >> accessing the annotation by reflection anyway it might be time to >> resuscitate this idea. Then users could at least insulate themselves >> from no-JavaBeans breakage by using their own definition of >> @ConstructorProperties. > > > I see two scenarios: > 1. the application being instrumented is running on an older version of > JRE > 2. the jmx client accessing the model-specific types from a JVM being > managed running 2 different versions of JRE > > This raises an interesting question - if @CP is part of the standalone JMX > (e.g. javax.management.PropertyNames), would that issue exist? Alan and I > have asked ourselves if we need to bring back javax.management.PropertyNames > but it wasn't clear to us. Your feedback and any information/requirement > info from the past relevant to this will be valuable. I'll file a separate > RFE for it once the requirement becomes clear that the jmx/serviceability > team can follow up. > > I'd like to get the fix to eliminate the dependency into jdk8 separated > from this RFE. > > Thanks > Mandy From mandy.chung at oracle.com Thu Sep 13 22:25:18 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 Sep 2012 22:25:18 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> Message-ID: <5052BFBE.4010309@oracle.com> On 9/13/2012 2:59 PM, Eamonn McManus wrote: >>> If at all possible, it would be better to split out >>> ConstructorProperties into a separable dependency so that JMX could >>> depend on just that. The idea that a profile with JMX but not >>> JavaBeans is almost but not quite exactly like a profile with both >>> seems rather user-hostile. >> The current jdk modularization is being done that way. java.beans is >> split between the base module and the desktop module and >> ConstructorProperties is included in the base. We're working on addressing >> the split package issue so that the platform can be modularized cleanly. >> That's the motivation for this bug fix. > I'm not sure I fully understand. Are there no other cases where > packages are split across modules? Our goal is to remove all split packages. > I'm wondering how important it is > to avoid this particular split since it seems to me to introduce a > subtle irregularity into JMX that could make things hard for users of > the API. > > The cross-version scenarios you describe seem very unlikely since the > MXBean API and @ConstructorProperties were added to the JRE at the > same time. So I probably misunderstand the use cases for allowing any @ConstructorProperties annotation, regardless of what package. Can you elaborate on that? Thanks Mandy > > I don't think it would help much to introduce a new > @javax.management.PropertyNames or whatever, because you would still > have to support existing code that uses @ConstructorProperties. > > ?amonn > > > On 13 September 2012 14:45, Mandy Chung wrote: >> Hi Eamonn, >> >> Thanks for the review and the information. >> >> >> On 9/13/2012 9:48 AM, Eamonn McManus wrote: >>> If at all possible, it would be better to split out >>> ConstructorProperties into a separable dependency so that JMX could >>> depend on just that. The idea that a profile with JMX but not >>> JavaBeans is almost but not quite exactly like a profile with both >>> seems rather user-hostile. >> >> The current jdk modularization is being done that way. java.beans is >> split between the base module and the desktop module and >> ConstructorProperties is included in the base. We're working on addressing >> the split package issue so that the platform can be modularized cleanly. >> That's the motivation for this bug fix. >> >> >>> If it is not possible to make that separation then the method >>> CompositeBuilderViaConstructor.applicable should return immediately if >>> constructorPropertiesClass == null, with an explanation string like >>> "@ConstructorProperties annotation not available". That will produce a >>> better exception message than the "no constructor has >>> @ConstructorProperties annotation" that the code will produce as it >>> stands even if constructors do have that annotation. >> >> Good idea. I have fixed that. >> >>> On line 1161 you could write valueMethod.invoke(a) instead of >>> valueMethod.invoke(a, new Object[0]). >> >> Fixed and the updated webrev is at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198070/webrev.01/ >> >> >>> We faced a similar problem in the past where standalone JMX might be >>> running on a Java version that did not have >>> java.beans.ConstructorProperties. At that time we considered >>> specifying that any @ConstructorProperties annotation, regardless of >>> what package it came from, would have the same effect. Since you are >>> accessing the annotation by reflection anyway it might be time to >>> resuscitate this idea. Then users could at least insulate themselves >>> from no-JavaBeans breakage by using their own definition of >>> @ConstructorProperties. >> >> I see two scenarios: >> 1. the application being instrumented is running on an older version of >> JRE >> 2. the jmx client accessing the model-specific types from a JVM being >> managed running 2 different versions of JRE >> >> This raises an interesting question - if @CP is part of the standalone JMX >> (e.g. javax.management.PropertyNames), would that issue exist? Alan and I >> have asked ourselves if we need to bring back javax.management.PropertyNames >> but it wasn't clear to us. Your feedback and any information/requirement >> info from the past relevant to this will be valuable. I'll file a separate >> RFE for it once the requirement becomes clear that the jmx/serviceability >> team can follow up. >> >> I'd like to get the fix to eliminate the dependency into jdk8 separated >> from this RFE. >> >> Thanks >> Mandy From Alan.Bateman at oracle.com Fri Sep 14 06:46:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Sep 2012 14:46:04 +0100 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <5052BFBE.4010309@oracle.com> References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> <5052BFBE.4010309@oracle.com> Message-ID: <5053351C.5020702@oracle.com> On 14/09/2012 06:25, Mandy Chung wrote: > > : >> I'm not sure I fully understand. Are there no other cases where >> packages are split across modules? > > Our goal is to remove all split packages. Yes, as Mandy said, we want to keep things as clean as possible and that means aligning the modules on package boundaries. So far this has worked out quite well in our prototyping to date. By far the most problematic area in the Java SE APIs java.beans, it's just too tied into Applets, AWT, Swing, even XML. It's unfortunate that JMX uses it, particularly for use-cases such as small environments where one should be able install a "management" module to be able to remotely monitor or manage applications on the device. If JMX requires JavaBeans then it means needing to install a lot of things that might not make sense in that environment. At this point I think our only remaining hard dependency on JavaBeans from JMX is the ConstructorProperties annotation, you might remember we put in a helper to identify getter methods when the beans Introspector is not available. For the JMX Remote API then I think specification changes will eventually be required to allow the RMI-IIOP transport be optional (this is something you will probably have an opinion on). This is another cases where we have a split-package issue, this time due to the CORBA stub/tie classes that are in javax.management.remote.rmi (something that the IDL Mapping specification requires if I remember correctly). My main observation on ConstructorProperties is that any code that uses it will require the module containing ConstructorProperties to be present when compiling that code. If the module declaration is setup so that the module containing the annotation type is required to be present at runtime then I think we are okay and Mandy's changes amount to a no-op. If the application is not using the annotation then it doesn't matter if ConstructorProperties is present or not and I think the proposed changes are benign. So my view is that the onus on anyone using ConstructorProperties needs to ensure that they have their module declaration right, otherwise their code will not compile or run. Mandy - I've looked at webrev.01 and the changes look okay to me. The only thing is that the value method may throw a RuntimeException or Error and it would be good to propagate those rather than throwing an AssertionError. -Alan. From eamonn at mcmanus.net Sun Sep 16 19:07:12 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Sun, 16 Sep 2012 19:07:12 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <5053351C.5020702@oracle.com> References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> <5052BFBE.4010309@oracle.com> <5053351C.5020702@oracle.com> Message-ID: OK, well if you've managed to align modules on package boundaries everywhere else then congratulations, because that can't have been easy! Certainly a relatively minor feature like ConstructorProperties shouldn't be the only obstacle to completing that split. If we had known that this question would arise when we were defining ConstructorProperties I feel sure we would have put it somewhere else, perhaps a new package on its own like java.beans.annotations, or perhaps an existing package like javax.annotation (though I think the process for that one would have been very hard). I do feel that if, at the end of the exercise, it turns out that there is a nontrivial number of other split packages then ConstructorProperties should be put back the way it was. And, regardless, a JMX spec change allowing ConstructorProperties annotations from any package, as I suggested earlier, would clarify the situation for users. As it is, they are likely to want to avoid ConstructorProperties just in case their code might end up on a profile that doesn't include it. That would be unfortunate, because the code one has to write to achieve the same effect by defining from(CompositeData) is nasty. (Although I have reviewed this change, I would rather not be mentioned in the Reviewed-by field.) ?amonn On 14 September 2012 06:46, Alan Bateman wrote: > On 14/09/2012 06:25, Mandy Chung wrote: >> >> >> : >>> >>> I'm not sure I fully understand. Are there no other cases where >>> packages are split across modules? >> >> >> Our goal is to remove all split packages. > > Yes, as Mandy said, we want to keep things as clean as possible and that > means aligning the modules on package boundaries. So far this has worked out > quite well in our prototyping to date. By far the most problematic area in > the Java SE APIs java.beans, it's just too tied into Applets, AWT, Swing, > even XML. It's unfortunate that JMX uses it, particularly for use-cases such > as small environments where one should be able install a "management" module > to be able to remotely monitor or manage applications on the device. If JMX > requires JavaBeans then it means needing to install a lot of things that > might not make sense in that environment. > > At this point I think our only remaining hard dependency on JavaBeans from > JMX is the ConstructorProperties annotation, you might remember we put in a > helper to identify getter methods when the beans Introspector is not > available. For the JMX Remote API then I think specification changes will > eventually be required to allow the RMI-IIOP transport be optional (this is > something you will probably have an opinion on). This is another cases where > we have a split-package issue, this time due to the CORBA stub/tie classes > that are in javax.management.remote.rmi (something that the IDL Mapping > specification requires if I remember correctly). > > My main observation on ConstructorProperties is that any code that uses it > will require the module containing ConstructorProperties to be present when > compiling that code. If the module declaration is setup so that the module > containing the annotation type is required to be present at runtime then I > think we are okay and Mandy's changes amount to a no-op. If the application > is not using the annotation then it doesn't matter if ConstructorProperties > is present or not and I think the proposed changes are benign. So my view is > that the onus on anyone using ConstructorProperties needs to ensure that > they have their module declaration right, otherwise their code will not > compile or run. > > Mandy - I've looked at webrev.01 and the changes look okay to me. The only > thing is that the value method may throw a RuntimeException or Error and it > would be good to propagate those rather than throwing an AssertionError. > > -Alan. From mandy.chung at oracle.com Tue Sep 18 15:05:11 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Sep 2012 15:05:11 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> <5052BFBE.4010309@oracle.com> <5053351C.5020702@oracle.com> Message-ID: <5058F017.60705@oracle.com> Eamonn, I filed a RFE that the serviceability team can follow up your suggestion: 7199353: Allow ConstructorProperties annotation from any package Alan - I modified the fix to throw InternalError instead of AssertionError. Thanks for both of your review and I'll only list alanb in the Reviewed-by list per Eamonn's request. Thanks Mandy On 9/16/2012 7:07 PM, Eamonn McManus wrote: > OK, well if you've managed to align modules on package boundaries > everywhere else then congratulations, because that can't have been > easy! Certainly a relatively minor feature like ConstructorProperties > shouldn't be the only obstacle to completing that split. If we had > known that this question would arise when we were defining > ConstructorProperties I feel sure we would have put it somewhere else, > perhaps a new package on its own like java.beans.annotations, or > perhaps an existing package like javax.annotation (though I think the > process for that one would have been very hard). > > I do feel that if, at the end of the exercise, it turns out that there > is a nontrivial number of other split packages then > ConstructorProperties should be put back the way it was. And, > regardless, a JMX spec change allowing ConstructorProperties > annotations from any package, as I suggested earlier, would clarify > the situation for users. As it is, they are likely to want to avoid > ConstructorProperties just in case their code might end up on a > profile that doesn't include it. That would be unfortunate, because > the code one has to write to achieve the same effect by defining > from(CompositeData) is nasty. > > (Although I have reviewed this change, I would rather not be mentioned > in the Reviewed-by field.) > > ?amonn > > > On 14 September 2012 06:46, Alan Bateman wrote: >> On 14/09/2012 06:25, Mandy Chung wrote: >>> >>> : >>>> I'm not sure I fully understand. Are there no other cases where >>>> packages are split across modules? >>> >>> Our goal is to remove all split packages. >> Yes, as Mandy said, we want to keep things as clean as possible and that >> means aligning the modules on package boundaries. So far this has worked out >> quite well in our prototyping to date. By far the most problematic area in >> the Java SE APIs java.beans, it's just too tied into Applets, AWT, Swing, >> even XML. It's unfortunate that JMX uses it, particularly for use-cases such >> as small environments where one should be able install a "management" module >> to be able to remotely monitor or manage applications on the device. If JMX >> requires JavaBeans then it means needing to install a lot of things that >> might not make sense in that environment. >> >> At this point I think our only remaining hard dependency on JavaBeans from >> JMX is the ConstructorProperties annotation, you might remember we put in a >> helper to identify getter methods when the beans Introspector is not >> available. For the JMX Remote API then I think specification changes will >> eventually be required to allow the RMI-IIOP transport be optional (this is >> something you will probably have an opinion on). This is another cases where >> we have a split-package issue, this time due to the CORBA stub/tie classes >> that are in javax.management.remote.rmi (something that the IDL Mapping >> specification requires if I remember correctly). >> >> My main observation on ConstructorProperties is that any code that uses it >> will require the module containing ConstructorProperties to be present when >> compiling that code. If the module declaration is setup so that the module >> containing the annotation type is required to be present at runtime then I >> think we are okay and Mandy's changes amount to a no-op. If the application >> is not using the annotation then it doesn't matter if ConstructorProperties >> is present or not and I think the proposed changes are benign. So my view is >> that the onus on anyone using ConstructorProperties needs to ensure that >> they have their module declaration right, otherwise their code will not >> compile or run. >> >> Mandy - I've looked at webrev.01 and the changes look okay to me. The only >> thing is that the value method may throw a RuntimeException or Error and it >> would be good to propagate those rather than throwing an AssertionError. >> >> -Alan. From Alan.Bateman at oracle.com Wed Sep 19 02:01:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Sep 2012 10:01:13 +0100 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <5058F017.60705@oracle.com> References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> <5052BFBE.4010309@oracle.com> <5053351C.5020702@oracle.com> <5058F017.60705@oracle.com> Message-ID: <505989D9.9070803@oracle.com> On 18/09/2012 23:05, Mandy Chung wrote: > Eamonn, > > I filed a RFE that the serviceability team can follow up your suggestion: > 7199353: Allow ConstructorProperties annotation from any package > > Alan - I modified the fix to throw InternalError instead of > AssertionError. It's great to have this static dependency removed. I should have been clearer in my comment about the AssertionError. What I meant is that I think we should looking at the InvocationTargetException's cause, and if an error or runtime exception then we should re-throw it rather than throwing AssertionError (or InternalError as it is now). That will making it easier to diagnose cases where the value method throws an error or a runtime exception. -Alan From jaroslav.bachorik at oracle.com Wed Sep 19 05:39:44 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 19 Sep 2012 14:39:44 +0200 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently Message-ID: <5059BD10.40801@oracle.com> The ExecutorTest.java fails in cca. 30-40% of runs with NPE in the part testing IIOP connection. The failure is caused by the JMX notification processing - ideally, once the RMIConnector is closed the client JMX notification processing should quit as well and should not try to fetch any more notifications over the already closed remote connection. But achieving this is particularly difficult mostly due to the synchronous nature of the fetchNotifications() method. The RMIConnector can get closed after the fetchNotifications() method was entered but before attempting to invoke its remote counterpart. At this moment the remote connection is effectively closed and any attempt to use it will throw an exception - a NPE in this case. The patch does not solve the core problem as it would probably require significant changes in the client JMX notification processing - rather it targets the NPE which becomes expected when the RMIConnector is closed. This is handled by adding a new "catch (NullPointerException)" block and, inside that block, checking for the connection state and rethrowing the exception in case the connection is still open (RMIConnector is started). For any other state of RMIConnector the NPE is ignored. The webrev is located at: http://washi.ru.oracle.com/jb198685/webrev/7195779 -JB- From Alan.Bateman at oracle.com Wed Sep 19 06:06:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Sep 2012 14:06:05 +0100 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently In-Reply-To: <5059BD10.40801@oracle.com> References: <5059BD10.40801@oracle.com> Message-ID: <5059C33D.7@oracle.com> On 19/09/2012 13:39, Jaroslav Bachorik wrote: > The ExecutorTest.java fails in cca. 30-40% of runs with NPE in the part > testing IIOP connection. > > The failure is caused by the JMX notification processing - ideally, once > the RMIConnector is closed the client JMX notification processing should > quit as well and should not try to fetch any more notifications over the > already closed remote connection. But achieving this is particularly > difficult mostly due to the synchronous nature of the > fetchNotifications() method. The RMIConnector can get closed after the > fetchNotifications() method was entered but before attempting to invoke > its remote counterpart. At this moment the remote connection is > effectively closed and any attempt to use it will throw an exception - a > NPE in this case. > > The patch does not solve the core problem as it would probably require > significant changes in the client JMX notification processing - rather > it targets the NPE which becomes expected when the RMIConnector is > closed. This is handled by adding a new "catch (NullPointerException)" > block and, inside that block, checking for the connection state and > rethrowing the exception in case the connection is still open > (RMIConnector is started). For any other state of RMIConnector the NPE > is ignored. > > The webrev is located at: http://washi.ru.oracle.com/jb198685/webrev/7195779 > This webrev looks to be Oracle internal so folks on this list will not be able to look at it. In any case, I'm not sure that catching the NPE is a good idea as it seems to be masking the real problem. At the lower level then would it be possible to have an IOException thrown if the connection is closed? -Alan. From jaroslav.bachorik at oracle.com Wed Sep 19 06:16:35 2012 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 19 Sep 2012 15:16:35 +0200 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently In-Reply-To: <5059C33D.7@oracle.com> References: <5059BD10.40801@oracle.com> <5059C33D.7@oracle.com> Message-ID: <5059C5B3.6020808@oracle.com> On Wed 19 Sep 2012 03:06:05 PM CEST, Alan Bateman wrote: > On 19/09/2012 13:39, Jaroslav Bachorik wrote: >> The ExecutorTest.java fails in cca. 30-40% of runs with NPE in the part >> testing IIOP connection. >> >> The failure is caused by the JMX notification processing - ideally, once >> the RMIConnector is closed the client JMX notification processing should >> quit as well and should not try to fetch any more notifications over the >> already closed remote connection. But achieving this is particularly >> difficult mostly due to the synchronous nature of the >> fetchNotifications() method. The RMIConnector can get closed after the >> fetchNotifications() method was entered but before attempting to invoke >> its remote counterpart. At this moment the remote connection is >> effectively closed and any attempt to use it will throw an exception - a >> NPE in this case. >> >> The patch does not solve the core problem as it would probably require >> significant changes in the client JMX notification processing - rather >> it targets the NPE which becomes expected when the RMIConnector is >> closed. This is handled by adding a new "catch (NullPointerException)" >> block and, inside that block, checking for the connection state and >> rethrowing the exception in case the connection is still open >> (RMIConnector is started). For any other state of RMIConnector the NPE >> is ignored. >> >> The webrev is located at: >> http://washi.ru.oracle.com/jb198685/webrev/7195779 >> > This webrev looks to be Oracle internal so folks on this list will not > be able to look at it. Ok, I am attaching the change (webrev.zip attachment seems to be too big for the mailing list): --- old/src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java 2012-09-19 14:23:56.966032400 +0200 +++ new/src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java 2012-09-19 14:23:56.814032403 +0200 @@ -594,6 +594,18 @@ } return nr; + } catch (NullPointerException e) { + synchronized(ClientNotifForwarder.this) { + if (state == STARTED) { + throw e; + } + /* When the attached RMIConnector is detached a NPE + can occur since the remote connection closes in the middle + of fetchNotifs() execution. + The NPE can be safely ignored in that case. + */ + return null; + } } catch (ClassNotFoundException e) { logger.trace("NotifFetcher.fetchNotifs", e); return fetchOneNotif(); > > In any case, I'm not sure that catching the NPE is a good idea as it > seems to be masking the real problem. At the lower level then would it I don't like ignoring an exception as well. But fixing the processing logic will take substantially longer time as I am not really familiar with the code. Perhaps adding the test to ProblemList.txt would be appropriate then? > be possible to have an IOException thrown if the connection is closed? 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. > > -Alan. > > From Alan.Bateman at oracle.com Wed Sep 19 06:39:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Sep 2012 14:39:16 +0100 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently In-Reply-To: <5059C5B3.6020808@oracle.com> References: <5059BD10.40801@oracle.com> <5059C33D.7@oracle.com> <5059C5B3.6020808@oracle.com> Message-ID: <5059CB04.30107@oracle.com> 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 From mandy.chung at oracle.com Wed Sep 19 09:23:20 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Sep 2012 09:23:20 -0700 Subject: jmx-dev Review Request: 7198070 Eliminate static dependency from JMX to java.beans.ConstructorProperties In-Reply-To: <505989D9.9070803@oracle.com> References: <5051FFD5.8070608@oracle.com> <505253EF.6060309@oracle.com> <5052BFBE.4010309@oracle.com> <5053351C.5020702@oracle.com> <5058F017.60705@oracle.com> <505989D9.9070803@oracle.com> Message-ID: <5059F178.8020609@oracle.com> On 9/19/2012 2:01 AM, Alan Bateman wrote: > On 18/09/2012 23:05, Mandy Chung wrote: >> Eamonn, >> >> I filed a RFE that the serviceability team can follow up your >> suggestion: >> 7199353: Allow ConstructorProperties annotation from any package >> >> Alan - I modified the fix to throw InternalError instead of >> AssertionError. > It's great to have this static dependency removed. I should have been > clearer in my comment about the AssertionError. What I meant is that I > think we should looking at the InvocationTargetException's cause, and > if an error or runtime exception then we should re-throw it rather > than throwing AssertionError (or InternalError as it is now). That > will making it easier to diagnose cases where the value method throws > an error or a runtime exception. Thanks for clarifying that. I agree it's better to rethrow the InvocationTargetException's cause if the value method throws an error or runtime exception. I can file a new CR and clean that up later. Mandy From eamonn at mcmanus.net Thu Sep 20 09:02:47 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Thu, 20 Sep 2012 09:02:47 -0700 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently In-Reply-To: <5059CB04.30107@oracle.com> References: <5059BD10.40801@oracle.com> <5059C33D.7@oracle.com> <5059C5B3.6020808@oracle.com> <5059CB04.30107@oracle.com> Message-ID: >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 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 From Alan.Bateman at oracle.com Fri Sep 21 03:52:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Sep 2012 11:52:27 +0100 Subject: jmx-dev Review Request: 7195779 javax/management/remote/mandatory/threads/ExecutorTest.java fail intermittently In-Reply-To: References: <5059BD10.40801@oracle.com> <5059C33D.7@oracle.com> <5059C5B3.6020808@oracle.com> <5059CB04.30107@oracle.com> Message-ID: <505C46EB.60800@oracle.com> On 20/09/2012 17:02, Eamonn McManus wrote: > 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. I think this is what I would do to, even though it means going into the corba repository as that is there the stub generator is. I should say that I don't violently object to Jaroslav's patch, it's just that it is an ugly workaround. > 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. > I don't know if the rmi-iiop connector was ever used much but since it seems to be required by the JMX Remote API spec then I think we should continue to test it. As I think I mentioned in another mail recently, I think we have to look at making this transport optional as it's painful to have the CORBA tie/stub classes in javax.management.remote.rmi. I don't what to hijack Jaroslav's thread to discuss that, that's a topic for another thread. -Alan