@openjdk.java.net [email protected]
Subject: Re: Protocol version of Attach API
PS. This should be sent out in a proper RFR thread for JDK-8219721
Thanks,
David
On 4/03/2019 5:22 pm, David Holmes wrote:
> Hi Lin,
>
> I think this is fine to address the problem that was i
h 1, 2019 12:22 PM
To: Yasumasa Suenaga ; 臧琳
Cc: [email protected]
[email protected]
Subject: Re: Protocol version of Attach API
On 1/03/2019 1:54 pm, Yasumasa Suenaga wrote:
Hi,
I agree with David. I think we should backout 8215622.
Note that I conceded that if Lin
From: David Holmes
Sent: Monday, March 4, 2019 3:22:34 PM
To: 臧琳; Yasumasa Suenaga; Hohensee, Paul
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Hi Lin,
I think this is fine to address the
change,
please let me know.
Thanks for all of your help and suggestions.
BRs,
Lin
-Original Message-
From: David Holmes
Sent: Friday, March 1, 2019 12:22 PM
To: Yasumasa Suenaga ; 臧琳
Cc: [email protected] [email protected]
Subject: Re: Protoc
-Original Message-
> From: David Holmes
> Sent: Friday, March 1, 2019 12:22 PM
> To: Yasumasa Suenaga ; 臧琳
> Cc: [email protected] [email protected]
>
> Subject: Re: Protocol version of Attach API
>
> On 1/03/2019 1:54 pm, Yas
openjdk.java.net [email protected]
Subject: Re: Protocol version of Attach API
Hi Lin,
On 28/02/2019 7:30 pm, 臧琳 wrote:
Hi David,
I am a little confused, do you think it is proper to made the patch as a
fix of https://bugs.openjdk.java.net/browse/JDK-8219721 so that
3.
>
> Thanks,
> David
>
> > Thanks,
> > LIn
> >
> > From: 臧琳
> > Sent: Thursday, February 28, 2019 4:50:12 PM
> > To: David Holmes; Yasumasa Suenaga
> > Cc: [email protected] servi
ev.
Thanks.
Lin
From: David Holmes
Sent: Thursday, February 28, 2019 7:55:01 PM
To: 臧琳; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Hi Lin,
On 28/02/2019 7:30 pm, 臧琳 w
ubject: Re: Protocol version of Attach API
I'd like to propose an alternative approach, namely, we could add another
argument parsing feature on top of the old functionality intact and leave the
latter intact. We currently have just a single constant
AttachOperation::arg_count_max, which th
ga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Dear All,
I have tried simply recover the max argument count makes jmap -histo
works and also makes the compatibility works fine.
Following are the changes I made:
I'd like to propose an alternative approach, namely, we could add another
argument parsing feature on top of the old functionality intact and leave the
latter intact. We currently have just a single constant
AttachOperation::arg_count_max, which the patch changed from 3 to 4. We could
leave it
12 PM
To: David Holmes; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Dear All,
I have tried simply recover the max argument count makes jmap -histo
works and also makes the compatibility works
a random name
Random rnd = new Random();
Thanks,
Lin
From: 臧琳
Sent: Thursday, February 28, 2019 3:24:52 PM
To: David Holmes; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: RE: Protocol version of At
t [email protected]
>
> Subject: Re: Protocol version of Attach API
>
> Hi Lin,
>
> On 28/02/2019 4:49 pm, 臧琳 wrote:
> > Hi David,
> > Your are right and thanks for pointing it out. when I worte that
> > patch, I
> was considering imp
in
their own RFR thread.
Thanks,
David
BRs,
Lin
From: David Holmes
Sent: Thursday, February 28, 2019 12:59:28 PM
To: 臧琳; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of
, February 28, 2019 12:59:28 PM
To: 臧琳; Yasumasa Suenaga
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Sorry I'm going to pick up on the rollback and re-do option here as I
just had a closer look at jmap. Given jmap
es; [email protected]
<mailto:[email protected]>
Subject: Re: Protocol version of Attach API
Hi Lin,
I think we need to research more about this.
IMHO we need to match length of arguments between
server (AttachListener) and client (s
uffer was too small, impossible!");
> buf[max_len - 1] = '\0';
> if (n == -1) {
Thanks,
Yasumasa
> Thanks.
> Lin
>
> ____________________
> From: Yasumasa Suenaga mailto:yasue.
@openjdk.java.net
[email protected]
Subject: Re: Protocol version of Attach API
2019年2月28日(木) 0:04 臧琳 mailto:[email protected]>>:
Dear Suenaga,
Thanks for your reviewing. I will try to refine the patch.
For the argument length you mentioned, do you mean the "arg
; BRs,
> Lin
>
> From: Yasumasa Suenaga
> Sent: Wednesday, February 27, 2019 8:10:14 PM
> To: 臧琳
> Cc: David Holmes; [email protected]
> Subject: Re: Protocol version of Attach API
>
> Hi Lin,
>
> I
ll. so 00 may not indicate
it reach the end.
BRs,
Lin
From: Yasumasa Suenaga
Sent: Wednesday, February 27, 2019 8:10:14 PM
To: 臧琳
Cc: David Holmes; [email protected]
Subject: Re: Protocol version of Attach API
Hi Lin,
I think we need to
ebruary 27, 2019 15:15
To: David Holmes; 臧琳
Cc: [email protected]
Subject: Re: Protocol version of Attach API
On 2019/02/27 15:59, David Holmes wrote:
On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote:
Hi,
Buffer size for receiving packets from client is determined at [1].
Maximum
sday, February 27, 2019 15:15
To: David Holmes; 臧琳
Cc: [email protected]
Subject: Re: Protocol version of Attach API
On 2019/02/27 15:59, David Holmes wrote:
> On 27/02/2019 4:10 pm, Yasumasa Suenaga wrote:
>> Hi,
>>
>> Buffer size for receiving packets from client is
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' ; Yasumasa Suenaga
Cc: [email protected]
Subject: RE: Protoc
ate whether is works.
Cheers,
Lin
-Original Message-
From: 臧琳
Sent: Wednesday, February 27, 2019 1:52 PM
To: 'David Holmes' ; Yasumasa Suenaga
Cc: [email protected]
Subject: RE: Protocol version of Attach API
Dear David, Yasumasa,
I think it is hard
heers,
Lin
-Original Message-
From: 臧琳
Sent: Wednesday, February 27, 2019 1:52 PM
To: 'David Holmes' ; Yasumasa Suenaga
Cc: [email protected]
Subject: RE: Protocol version of Attach API
Dear David, Yasumasa,
I think it is hard to know how long the buffer i
reasonable, but are we guaranteed to immediately see the complete
next arg?
David
Cheers,
Lin
-Original Message-
From: David Holmes
Sent: Wednesday, February 27, 2019 1:44 PM
To: Yasumasa Suenaga ; 臧琳
Cc: [email protected]
Subject: Re: Protocol version of Attach API
Hi
> 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_
age-
> From: David Holmes
> Sent: Wednesday, February 27, 2019 1:44 PM
> To: Yasumasa Suenaga ; 臧琳
> Cc: [email protected]
> Subject: Re: Protocol version of Attach API
>
> Hi Yasumasa,
>
> On 27/02/2019 1:05 pm, Yasumasa Suenaga wrote:
> > Hi Lin
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`. Please see
HotSpotVirtualMachine and extended classes.
In case of jcmd, I guess AttachListener will re
Hi Lin,
My proposal is a just idea, so you need to tweak it.
AttachListener receives raw command.
For example, jcmd is `jcmd\0`. Please see HotSpotVirtualMachine
and extended classes.
In case of jcmd, I guess AttachListener will receive message
`\0jcmd\0\0\0\0` (I did not check it well).
So I
hanks,
Lin
From: serviceability-dev on
behalf of David Holmes
Sent: Wednesday, February 27, 2019 10:35:34 AM
To: Alex Menkov; Chris Plummer; Erik Gahlin; [email protected]
Subject: Re: Protocol version of Attach API
On 27/02/2019 8:48 am, Alex Menkov wrote:
kov
Sent: Wednesday, February 27, 2019 6:48:41 AM
To: David Holmes; Chris Plummer; Erik Gahlin;
[email protected]
Subject: Re: Protocol version of Attach API
On 02/26/2019 13:58, David Holmes wrote:
> On 27/02/2019 7:50 am, Chris Plummer wrote:
>> On 2/26/19 1:30 PM,
On 27/02/2019 8:48 am, Alex Menkov wrote:
On 02/26/2019 13:58, David Holmes wrote:
On 27/02/2019 7:50 am, Chris Plummer wrote:
Also want to point out that this issue might be two-way: 8 can't
attach to 13 and 13 may have issues attaching to 8 (what happens
with the extra argument that is sent
On 02/26/2019 13:58, David Holmes wrote:
On 27/02/2019 7:50 am, Chris Plummer wrote:
On 2/26/19 1:30 PM, David Holmes wrote:
On 27/02/2019 5:52 am, Chris Plummer wrote:
On 2/26/19 9:34 AM, Erik Gahlin wrote:
On 2019-02-26 07:47, Thomas Stüfe wrote:
Hi David, Yasumasa,
> Do we suppor
On 27/02/2019 7:50 am, Chris Plummer wrote:
On 2/26/19 1:30 PM, David Holmes wrote:
On 27/02/2019 5:52 am, Chris Plummer wrote:
On 2/26/19 9:34 AM, Erik Gahlin wrote:
On 2019-02-26 07:47, Thomas Stüfe wrote:
Hi David, Yasumasa,
> Do we support connection to later VMs from earlier JDK t
On 2/26/19 1:30 PM, David Holmes wrote:
On 27/02/2019 5:52 am, Chris Plummer wrote:
On 2/26/19 9:34 AM, Erik Gahlin wrote:
On 2019-02-26 07:47, Thomas Stüfe wrote:
Hi David, Yasumasa,
> Do we support connection to later VMs from earlier JDK tools?
I could not find the spec about th
On 27/02/2019 5:52 am, Chris Plummer wrote:
On 2/26/19 9:34 AM, Erik Gahlin wrote:
On 2019-02-26 07:47, Thomas Stüfe wrote:
Hi David, Yasumasa,
> Do we support connection to later VMs from earlier JDK tools?
I could not find the spec about this.
So I asked to serviceability folk
On Tue, Feb 26, 2019 at 8:54 PM Chris Plummer
wrote:
> On 2/26/19 9:34 AM, Erik Gahlin wrote:
>
> On 2019-02-26 07:47, Thomas Stüfe wrote:
>
> Hi David, Yasumasa,
>
>
>>
>> > Do we support connection to later VMs from earlier JDK tools?
>>
>> I could not find the spec about this.
>> So I asked to
On 2/26/19 9:34 AM, Erik Gahlin wrote:
On 2019-02-26 07:47, Thomas Stüfe
wrote:
Hi David, Yasumasa,
> Do we support connection to later VMs from earl
On 2019-02-26 07:47, Thomas Stüfe wrote:
Hi David, Yasumasa,
> Do we support connection to later VMs from earlier JDK tools?
I could not find the spec about this.
So I asked to serviceability folks before filing this to JBS :-)
Just to chime in on that, I do not know if it is sp
it on my side, and I will handle the fix.
would you like to help create a JBS for this issue?
Cheers,
Lin
From: serviceability-dev on behalf of
Yasumasa Suenaga
Sent: Tuesday, February 26, 2019 3:25:15 PM
To: David Holmes
Cc: [email protected]
So my idea to fix is using non-blocking socket, do you think it
is reasonable?
BRs,
Lin
From: 臧琳
Sent: Tuesday, February 26, 2019 6:19:37 PM
To: Yasumasa Suenaga; David Holmes
Cc: [email protected]
[email protected]
9:37 PM
To: Yasumasa Suenaga; David Holmes
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Hi David, Yasumasa, Thomas,
Thanks for point out this issue. it is introduced by enlarged the
arg_count_max for 8215622.
I have reprod
easonable?
BRs,
Lin
From: 臧琳
Sent: Tuesday, February 26, 2019 6:19:37 PM
To: Yasumasa Suenaga; David Holmes
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
Hi David, Yasumasa, Thomas,
Thanks for point o
From: serviceability-dev on
behalf of Yasumasa Suenaga
Sent: Tuesday, February 26, 2019 3:25:15 PM
To: David Holmes
Cc: [email protected] [email protected]
Subject: Re: Protocol version of Attach API
2019年2月26日(火) 16:11 David Holmes :
>
> On 26/02/201
2019年2月26日(火) 16:11 David Holmes :
>
> On 26/02/2019 5:01 pm, Yasumasa Suenaga wrote:
> > 2019年2月26日(火) 15:47 Thomas Stüfe :
> >>
> >> Hi David, Yasumasa,
> >>
> >>>
> >>>
> Do we support connection to later VMs from earlier JDK tools?
> >>>
> >>> I could not find the spec about this.
> >>> So
On 26/02/2019 5:01 pm, Yasumasa Suenaga wrote:
2019年2月26日(火) 15:47 Thomas Stüfe :
Hi David, Yasumasa,
Do we support connection to later VMs from earlier JDK tools?
I could not find the spec about this.
So I asked to serviceability folks before filing this to JBS :-)
Just to chime in o
2019年2月26日(火) 15:47 Thomas Stüfe :
>
> Hi David, Yasumasa,
>
>>
>>
>> > Do we support connection to later VMs from earlier JDK tools?
>>
>> I could not find the spec about this.
>> So I asked to serviceability folks before filing this to JBS :-)
>>
>
> Just to chime in on that, I do not know if it
Hi David, Yasumasa,
>
> > Do we support connection to later VMs from earlier JDK tools?
>
> I could not find the spec about this.
> So I asked to serviceability folks before filing this to JBS :-)
>
>
Just to chime in on that, I do not know if it is specified but it is
certainly very handy in dai
On 26/02/2019 4:32 pm, Yasumasa Suenaga wrote:
Hi David,
2019年2月26日(火) 15:14 David Holmes :
On 26/02/2019 4:01 pm, Yasumasa Suenaga wrote:
Hi all,
When I attached to VM which is after 8215622 change via jcmd in JDK 8
on Linux, jcmd hanged.
What command are you trying to execute through jcm
Hi David,
2019年2月26日(火) 15:14 David Holmes :
>
> On 26/02/2019 4:01 pm, Yasumasa Suenaga wrote:
> > Hi all,
> >
> > When I attached to VM which is after 8215622 change via jcmd in JDK 8
> > on Linux, jcmd hanged.
>
> What command are you trying to execute through jcmd?
I tried VM.info, Thread.pri
On 26/02/2019 4:01 pm, Yasumasa Suenaga wrote:
Hi all,
When I attached to VM which is after 8215622 change via jcmd in JDK 8
on Linux, jcmd hanged.
What command are you trying to execute through jcmd?
Do we support connection to later VMs from earlier JDK tools?
I checked the status of targ
53 matches
Mail list logo
