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
Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
December 17, 2021
10:39, EET
Avatar
gerstale
Member
Members
Forum Posts: 6
Member Since:
November 26, 2019
sp_UserOfflineSmall Offline

Hello,

we are facing a problem with the message above. The problem occurs with prosys-opc-ua-sdk-for-java-4.6.2-1636 when we try to establish connection to 50 OPC UA test server and subscribe 50 Items for each server. The issue leads also to overrun in our System and various timeouts due high CPU load caused by Prosys stack. All test OPC UA Servers are based on Prosys sampleconsoleserver. Could you please advise how to proceed with this issue?

Thank you in advance
Alexej

December 17, 2021
11:17, EET
Avatar
rocket science
Member
Members
Forum Posts: 52
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline
December 17, 2021
11:35, EET
Avatar
gerstale
Member
Members
Forum Posts: 6
Member Since:
November 26, 2019
sp_UserOfflineSmall Offline

Thank you for the hint đŸ™‚ I have checked them, but there is no solution for the problem.
Unfortunately I have to reconnnect the affected OPC UA servers to receive the values for subscribed items.

December 17, 2021
12:18, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Having so many connections makes this a different situation.

Do you really need _that many_ of them in a real case?

Are all the 50 items in a single subscription (per client/connection)? Are all the clients in the same JVM? Are the servers in same? Are servers same JVM in the clients are? How many cores you have in your CPU? How much RAM you have? Or well, in general what kind of hardware you use? What are the parameters of the items and Subscriptions i.e. publishinginterval/maxkeepalivecount/lifetimecount?

Due to the legacy of the “stack level designs” most lower level blocking operations rely on shared threadpools, which has 64 Threads. This is shared between all clients and servers of the same JVM. This can be changed via StackUtils.setBlockingWorkerThreadPoolCoreSize(number of threads), though it should be noted that the default 64 is pretty much the only tested number.

December 17, 2021
13:01, EET
Avatar
gerstale
Member
Members
Forum Posts: 6
Member Since:
November 26, 2019
sp_UserOfflineSmall Offline

We are looking for solution to connect up to 70 OPC UA Servers and overall 2500 monitored Items from single communication node.
Our answers for your queries:
-> Are all the 50 items in a single subscription (per client/connection)?
Yes, all 50 items are in single subscription.
-> Are all the clients in the same JVM?
Yes, all clients are in the same VM
-> Are the servers in same?
Yes, also the test servers are in the same VM (in the real life, all of them are separted devices)
-> Are servers same JVM in the clients are?
No, the servers are running on separted host
-> How many cores you have in your CPU?
Dual core
-> How much RAM you have?
On servers and clients side JVMs run with -Xmx1024m -Xms512m
-> What kind of hardware you use?
Industrial PC with Debian Linux on Intel(R) Atom(TM) CPU E3827 @ 1.74GHz, 2G RAM
-> What are the parameters of the items and Subscriptions i.e. publishinginterval/maxkeepalivecount/lifetimecount?
The publishing interval in the mentioned test scenario set to 200mSec, all other parameters are default

What are the limits for Prosys SDK? How many connections could be managed? How many items per connections are allowed?

December 17, 2021
15:50, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 726
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

It is a bit complicated to write a good answer to this, so I’ll skip a lot of details for now.

Please try with
uaClient.setInitTypeDictionaryAutoUsage(false)
uaClient.setInitTypeDictionaryOnConnect(false)
(call before calling connect).

Only helps if you do not need custom Structure support. Also if you use any UaNode-based APIs such as UaClient.getAddressSpace().getNode() typically it would be better to have those flags as true (though we are aware that this either is not optimal, but it is … kinda better than what we used to have, but maybe not in this particular case), but assuming I found the right spec sheet for the CPU https://www.intel.com/content/www/us/en/products/sku/78478/intel-atom-processor-e3827-1m-cache-1-75-ghz/specifications.html), it is like from 2013. I would not do any _new_ projects with this old hardware (it is different if you already have them) regradless of it’s speed. And it is also a very low-end CPU maybe even back then. Like, SDK should … run, like it runs on a raspberry pi, but at least my expectation would be like more of running a single server with some few clients connected to it. Note that this is just a guess, as I do not have that exact hardware here to test and profile on.

Basically SDK-wise we sort of have no limits (except some “safety limits” in the server side in how many sessions can be made etc.), so it basically depends on how much the hardware can do, i.e. “as much as you have tested to work on the hardware you have”. I can note however that most of the things “take a Thread”. UaClient needs 2 Threads per instance, on the server side we need multiple per UaServer. One Thread per Session of the server (assuming the Session uses Subscriptions). One per a Subscription made to a Session. Plus then the common thread pools mentioned earlier (one “blocking” and another “non-blocking” with CPU cores amount of threads). On the server side each service request is handled on the blocking work pool.

Typically we’ll try to improve the things our customers wants from us, though performance related questions have not been common these days. Basically saying we’ll optimize things when that is needed thus things might not be … that optimized as there has not been that much demand for it.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
22 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 113

pramanj: 86

ibrahim: 74

kapsl: 57

rocket science: 52

gjevremovic: 49

Xavier: 42

fred: 41

TimK: 41

Fransua33: 39

Member Stats:

Guest Posters: 0

Members: 1743

Moderators: 17

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1206

Posts: 5137

Newest Members:

LimaomoT, eulaallcot, brain7955241817, barbaravillalobo, widallet, erminovski, etsuko73u61420, donnyblaxland, DonaldHAp, kelvin6887

Moderators: Jouni Aro: 918, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 726, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 24, Teppo Uimonen: 21, Markus Johansson: 36, Niklas Nurminen: 0, Matti Siponen: 163, Lusetti: 0

Administrators: admin: 1