ThingWorx Edge Java SDK > Application Details > ClientConfigurator Component
ClientConfigurator Component
A ClientConfigurator class is used to configure an instance of a ConnectedThingClient.
The ClientConfigurator accepts an option to set the maximum ThingWorx message size (NOT the size of an individual Websocket message). This option is MaxMessageSize, with a default value of 16KB (16384 bytes). If you are transferring large files, you may want to increase this value (e.g., 536870912 bytes). Any attempt to send a message with a payload larger than the value defined for MaxMessageSize will result in a GenericHTTPException message. When the log level for the SDK is set to debug, the SDK logs a message about the size being too large.
For the complete list of the parameters you can set with the ClientConfigurator, refer to the Javadoc for the SDK. The Javadoc lists, briefly describes, and provides default values for the parameters (if applicable).
* 
For examples of using a ClientConfigurator when setting up a connection through a proxy server for an Android application, refer to Setting Up to Run Sample Android Applications.
For examples of setting options for file transfers in the ClientConfigurator, refer to Transferring Files.
* 
setPipeCount() sets the pipe count for ClientConfigurator, where PipeCount is the number of WebSockets that the client opens to the server. By default, pipe count is set to 1; and it is not recommended to change this value.
If you change this value, and if your agent passes through a Load Balancer or proxy such as NGINX, then the WebSockets may connect to different connection servers or platforms or both. This will lead to unexpected results, such as bind failures and data arriving out of order.
This method will be deprecated in a future release.
Compression
The Java SDK supports compression for all WebSocket communications. Compression is useful when you need to send a significant amount of data to the ThingWorx Platform over a cellular network. By default WebSocket compression is enabled in the Java SDK for communications between the edge and the platform. If necessary, before initializing a WebSocket connection, you can disable it through the ClientConfigurator object, which sets the CompressionEnabled flag to false to disable compression or true to enable compression. Note that if compression is enabled, the maximum block size is adjusted by 4 to account for the 4 bytes needed for deflate synchronization. The adjustment is made automatically because compression is enabled by default. If compression is not enabled, the block size is not modified.
If necessary, compression can be disabled using the following line of code in the ClientConfigurator:

config.compressionEnabled(false);
Where config is an instance of a ClientConfigurator object.
When compression is enabled, WebSocket frames are compressed in accordance with RFC-7692. You can also compress Tunnel WebSocket frames, using a setting that is independent of the API WebSocket connection. The tunnel WebSocket compression setting defaults to the same setting as for the ClientConfigurator WebSocket connection. The setting for tunneling is determined by the isCompressionEnabled() method
In addition, metrics have been added to monitor compression when it is enabled. The following information is logged:
When compression is being used. Specifically, a message is added to the logs when the WebSocketClientCompressionHandler is added to the pipeline. The DEBUG level message is

Adding compression handler to pipeline
TRACE log when compression is enabled. This logging prints out the ordered list of ChannelHandlers.
Was this helpful?