Protocol version of Attach API

David Holmes david.holmes at oracle.com
Wed Feb 27 05:56:33 UTC 2019


On 27/02/2019 3:51 pm, 臧琳 wrote:
> Dear David, Yasumasa,
>         I think it is hard to know how long the buffer is passed from socket without changing the info of the message from the receiver side.
>         So how about when str_count reach to 3, we test it with non_blocking read?

Seems reasonable, but are we guaranteed to immediately see the complete 
next arg?

David

> 
> Cheers,
> Lin
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Wednesday, February 27, 2019 1:44 PM
>> To: Yasumasa Suenaga <yasuenag at gmail.com>; 臧琳 <zanglin5 at jd.com>
>> Cc: serviceability-dev at openjdk.java.net
>> Subject: Re: Protocol version of Attach API
>>
>> Hi Yasumasa,
>>
>> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote:
>>> Hi Lin,
>>>
>>> My proposal is a just idea, so you need to tweak it.
>>>
>>> AttachListener receives raw command.
>>> For example, jcmd is `jcmd\0<arg strings>`. Please see
>>> HotSpotVirtualMachine and extended classes.
>>>
>>> In case of jcmd, I guess AttachListener will receive message
>>> `<version>\0jcmd\0<args>\0\0\0` (I did not check it well).
>>> So I guess we can add '\0' when `str_count` does not reach to maximum.
>>
>> I don't see how this approach can work. You have to know how many
>> arguments are coming in the "packet", but that information is not available in
>> the current Linux implementation.Without it you can't know when to stop
>> calling read().
>>
>> The protocol would need to be changed to send the "packet" size, but that's
>> not compatible with older JDKs.
>>
>> Otherwise I think we have no choice but to use a non-blocking read ...
>> though I'm still unsure if you can know for certain that you've reached the
>> end of the "packet" ...
>>
>> Thanks,
>> David
>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2019/02/27 11:50, zanglin5 at jd.com wrote:
>>>> Dear  Yasumasa,
>>>>     The fix you mentioned seems not work as expected.
>>>>     I have done an experiment that use jdk1.8's "jcmd <pid> help" to
>>>> attach to latest jdk.
>>>>     it seem the whole "jcmd <pid> help"  buffer is not
>>>>     read completely at one time. in my case it is "jcmd", "<pid>",
>>>> "help", and then block at while().
>>>>     After applied your change, it seems only the "jcmd" is processed,
>>>> the "<pid>", "help" is replaced by '\0'.
>>>>
>>>> BRs,
>>>> Lin
>>>>


More information about the serviceability-dev mailing list