Log In
Register
Forum
Topic RSS
14:07, EEST
June 25, 2014
Offline
Hello,
I’ve analyzed TCPIP connections from OPC UA Java SDK to OPC server and I found two issues that I don’t fully understand.
1) When I monitored threads created by OPC UA Java SDK, I saw there were exactly 64 threads with name “Blocking-Work-Executor”. I suppose these threads are used as a thread pool for various communication from client to server (it means the client does not have to create a new thread for subscriptions, reads etc., but can just reuse threads from this pool). Is it correct? Can I handle these threads somehow? For example I wonder if I can set maximum threads for this pool? How?
2) Next issue is connected to TCPIP communication. When I analyzed network communication, I found there were many TCPIP RESETs (basically every 1 minute or so). I don’t know if it is connected to OPC UA Java SDK, but I would like to ask about this before I start checking network issues and other network devices.
My settings are:
client.setSecurityMode(NONE)
client.setTimeout(30000)
client.setValidateDiscoveredEndpoints(false)
client.setStatusCheckTimeout(0)
client.setAutoReconnect(false)
Scenario:
1) connect
2) no communication for X hours
3) read from / write to OPC
During the second step there are many RESETs sent in communication between client and server. Is it possible that client is doing something like this?
Thank you for anything that could help me to solve it.
Best regards,
Ladislav Asenbrener
9:52, EEST
April 3, 2012
Offline
Hi,
1.
You are correct, they are part of the Java Stack and used for communication, e.g. async calls. In addition in the SDK, UaClient has one thread per instance, which handles PublishResponses, reconnecting and server status checking.
Some settings of those threadpools can be modified by static methods in the StackUtils class. It seems the max pool size cannot be changed (is 256), but you can change the core pool size.
2.
Not sure. The client does periodically read the server status (StatusCheckInterval) to keep the channel from timeouting (default is once per second). Setting the status check timeout to 0 means the client side should wait forever for a reply. To my knowledge that is ususally not done. Also the communication channel is renewed periodically, but that should be around one hour with default settings.
Just for info, in case you use wireshark, it has opc ua filters. https://www.prosysopc.com/blog/opc-ua-wireshark/
– Bjarne
11:19, EEST
June 25, 2014
Offline
Hi,
Thank you for reply.
1) I will try to play with that core pool size. Just to be clear, I don’t have any problems with it, I just want to know if it is possible somehow to set it and to possibly lower memory requirements in some special cases.
2) After further analyzing the network communication I found out that RES (tcpip reset) was sent when I was trying to read a node that didn’t exist on OPC server. And we had a service that tried to read a specific node from OPC server every few seconds / minutes (we do this instead of using uaClient.isConnected(), because it was unreliable for some OPC servers).
Best regards,
Ladislav Asenbrener
12:36, EET
January 12, 2018
Offline
Bjarne Boström said
1.
You are correct, they are part of the Java Stack and used for communication, e.g. async calls. In addition in the SDK, UaClient has one thread per instance, which handles PublishResponses, reconnecting and server status checking.
Hi,
So all the threads that I see during execution are generated by the stack?
If I understand correctly for every instance of UaClient there is an extra thread (besides the ones created by the stack) that manages reconnection etc. When I create an instance of UaServer what happens?
In addition to the 64 Blocking-Work-Excutors I see that there are other types (example I / O dispatcher, selector, UaTimer, Non-blocking ..), where can I find information on their use?
Thanks in advance,
Best regards,
Mike
17:32, EET
April 3, 2012
Offline
Hi,
In general they are technical implementation specifics and details for the SDK and the Stack and therefore not documented (and may change between versions). I can go into the details, if needed, but in practice unless you have a problem, it is best to ignore those. One note is that the 64 blocking pool (and in general most of the stack generated threads) is common/static for the whole JVM.
– Bjarne
12:05, EET
January 12, 2018
Offline
Hi,
Without going into details I would like to understand how it works.
I thought that there were dedicated thread for each session with the clients and that they were responsible for handling all requests for that session.
This is not true right?
So there are no specific threads listening on each session?
Thanks again
Regards
Mike
21:27, EET
December 21, 2011
Offline
There’s a major difference between the client and server side. The client side uses the blocking IO (java.io), whereas the server side uses non-blocking IO (java.nio) for the socket communication.
So on the server side it is only using the ‘Non-Blocking-Worker’ threads to handle incoming requests, and the single ‘Selector’ thread is managing the socket multiplexing.
Most Users Ever Online: 518
Currently Online:
23 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 76
ibrahim: 75
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 685
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6257
Newest Members:
Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1, Flores Frederick, ellenmoss, harriettschererModerators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 320, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
