RFR for JDK-8030844:sun/rmi/rmic/classpath/RMICClassPathTest.java timeout in same binaries run

Stuart Marks stuart.marks at oracle.com
Thu Feb 13 23:23:08 UTC 2014

Great, pushed:


Having the full changeset in the webrev was quite convenient. I was able to "hg 
import" it directly.


On 2/12/14 7:21 PM, Tristan Yan wrote:
> Thank you Stuart
> This is a very nice tutorial. I did try both ways. Adopt your fix doesn't seem
> work for me. It still doesn't generate changeset. But without -r option works.
> http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.02/
> Could you push it for me?
> Tristan
> On 02/13/2014 03:48 AM, Stuart Marks wrote:
>> Hi Tristan,
>> Changes look good. Unfortunately the webrev doesn't contain an actual
>> changeset; it just contains a patch. In the webrev header there is the line
>> "Patch of Changes". Instead it should say "Changeset". Like this one:
>> http://cr.openjdk.java.net/~smarks/reviews/7900311/webrev.1/
>> Unfortunately webrev doesn't always produce an actual changeset, in particular
>> it doesn't if you use webrev -r.
>> (My example webrev above is a patch that changes webrev to generate the
>> changeset even with -r. It hasn't been pushed yet; possibly it will later
>> today. Or you can apply my webrev changeset to your local webrev.)
>> Or, you can just run webrev without -r and it should check "hg outgoing" to
>> determine the changesets used in generating the webrev, which does place the
>> changeset into the webrev.
>> Can you regenerate the webrev so that it includes the actual changeset? Sorry,
>> this is a small thing, but as someone who is sponsoring changesets, I'd
>> appreciate an actual changeset in the webrev instead of having to construct
>> one manually. I think other sponsors would appreciate this too.
>> s'marks
>> On 2/11/14 6:59 PM, Tristan Yan wrote:
>>> Thank you Stuart
>>> http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.01/
>>> Regards
>>> Tristan
>>> On Feb 12, 2014, at 10:06 AM, Stuart Marks <stuart.marks at oracle.com
>>> <mailto:stuart.marks at oracle.com>> wrote:
>>>> Hi, yes, I'll take this one.
>>>> It's slightly odd that this is creating filenames that already have "/" in
>>>> them (as opposed to File.separator) but since these files don't actually have
>>>> to exist, I suppose it doesn't really matter.
>>>> I'm not convinced that we actually have any evidence that /home/~user is
>>>> really causing the hang/timeout (either caused by the automounter hanging on
>>>> /home or LDAP or other nameservice lookup on ~user), but this is harmless, and
>>>> it'll fix the problem on the off chance that this really is the root cause.
>>>> Tristan, please update the test's @bug tag to add 8030844, create a changeset,
>>>> and create a webrev with the changeset in it (as opposed to a bare patch).
>>>> I'll then push it for you.
>>>> s'marks
>>>> On 2/10/14 4:08 AM, Alan Bateman wrote:
>>>>> On 10/02/2014 10:57, Tristan Yan wrote:
>>>>>> Ping: Can anyone give a review on this.
>>>>>> Thank you
>>>>>> Tristan
>>>>> Changing the test so that it doesn't try to /home/~user seems reasonable to
>>>>> me.
>>>>> Stuart - I see you've been sponsoring Tristan's updates to the RMI tests. Are
>>>>> you going to take this one too?
>>>>> -Alan
>>>>>> On Feb 6, 2014, at 5:13 PM, Tristan Yan<tristan.yan at oracle.com
>>>>>> <mailto:tristan.yan at oracle.com>>  wrote:
>>>>>>> Hi All
>>>>>>> Please help to review a simple fix for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8030844
>>>>>>> http://cr.openjdk.java.net/~tyan/JDK-8030844/webrev.00/.
>>>>>>> Description:
>>>>>>> Change replace a “/home/~user" folder with an test source path. Folder
>>>>>>> “/home/~user” cause some problem whenever something wrong with the automount
>>>>>>> filesystem or an username lookup problem.
>>>>>>> Thank you
>>>>>>> Tristan

More information about the core-libs-dev mailing list