ThingWorx Edge Java SDK > Application Details > ClientConfigurator Component
  
ClientConfigurator Component
You create a ClientConfigurator object to configure an instance of a ConnectedThingClient. The ClientConfigurator object takes a config.json file, which contains an infotable that contains the parameters required to communicate with the ThingWorx platform over WebSocket connections. For example:
// Create a client config
ClientConfigurator config = ClientConfiguratorFactory.from(configFile);
where configFile is a String that represents the config.json file that contains parameters in an InfoTable, in JSON format.
The config.json file for the ClientConfigurator object always contains the address for the ThingWorx platform. This address is a URL, beginning with ws if it is an HTTP connection or beginning with wss if it is an HTTPS connection. The config.json file for the ClientConfigurator object also has the security credentials to access the platform.
The ClientConfigurator also 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 (65535 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. This parameter works for both the Java and Android SDKs.
For the complete list of the parameters you can set with the ClientConfigurator, see 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, see . Connecting Through a Proxy Server
For examples of setting options for file transfers in the ClientConfigurator, see Configuring File Transfers.
Compression
As of v.6.1.0, 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.
The version of netty-all has been updated to 4.1.14 Final to support compression from the Java SDK to a ThingWorx endpoint (the platform or a ThingWorx Connection Server). 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.