Another solution I can figure out is try to add timeout for socket read. I will also investigate whether is works.
Cheers, Lin > -----Original Message----- > From: 臧琳 > Sent: Wednesday, February 27, 2019 1:52 PM > To: 'David Holmes' <[email protected]>; Yasumasa Suenaga > <[email protected]> > Cc: [email protected] > Subject: RE: Protocol version of Attach API > > 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? > > > Cheers, > Lin > > -----Original Message----- > > From: David Holmes <[email protected]> > > Sent: Wednesday, February 27, 2019 1:44 PM > > To: Yasumasa Suenaga <[email protected]>; 臧琳 <[email protected]> > > Cc: [email protected] > > 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, [email protected] 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 > > >>
