Support for configuring NuProcess buffer capacity via user property

[avrecko]

Configurable via property com.zaxxer.nuprocess.bufferCapacity.

I've set the limits between 1 KiB and 1 MiB. They are arbitrary choices. Should handle use cases of 4, 8, 16, 32, 64 KB/KiB.

edit: could also set limit to something like 128 KiB? Thoughts?

[bturner]

I don't think this should be here. I'd put it on NuProcess instead. If a point comes where the NuProcessBuilder grows the ability to control the buffer size per-process, NuProcess.BUFFER_CAPACITY would still not be able to reflect that (since it's a static constant). I suspect if that ever became possible we'd need to deprecate that constant and either remove it or rename it (e.g. DEFAULT_BUFFER_CAPACITY). Regardless, though, it still wouldn't need to look at the builder to know what that value is.

[avrecko]

Yeah, maybe we put this in Constants class?

[avrecko]

I also first thought about putting it in NuProcess but it is an interface. Not a big fan of implementation in interfaces. Constants feels good to me. But if you like. No problem for me to put something in NuProcess.

[avrecko]

For more fine grained control I'd put it in the NuProcessBuilder.

NuProcessBuilder(....).setStdoutBufferCapacity(4092).setStdinBufferCapacity(32000).setStdErrBufferCapacity(16000);

[bturner]

Re: using 128K as the limit, I don't thing we need to super prescriptive here in the library. To some extent, I'm a bit inclined to just let the caller use whatever value they want, even if it's what I would consider excessively small or large, and not validate at all beyond ensuring it's a number (and defaulting the value if it isn't, rather than throwing).

If we're going to have a limit, I'd probably leave it as you have it.

[avrecko]

Re: using 128K as the limit, I don't thing we need to super prescriptive here in the library. To some extent, I'm a bit inclined to just let the caller use whatever value they want, even if it's what I would consider excessively small or large, and not validate at all beyond ensuring it's a number (and defaulting the value if it isn't, rather than throwing).

If we're going to have a limit, I'd probably leave it as you have it.

I think most if not all would want to use 4, 8, 16 or 32 as alternatives to 64. So I think a limit makes sense.