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

[Tristan Yan]

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