Hi,

In 2.2.0 we implemented PublishRequest timeouts. The default timeout time is 2 minutes. This can be configured in UaClient.setPublishRequestTimeout. Before it was UnsignedInteger.MAX_VALUE

Technical/Complex stuff (also ended up quite long post, sorry):
The reason for the non-infinite timeout is that there is a possibility for a “deadlock” if a server manages to send all PublishResponses back during a small connection break. The client wont send any more requests (how many the client sends depends on UaClient’s publishRequestFactor and number of subscriptions) because it has not received any response (because of the communication break) and the server wont have any requests to response so neither will do anything and the Subscription itself will timeout on the server after lifetime ends. If the requests do timeout on the client side before the subscription has been idle for it’s Lifetime, the client will notice the timeout and send more requests, i.e. the situation is recovered.

We have received similar report recently. We have found 2 bugs in related to this.
1. One is that t is possible that under heavy load (lots of subscriptions/lots of notificates) a PublishRequest might be sent twice. Most of the servers probably wont mind this, but the client side only accepts the first reply (they have the same RequestId), this creates the Unidentified message warning. This one is fixed.
2. The second is related how the server determines the timeouts of the PublishRequests. It is possible that we responsing an already timeouted request. This is somewhat fixed currently.
Techical stuff related to 2.
The problem is that the server should wait at least the TimeoutHint amount given in the request. If we do reply when it is almost but not yet timeouted, it might timeout during network travel (depends on latency and computer clocks).

My conclusion is that the PublishRequest timeout should be set to suitable value depending on PublishInterval/KeepAlive/Lifetime. The KeepAlive should such that in normal conditions there would be no timeouts (i.e. the server has always at least a KeepAlive Notification to send before any PublishRequest timeouts). The Timeout should be such that you do receive the timeout well before Lifetime end (otherwise there is no point, since the point is to avoid the subscription itself from timeouting). As long as you have a single Subscription this logic is somewhat easy. If you have multiple, then it is more complicated. You could for now maybe keep it at the old MAX_VALUE if the possibility for communication breaks is low. I am not sure which would be the ideal solution.

Email at uajava-support@prosysopc.com if you want to try the current (beta) build. These fixes will be part of 2.2.2. which we hope to release soon.
(NOTE! the beta uses currently the MAX_VALUE because I’m not sure is it still a better default value…)

– Bjarne