cr7154822 : Request for code review
staffan.larsen at oracle.com
Thu Mar 29 11:20:11 PDT 2012
On 29 mar 2012, at 17:11, David Buck wrote:
> >> > If the limit is the same for all platforms, then the fix
> >> > could be improved to check that each line is smaller than the
> >> > limit before to send it to the target JVM, and properly
> >> > report an error if it isn't. Right now, each platform
> >> > throws an IOException with a platform dependent message.
> >> > Instead, detecting lines exceeding the limit and printing
> >> > a clear message like:
> >> >
> >> > "line 84: Line too long"
> >> >
> >> > would improve the user experience.
> >> That should be doable. Are we OK with hard-coding the current VM limit
> >> into the client side code?
> > I'm not fond of the idea that the client side "knows" the VM limit.
> > Yes, I recognize that would improve the user experience, but it
> > makes the code more fragile. I don't think there is a client-side
> > query for determining the buffer length. Perhaps you should query
> > Alan Bateman for advice since the attach-on-demand stuff was his
> > creating way back when... He might have some advice...
> I talked with Dan over IM about this, and feel that it is not worth pursuing. There is no obvious interface for a client to dynamically query the limit. And when an exception is thrown, there is no obvious way for the client to distinguish between having sent a string that was too large and some other IO error. Hard coding this value into the client is just asking for trouble. Ideally, jcmd should be inter-operable with multiple versions of the JVM.
It may be possible to use the error messages sent from the VM to the client to do this. See the ATTACH_ERROR_* constants in attachListener_solaris.cpp for example. Similar things exists on linux, but apparently not for windows. Anyway, that would be outside the scope of this fix.
More information about the serviceability-dev