PING: RFR: 8209790: SA tools not providing option to connect to debug server
Chris Plummer
chris.plummer at oracle.com
Mon Jul 8 05:24:43 UTC 2019
Hi Yasumasa,
I think it should be "[<id>@]<host>". Angle brackets are used to
indicate non-literal values (ones to be replaced by something the user
chooses), but the '@' is a literal value, so should not be enclosed in
the angle brackets.
Also one minor thing. You ended up duplicating the //:
60 // // --connect <[id@]host>
thanks,
Chris
On 7/6/19 5:55 PM, Yasumasa Suenaga wrote:
> Hi Chris,
>
> Thank you for your advise.
> I uploaded new webrev. How about this?
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.04/
>
> I replaced "server" to "host" as you said.
> Other comments from you also have been fixed in it.
>
> For example, `jhsdb jstack --help` shows as below:
>
> ```
> $ jhsdb jstack --help
> --locks To print java.util.concurrent locks.
> --mixed To print both Java and native frames
> (mixed mode).
> --pid <pid> To attach to and operate on the given live
> process.
> --core <corefile> To operate on the given core file.
> --exe <executable for corefile>
> --connect <[id@]host> To connect to a remote debug server
> (sadebugd).
>
> The --core and --exe options must be set together to give the core
> file, and associated executable, to operate on. They can use
> absolute or relative paths.
> The --pid option can be set to operate on a live process.
> The --connect option can be set to connect to a debug server
> (sadebugd).
> <--core --exe> and <--pid> and <--connect> are exclusive.
>
> Examples: jhsdb jstack --pid 1234
> or jhsdb jstack --core ./core.1234 --exe ./myexe
> or jhsdb jstack --connect debugserver
> or jhsdb jstack --connect id at debugserver
> ```
>
> If you are ok, I will reopen CSR (JDK-8224979).
>
>
> Yasumasa
>
>
> On 2019/07/06 6:26, Chris Plummer wrote:
>> On 7/4/19 3:53 PM, Yasumasa Suenaga wrote:
>>> Hi Chris,
>>>
>>> On 2019/07/05 4:24, Chris Plummer wrote:
>>>> Hi Yasumasa,
>>>>
>>>> On 7/4/19 5:30 AM, Yasumasa Suenaga wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thank you for your review.
>>>>>
>>>>> On 2019/07/04 8:07, Chris Plummer wrote:
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> Overall these changes look good, but I think there is a bit of
>>>>>> cleanup still needed.
>>>>>>
>>>>>> You've changed the indentation of the help to always have a few
>>>>>> spaces before the /t. If you are going to do this, then perhaps
>>>>>> you don't need the /t anymore.
>>>>>
>>>>> Ok, I will replace '\t' to whitespace.
>>>>>
>>>>>
>>>>>> There are 3 checks for "remote != null". Shouldn't they be
>>>>>> "remote != NO_REMOTE"?
>>>>>
>>>>> I will fix them.
>>>>>
>>>>>
>>>>>> The old jstack help output is a bit more informative than your
>>>>>> output:
>>>>>>
>>>>>> jstack [-m] [-l] [server_id@]<remote server IP or hostname>
>>>>>> (to connect to a remote debug server)
>>>>>>
>>>>>> vs
>>>>>>
>>>>>> --connect <[id@]server> To operate on the remote debug server.
>>>>>>
>>>>>> More specifically, you replaced <remote server IP or hostname>
>>>>>> with "server". I think the former is a bit more self explanatory.
>>>>>
>>>>> Exactly, but it is too long to show on the console.
>>>>> So I used short word: server.
>>>>>
>>>>> If we can ignore long line, or can add newline (\n) on help message,
>>>>> I can change it. What do you think?
>>>> I don't see why not. Isn't there already help output that relies on
>>>> newlines?
>>>
>>> As you can see on the CSR (JDK-8224979), format of jhsdb help
>>> messages is:
>>>
>>> <option name> <blank (includes tab)> <description>
>>>
>>> Thus I think long option / description is not comfortable.
>>> If we need to describe more, I think we should write it as below:
>>>
>>> --connect <[server-id@]remote server IP or hostname>
>>> To connect to a remote debug server.
>> Hi Yasumasa,
>>
>> We already have multiline examples like:
>>
>> |--pid <pid> To attach to and operate on the given live process.
>>
>> Is your concerned that the long option name will extend into the
>> columns where the description normally is? If so, you can start the
>> description on a new line as you suggest, or maybe come up with a
>> different name for the option that isn't quite as long. My main
>> objection to just saying "server" is it in no way conveys we are
>> talking about an IP host. Even just saying <host> would be better. It
>> is also more correct since the host isn't necessarily what someone
>> would consider to be a server (it could just be someone's desktop).
>> <server-id> on the other hand is the correct term because we are
>> talking about the id of the debug server running on a particular host.
>>
>> Chris
>> |
>>
More information about the serviceability-dev
mailing list