Log In
Register
Forum
Topic RSS
18:26, EEST
June 18, 2015
Offline
Hello,
we are using the client Java SDK 2.2.2 and we have the following use case:
The application creates 60+ OPCUA clients, each having exactly 1 subscription with <10 nodes connecting to one commercial OPCUA server.
We see these WARN-level entries in our log:
org.opcfoundation.ua.common.ServiceFaultException: ServiceFault: Bad_TooManyPublishRequests (0x80780000) "The server has reached the maximum number of queued publish requests."
Diagnostic Info:
at org.opcfoundation.ua.transport.tcp.io.SecureChannelTcp.onMessage(Unknown Source) ~[xxx.jar:na]
at org.opcfoundation.ua.transport.tcp.io.TcpConnection$ReadThread.run(Unknown Source) ~[xxx.jar:na]
I know that the last version of the SDK had issues around the topic of public requests. Hence, I would like to ask the following questions:
– Is this still related to these issues?
– Could this actually mean that data could get lost, because the server’s cache of publish requests is full with requests from some clients and if the requests of other clients are used up, the new data cannot be send?
– Can we prevent this by changing the clients’ configuration? Currently, we don’t set the publish request factor setting, meaning that the standard value of 2 is used by the SDK.
– Can we do anything at all on client side or does the server operator needs to adapt the server’s settings to prevent subscription data loss in our use case?
Thanks a lot in advance!
Kind regards,
Jun
20:26, EEST
December 21, 2011
Offline
This specific aspect of the SDK wasn’t changed in the latest revisions. Although the publish request timeouts, which may have an effect. Except that in 2.2.2 the default PublishRequestTimeout of UaClient was returned back to “Max Value”, meaning that it is no longer used in practice, unless you define a value for it. This might be able to cause the problem, if the server is not managing the timeout, whereas the client is and is sending more and more requests to the server. So, please check that you haven’t changed that from the default.
If that is not the case, it does sound strange, since the server should have a separate limit for publish requests per session – and 2 requests is not a lot per session (since you only have one subscription per session).
Most probably the only way to get rid of the problem is to modify the server configuration if possible. Or if you can somehow monitor the server behaviour.
The error does not usually cause loss of data, unless this is a symptom of some other problem in the server. When the server responds with these errors it means that the request queue in the server is full and the request just bounces back immediately because of that. So the server should have enough requests in the queue (since it’s full), which it can use to report notifications normally.
13:36, EEST
June 18, 2015
Offline
Thank you for your answer!
This specific aspect of the SDK wasn’t changed in the latest revisions. Although the publish request timeouts, which may have an effect. Except that in 2.2.2 the default PublishRequestTimeout of UaClient was returned back to “Max Value”, meaning that it is no longer used in practice, unless you define a value for it. This might be able to cause the problem, if the server is not managing the timeout, whereas the client is and is sending more and more requests to the server. So, please check that you haven’t changed that from the default.
I checked, but we are not setting the PublishRequestTimeout. The PublishRequestFactor is set to 2 (which should be the same as the standard value).
If that is not the case, it does sound strange, since the server should have a separate limit for publish requests per session – and 2 requests is not a lot per session (since you only have one subscription per session).
Most probably the only way to get rid of the problem is to modify the server configuration if possible. Or if you can somehow monitor the server behaviour.
We cannot modify or monitor the server directly. However, we can ask the server operator to do some specific steps. In this case, it would help us a lot is you could point us to what to tell the server operator more specifically.
Thanks a lot in advance!
13:54, EEST
December 21, 2011
Offline
Try to find out why the server is limiting the number of publish requests or if you can find out the actual length of the publish request queue, when it starts reporting these problems.
Most Users Ever Online: 518
Currently Online:
9 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
Ibrahim: 76
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 683
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6261
Newest Members:
digitechroshni, LouieWreve, Kickbiche, karrimacvitie5, graciela2073, sagarchau, elviralangwell4, Donnavek, Eddiefauth, DonaldPoomaModerators: Jouni Aro: 1010, 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: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
