Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
SecureChannelTcp Timeout
April 2, 2020
14:11, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 100
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Good morning,
I hope you all are safe. Given the Corona situation I am connecting a Prosys OPC UA Client, (SDK v 4.1.4) from my home office to a remote server through a rather slow DSL line. The connection succeeds, but I receive the following message after a short time:

[Blocking-Work-Executor-63] SecureChannelTcp : Request id=305 timeouted 132005ms elapsed. timeout at 132000ms

I am subscribing to the ServerState, which, as a result from the timeout goes from Running to CommunicationFault. At that time, multiple regular data subscriptions already delivery DataValue updates normally. One monitored item though does not delivery an initial value, although UaExpert has no problems subscribing to it.

I know that this might me difficult to advise on with that little information, but maybe you can hint me towards the problem area.

Thanks,
Hans-Uwe

April 2, 2020
16:12, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 508
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

Most likely if you call UaClient.setTimeout (before calling connect) to some high value it should help. By default it is null, then internally in lower levels we use 120000 (milliseconds) as a default. So try something crazy like 10 minutes.

P.S. While not helping for individual service calls, if you have the option to try SDK 4.3.0 it should greatly shorten the connection time if you do UaNode related operations (and prev versions do use it internally for OperationLimits). It will still send about the same data binary-wise (or a bit more) (when connecting and reading the types etc.), but the calls are packed with more operations, thus less overhead of latency for each request. https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-3-0 (and like for a server that has large number of custom structures it is like going from 10000 service calls to like 100)

April 2, 2020
17:25, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 100
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hi,

thanks for your quick reply. I changed to timeout first to 20000ms and then to 70000, but this actually made things worse. At 20000ms, the request timeout out after 5000ms, at 70000ms, the timeout happened after 11000ms (according to the log. the actual message happened at different times). So I don’t see a direct relationship between the timeout period and the actual request timeout…

April 3, 2020
10:18, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 508
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hmm.. that should have worked.. interesting.

Could you please doublecheck you did it like e.g.

client.setTimeout(10, TimeUnit.MINUTES);
client.connect();

Is the server made with the Java SDK or something else? Does it’s log show anything?

IF you have option to https://www.prosysopc.com/blog/opc-ua-wireshark/, you could validate, that the correct number is sent in the RequestHeader TimeoutHint. Additionally if you do not see the server to reply, or see the timeout before that, then it means our client side did timeout the message. If instead you see server to return that code, it could be that server is timeouting them sooner. However the log line in the first post is client-side timeouting.

Client side timeouts at 1.1*RequestHeader.TimeoutHint. For 120000, this is 120000 * 1.1 == 132000 the number you saw.

While probably not related, do note that for initial connecting timeouts there are or at least can be operating system level timeouts, we cannot wait more than that, since the OS will timeout by itself. Typically those are 1 or 2 minutes. But that shouldn’t affect once the Socket connection is formed.

Also do check are the client and server clocks synchronized at least to some level. The RequestHeader does include a client-side timestamp, while that should only be used for logging purposes, in theory it is possible that it would incorrectly be used to calc timeouts in the server side.

April 3, 2020
14:29, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 508
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Additionally while numbers doesn’t exactly match for this case, you might need to also call UaClient.setStatusCheckTimeout in addition to that setTimeout. You can use the same values here as in the setTimeout.

The status check timeout is used when UaClient by default reads the server status once per second. The default status check timeout value is 10000 (ms), i.e. 10 seconds. Thus it might be this after all so please try to change it also to some crazy value. Note however, that the value shouldn’t be that high normally, since if it is too high, then the UaClient will also be unaware that the server is e.g. shutting down etc. So it is should be larger than normally expected for the server to answer, but how much larger is then a good question.

April 16, 2020
15:07, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 100
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

I still did not figure out where exactly the problem is for the described situation. Changing the StatusCheckTimeouts do not seem to make any difference.

I create 2 subscriptions (plus a handful of monitored items) in the serverStatusListener when it changes from xxx to Running. This happens on a different thread though in order to not block the listener. If I only add a single subscription + monitored items, things work as expected.
I need to track this path further down….

May 7, 2020
17:46, EEST
Avatar
hbrackel
Member
Members
Forum Posts: 100
Member Since:
February 21, 2014
sp_UserOfflineSmall Offline

Hurray! After upgrading to SDK v4.3.0 the timeouts are no longer occurring! I still don’t know what caused them, but anyways… the problem has been solved.

Many thanks!

May 8, 2020
17:30, EEST
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 845
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Super!

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
12 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 100

pramanj: 86

ibrahim: 69

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 36

Rainer Versteeg: 32

Thomas Reuther: 26

Member Stats:

Guest Posters: 0

Members: 1037

Moderators: 14

Admins: 1

Forum Stats:

Groups: 3

Forums: 14

Topics: 968

Posts: 4078

Newest Members:

NilsonChalie, markblue523, savannah3880, darrenyo, pokapoka95, roscoedomingo7, kathrinrohde588, aleidamott69222, mp, corinapzx0505

Moderators: Jouni Aro: 845, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 508, Heikki Tahvanainen: 402, Jukka Asikainen: 1, Teppo Uimonen: 20, Markus Johansson: 15, Matti Siponen: 18, Lusetti: 0

Administrators: admin: 0