Serialization of queue size is broken

[maf23]

This issue exists in both in the 1.1 branch and head.

I have set the threadpool.get.queue_size to -1 using the REST API.
I am running the elasticsearch server with assertions enable (-ea).
If then a TransportClient with "sniff=false" connects and tries to send a query it gets a org.elasticsearch.client.transport.NoNodeAvailableException
The underlying exception is:
Caused by: java.lang.AssertionError
at org.elasticsearch.common.io.stream.StreamOutput.writeVLong(StreamOutput.java:176)
at org.elasticsearch.common.io.stream.AdapterStreamOutput.writeVLong(AdapterStreamOutput.java:126)
at org.elasticsearch.common.unit.SizeValue.writeTo(SizeValue.java:211)
at org.elasticsearch.threadpool.ThreadPool$Info.writeTo(ThreadPool.java:643)
at org.elasticsearch.threadpool.ThreadPoolInfo.writeTo(ThreadPoolInfo.java:74)
at org.elasticsearch.action.admin.cluster.node.info.NodeInfo.writeTo(NodeInfo.java:291)
at org.elasticsearch.action.admin.cluster.node.info.NodesInfoResponse.writeTo(NodesInfoResponse.java:68)
at org.elasticsearch.transport.netty.NettyTransportChannel.sendResponse(NettyTransportChannel.java:83)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$TransportHandler$1.onResponse(TransportNodesOperationAction.java:246)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$TransportHandler$1.onResponse(TransportNodesOperationAction.java:241)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$AsyncAction.finishHim(TransportNodesOperationAction.java:227)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$AsyncAction.onOperation(TransportNodesOperationAction.java:202)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$AsyncAction.access$900(TransportNodesOperationAction.java:102)
at org.elasticsearch.action.support.nodes.TransportNodesOperationAction$AsyncAction$2.run(TransportNodesOperationAction.java:146)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

That is the server tries to use OutputStream.writeVLong on a negative number.

Please let me know if you need more information.

[spinscale]

I think I found the root cause of this... the queue_size variable is serialized as a SizeValue, which does not support negative values in ThreadPool.Info.writeTo()