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

[Stuart Marks]

Great, pushed:

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2cecdf7fbc90

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

s'marks

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
>>>>>
>>>
>