Release Notes > ThingWorx Connection Server Release Notes
ThingWorx Connection Server Release Notes
ThingWorx Connection Server, versions 7.1 and later, represent the next generation of the ThingWorx Connection Server. With v.9.0.0, the Connection Server can be configured to operate in a single-server ThingWorx Platform deployment or in a ThingWorx High Availability Clustering deployment. For information about the features of the Connection Server, refer to Overview of the ThingWorx Connection Server.
IMPORTANT! As part of ongoing security improvements, the releases of the ThingWorx Connection Server include changes to fix potential security issues, as well as additional issues proactively identified by vulnerability scanning software or PTC QA testing. Please upgrade as soon as possible to take advantage of these important improvements
ThingWorx Connection Server, v.9.0.1
The ThingWorx Connection Server, v.9.0.1, provides a fix for the following issue:
Fixed an issue where the ThingWorx Connection Server docker images were failing to build due to the gpg utility not being present in the Linux version used to build it.
ThingWorx Connection Server, v.9.0.0
The ThingWorx Connection Server, v.9.0.0, has been tested and certified to work with the v.9.0.0 version of the ThingWorx Platform. In addition it has been tested and certified to work in a ThingWorx High Availability Clustering deployment.The following table lists additional enhancements and fixed software issues:
To allow better tracking of multi-part messages through it, the Connection Server now logs the multi-part details, including chunk number and the number of chunks, in the "forwarding to edge" and "forwarding to platform" log messages.
Add service discovery support to Connection Server to enable it to operate in a ThingWorx High Availability Clustering environment.
The Connection Server supports dynamic configuration of ThingWorx Platform instances to connect to using service discovery. With this feature, administrators do not have to configure the platform instances manually and restart the Connection Server when the platforms change.
More specifically, the service discovery feature enables the Connection Server to respond to platforms being added to and removed from the cluster. If a target platform is removed from the cluster, the Connection Server responds by:
Failing partially processed, multi-part request messages from the edge.
Logging and discarding multi-part responses to platform-initiated requests.
The service discovery feature detects ThingWorx Platform instances going up and down while keeping the Connection Servers connected correctly in the cluster. The Remote Things connected through HAProxy can still receive property updates from the edge when one platform instance in the cluster goes down.
Properties have been added to the Connection Server configuration for service discovery. If you are running the Connection Server in a ThingWorx High Availability Clustering environment, refer to .
Use round robin policy for message routing in HA connection server.
When operating in a ThingWorx High Availability Clustering environment, the Connection Server routes, ingress (request) messages to ThingWorx Platform instances using a round robin policy. The round robin policy provides good load distribution and fault tolerance. For more information, refer to Using the Connection Server in a ThingWorx High Availability (HA) Clustering Environment.
The Connection Server now handles multi-part ingress requests for round robin routing policy when operating in a ThingWorx High Availability Clustering environment. The Connection Server routes multi-part ingress (request) messages to the same ThingWorx Platform instance. If the platform disconnects or is not writable, error messages are written to the Connection Server log. For more information, refer to the subsection on multi-part messages in the topic, Using the Connection Server in a ThingWorx High Availability (HA) Clustering Environment.
Add support for '/TWS' AlwaysOn connections.
For remote access sessions through a ThingWorx Platform the ThingWorx Remote Access Client (RAC) uses a ThingWorx Temporary WebSocket (TWS) endpoint. In a ThingWorx High Availability Clustering deployment, two RAC clients will establish an AlwaysOn tunnel through the same Connection Server. In this type of deployment, the Connection Server is used as a proxy for remote access sessions. For more information about the TWS endpoint, refer to the subsection, "WebSocket Endpoint for Remote Access", in the ThingWorx help center topic, What's New in ThingWorx Remote Access Extension and ThingWorx Remote Access Client?
There is no special configuration for this support. The Connection Server supports this way for the RAC 2.0.0 to connect to a ThingWorx Platform that supports the TWS endpoint. However, if you are using a load balancer configuration that is path-based, you need to make sure to allow the /TWS path.
The following metrics have been added for a Connection Server that is running in a High Availability Clustering environment:
Count of messages sent to each ThingWorx instance
Count of message sizes (in bytes) sent to each ThingWorx instance
Count of messages received from each ThingWorx instance
Count of message sizes, in bytes, received from each ThingWorx instance
In addition, metrics have been added for the High Availability Cluster and service discovery. Refer to Metrics for details.
With this release, support for JKS is deprecated because the algorithms used by the Java Key Store are no longer considered secure. Instead of reading JKS, the Connection Server now reads PKCS keystores by default. If a keystore cannot be read, the Connection Server terminates abnormally. Indications of this situation are that the Connection Server returns a non-0 result code and writes messages to the appropriate logs.
If you configure a JKS, a warning message is logged. That said, JKS trust stores can still be used without issue since they contain only a list of trusted certificates.
The JDK still ships a default trust store (cacerts), which is a JKS-formatted key store.
When using PKCS, configuration files that specify the file name should not contain the extension. For example, abc_cert instead of abc_cert.pfx.
For information about converting a JKS key store to PKCS, refer to Converting JKS Keystores to PKCS Keystores.
The Connection Server now performs TLS host name validation of certificates by default when connecting to an HTTPS-enabled ThingWorx Platform.
If absolutely necessary, you can disable host name verification by configuration. Best security practice is to leave host name verification enabled.
When a ThingWorx Platform instance is removed from service discovery and the cluster no longer has any WebSocket connections to the platform, all per-platform metrics in the cluster are removed or reset for that platform instance.
In a ThingWorx High Availability Clustering environment, a Connection Server shuts down gracefully if it is disconnected from a ZooKeeper instance for a configurable amount of time. The Connection Server continues to work until the timeout expires, at which time, the Connection Server disconnects clients and shuts down gracefully.
Enable TLS by default in the Connection Server.
In keeping with PTC policy to be secure by default, the configuration of the Connection Server had SSL/TLS enabled by default. To configure the keystore for a standalone environment, refer to Required Configuration for the Connection Server. Optionally,, you can configure trust store. Refer to .
To configure the keystore in a ThingWorx High Availability Clustering environment, refer to . Optionally,, to configure the trust store, refer to in the same topic.
Issues Fixed in This Release
After a restart, the Connection Server now retries binding to a ThingWorx Platform every 15 seconds (configurable) until it succeeds.
With this change, the Connection Server eventually binds with a ThingWorx Platform after a restart in a ThingWorx High Availability Clustering deployment. In this environment, it may take two to three minutes for the bind to succeed and the last connection time to update.
ThingWorx Connection Server, v.8.5.0 - Enhancements and Issues Fixed
The ThingWorx Connection Server, v.8.5.0, has been tested and certified to work with the v.8.5.0 version of the ThingWorx Platform. In addition to ongoing security improvements for all Connection Services, this release of the Connection Server includes the following enhancements and fixed software issues:
Issue ID (SF ID)
Log the result message when a BIND request fails.
When ThingWorx Platform sends an unsuccessful BIND/UNBIND response, the result message is now written to the log. The log includes the endpoint ID and request ID. If possible, it may include the bind names.
Updates to support testing against ThingWorx 8.5.
No updates were necessary
Connection Server, v.8.4.0 – Enhancements and Issues Fixed
Release 8.4.0 of the ThingWorx Connection Server provides the following enhancements and software fixes:
Issue ID (SFID)
Additional metrics are provided for the Connection Server:
Total connections made metric
Successful authentication attempts metric
Bind/unbind metrics
Disconnected metrics
APIMessage meter
Platform message response meter
Add logs for the monitoring services of the Connection Server
The following changes have been made:
Request details are logged (endpoint ID, request ID)
The success or failure of sending the response is logged.
Redundant logs have been removed from the Connection Server.
Add higher QOS for responses flowing through Connection Server.
Responses flowing through a Connection Server are now submitted to netty up to two times the regular netty watermark. This functionality has a configuration property, transport.websockets.connections.enableHigherQualityOfServiceForResponses , to allow it to be enabled (default value of true) or disabled.(false.
Support for using an encrypted configuration file for the AlwaysOn Connection Server has been added for this release. See the topic, Setting Up an Encrypted Configuration File in the ThingWorx Connection Services Help Center or in the ThingWorx Connection Server Installation and Operations Guide, v.8.4, available from t he Reference Documents page on the PTC Support site.
Issues Fixed in This Release
Allow Connection Server to consolidate multiple authentication (AUTH) requests when platform authentication is slow.
If the platform is slow to respond to AUTH requests, a client may generate multiple AUTH requests. When finally getting a AUTH response from ThingWorx, the Connection Server will now send the AUTH response back to the edge with the latest AUTH request ID sent in.
Error sending message may not be propagated to original client.
This issue is fixed in this release. Errors encountered in the process of transforming and writing messages to the platform are now propagated back to the initiating client.
Minimize context switching
This issue is resolved in this release. To improve performance when processing a request, context switching has been minimized.
Connection Server should allow configuring a short AUTH timeout for WebSockets
The WebSocket will now be closed if no AUTH request is received within some configurable interval (10000 ms by default). The property is transport.websockets.authentication.timeout-ms.
This issue has been resolved as part of PTC’s continued investment in helping customers reduce risks associated with security threats.
CXS-518 (14708758)
Out of Memory issues.
This issue is fixed in the 8.4.0 release.
CXS-527 (14717556)
The Connection Server failed to start due to the following error:
Failed to create cache dir
WORKAROUND: Add -Dvertx.disableFileCPResolving=true to the CONNECTION_SERVER_OPTS environment variable.
This issue is fixed in the 8.4.0 release.
Connection Server v.8.2.3 — Issues Fixed
Release 8.2.3 of the ThingWorx Connection Server provides software fixes for the following issues:
Issue ID (SFID)
Async Java SDK does not correctly implement the WebSocket close session handshake
The async Java client did not reply to the server (ThingWorx platform) with a CloseWebSocketFrame when the platform tried to terminate a connection.
This issue is fixed in this release.
CXS-448 /PSPT-5684 (14571469)
The Connection Server is reporting OOM errors.
This issue is fixed in this release.
CXS-424 (14219987)
Connection Server does not properly handle "multi-part bind messages".
This issue is fixed in this release.
Edge device can assume session permissions of another session.
An edge device, once authenticated using valid security claims, could assume the permissions from another authenticated session by sending request messages with the session ID of the session that it wanted to assume.
This issue is fixed in this release. If a request is sent with a session ID other than the one returned from the initial authentication, the request is ignored. The request exencutes with the permissions associated with the initial authentication session ID rather than the permissions associated with the session ID sent in the request.
Connection Server v.8.2.2 — Issue Fixed
Release 8.2.2 of the ThingWorx Connection Server provides a software fix for the following issue:
CXS-407 (14078591)
The Connection Server may fail to appear in the Connection Server Monitor UI/Mashup when regaining connectivity to ThingWorx.
CAUSE: A race condition in the AlwaysOn protocol adapter could break the flow of egress messages from the ThingWorx Platform to the Connection Server.
This issue is fixed in this release.
Multiplexing Issue Fixed in ThingWorx Connection Server, v.8.2.1
The support for multiplexed client connections in v.8.2.0 meant that any WebSockets that were authenticated using the same endpoint ID were coming from a single client and were grouped together (multiplexed). Egress for any things bound from that client would be sent in a round-robin way across the multiplexed edge WebSockets.
For clients based on the ThingWorx Edge Java SDK, this behavior produces the expected results when multiple clients connect through the Connection Server using the same endpoint ID. However, for ThingWorx Edge C SDK-based clients (such as the ThingWorx WebSocket-based Edge MicroServer or WS EMS), this behavior was producing the following results:
When multiple C SDK-based clients such as the WS EMS connected through the Connection Server, bound things continued to show as connected on the ThingWorx Platform, even after the client's WebSocket was closed.
After having been bound, the C SDK-based clients could never reconnect because they were never actually disconnected from the ThingWorx Platform by the Connection Server. Newer ThingWorx Platform releases have additional security fixes that actively prevent a client from binding if it is "already bound".
With the 8.2.1 release of the Connection Server, multiplexed C SDK-based clients (including WS EMS) and Java SDK-based clients will connect and disconnect as expected.
Known Issue in v.8.2.1
The following table lists and describes the known issue for release 8.2.1:
ISSUE: Connection Server affinity required for load-balanced Connection Servers when using a multiplexed client
DETAILS: Multiplexed clients (Java SDK) must establish all WebSockets to the same Connection Server. If using a multiplexed client, you must ensure that the load balancer directs all traffic for a given client to the same Connection Server. If all WebSockets do not go to the same Connection Server, the client will experience egress-related issues. Also, if one of the Connection Servers to which the client is attached fails, all things bound through that Connection Server will show up as not connected in the ThingWorx Platform. However, the clients will think that they are still bound and will not try to re-bind. These remote things will not be able to receive egress and cannot send ingress. Restarting the clients will resolve the issue.
Enhancements ThingWorx Connection Server, v.8.2.0
This release of the next generation Connection Server includes the following enhancements:
Compression for the WebSocket connection using zlib 1.2.11. For information about zlib, go to Compression is enabled by default for the Connection Server.
Support for multiplexed client connections. Developers can create device clients that multiplex the requests/responses over multiple physical connections to the Connection Server.
Improved behavior for idle WebSockets.
See the ThingWorx Connection Server Installation and Operations Guide for details.
Issues Fixed in Release 7.2.1
Release 7.2.1 includes fixes for the following issues found in release 7.2.0:
CXS-261 / 13622133
EMS Linux + Connection Server 7.2 + ThingWorx Platform 7.2 does not work.
This issue is resolved in this release. The configuration section in the guide for the Connection Server has been updated.
Command to set environment variable as shown in documentation causes errors on startup.
This issue is resolved in this release.
Enhancements for 7.2.0
The following features were added for v. 7.2.0:
Support for tunneling and HTTP pass-through, including configuration that supports scalability for these features.
Support for HTTP pass-through.
Vert.x instead of Undertow for transport functionality.
Support for validating client certificates.
Improved log messaging:
Detailed log messages captured on exceptional situations, including stack traces.
Debugging log messages can be enabled on demand from the ThingWorx platform. The GetLogLevel and SetLogLevel of the ConnectionServer thing template have been implemented. These commands adjust the log level, but the logs are not visible in the Monitoring tab. Depending on the logback configuration, the messages may be written to the local logs for the Connection Server.
If the GetLogEntries and GetTypes services are invoked, the Connection Server returns an HTTP 404 Not Found error.
Size limits for log files.
Issues Fixed in Release 7.1.1
This release include the software fixes that were provided in the 7.1.1 release of the next generation Connection Server, which are described in the following table:
Chunking for uploads of large files was not working.
This issue is resolved.
In multi-part requests, the entityName was not being found properly, resulting in the messages timing out.
This issue is resolved.