Log In
Register
Forum
Topic RSS
10:26, EET
July 27, 2021
Offline
Hi,
I have added subscriptions in my application. Can you please suggest on these messages?
UaClient: handlePublishResponse: no subscription with ID=721 SequenceNumber=1263422; response discarded
UaClient: handlePublishResponse: no subscription with ID=721 SequenceNumber=1263423; response discarded
UaClient: handlePublishResponse: no subscription with ID=721 SequenceNumber=1263424; response discarded
Can you please suggest how to rectify this and handle them?
16:12, EET
April 3, 2012
Offline
Hi,
That is logged whenever we receive a PublishResponse and we cannot find the Subscription (in the client; per the ID) for which the response was. It is hard to say more without more info.
What version of the SDK you are using?
The Subscription system is entirely reliant on the server sending proper data. For example, a server could have just sent incorrect data back. IF that happened, then it would be just a cosmetic problem (this is logged on INFO level).
Can you say anything about the server you are connected to? Do you know which SDK has been used to make it?
Can you reproduce this or was it an one-off event?
Did you do anything when this happened such as removing the Subscription from the client or disconnecting the client? Was there any communication breaks?
Do you know if you had a Subscription with that ID? (basically, check logs when it was created, or did you receive successfully data for it in the past before this?)
Can you attach an SubscriptionAliveListener to the Subscription and tell if the onTimeout or onLifetimeTimeout method were called?
12:47, EET
July 27, 2021
Offline
Hi,
I am using prosys SDK – 3.16-542.
We are subscribing for huge batch of nodes with multiple subscriptions.
It runs fine in the beginning, but we see messages dropped after multiple days and investigating the same. And trying to understand if anything related to this message or sequence number that we need to handle and is causing messages being discarded.
Seeing these messages constantly in logs at ‘INFO’ level, but do not have more data what caused and if it is an issue.
Also, can you point to doc where I can get more reading and info on this part?
14:49, EET
April 3, 2012
Offline
That is a quite old version of the SDK; the latest is 4.6.2.
We have done some fixes during the years:
https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_Java_SDK_3_Release_Notes.html
https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html
Thus, basically please try with 4.6.2 first to see if this is something we have already fixed. Any possible fixes would be made on top of the latest release.
In general handling all that is SDK’s responsibility. The only thing SDK doesn’t do well even in 4.6.2 is IF after a connection break creation of Subscriptions work, but the items fail, they would not be re-attempted (in 4.6.0 Subscription.setRecreateFailedItems was added, though it is off by default as it could also lead to infinite re-attempts and is sort of basically a workaround for some servers which do not have address space fully loaded by the time they accept connections).
Like the only practical thing that can be done is to manually remove and re-add the subscription if you somehow detect it has failed. In 3.2.0 we added SubscriptionAliveListener.onLifetimeTimeout, which might help. Though, the onTimeout of it could maybe help as well. See the javadocs of those methods for more info. Neither should be called under normal conditions, onTimeout means we didn’t receive a keepalive in time, but the subscription should still exist on the server per spec rules and the onLifetimeTimeout means it shouldn’t be on the server anymore either. However, either would require the server to fail send us publishresponses, and we basically do constantly send them.
Do you have some numbers to give for “huge batch of nodes”? 100? 1000? 10000? more? + the number of subscriptions?
What publishinterval+keepalivecount+lifetimecount you use for the subscriptions (assumnig they are the same).
In general how much data you see per some time unit? e.g. 1000 datachanges/second?
Anyway, when the Subscription is UaClient.addSubscription’d it is created on the server (or if not connected, during connection). It will get a SubscriptionId (given by the server, in the CreateSubscriptionResponse ‘SubscriptionId’). If we receive a Publishresponse, whose getSubscriptionId cannot be found (by checking UaClient.getSubscriptions), we log it. The sequence number logged is just for info, at this stage it doesn’t do anything (only when the data would be processed it matters).
The only way for the Subscription’s id to be reset internally by the SDK is if:
– A connection break happens and the subscriptions must be recreated
– If the Subscription is removed from the UaClient
– If the UaClient is disconnected (and keepSubscriptions is false, which by default is false)
– Plus some internal logic after e.g. reconnect, but they would be recreated at that point as well
i.e. should not happen under normal conditions.
Please note that this is per the current version, since this has evolved over the years it could have been different in 3.1.6.
The subscription system is hard to tune, as many parameters affect it. See https://reference.opcfoundation.org/Core/docs/Part4/5.13.1/.
Do you have option to check with https://www.prosysopc.com/blog/opc-ua-wireshark/ what happens on the wire level?
11:48, EET
July 27, 2021
Offline
Thanks for your inputs!
We will upgrade to latest version. If you have, can you share details/steps to do the same from Prosys?
We have about 45000 nodes and we create one subscription for every 500 nodes and add monitored items.
For subscriptions, I am only setting ‘publishinterval’ which is a variable and ideally every second or a multiple of seconds like 2s or 4s etc. Other properties are default.
Please suggest if you think we have to update any other property for our case.
And we expect majority of monitored items keep sending data every interval (usually every second) in our application.
And w.r.t. subscription id refresh, do you suggest we remove and recreate subscriptions if we get such errors, as no guarantee it is done internally by SDK? If so, can you suggest where all or which callback methods we can add triggers to refresh to avoid such situations?
Also can you suggest method to reset the subscriptions. Does the client.reconnect method do that? Or we have to manually remove and add subscriptions from client, when required? We were assuming once the subscriptions are created, they will be taken care from SDK.
15:18, EET
April 3, 2012
Offline
Assuming that to mean extensions etc.: send mail to sales@prosysopc.com
If you meant a migration guide, there is a 3->4 guide (“Prosys_OPC_UA_SDK_for_Java_Migration_Guide”) in the ‘tutorials’ folder of 4.x distribution zips. It is mostly an easy process (depending on how you view things and what parts of the SDK you have used).
Preferably we would continue this once you have migrated, as that alone could maybe fix this. Anyway, i is a lot easier to to say how things work in the current release version.
I’ll take it is about 90 subscriptions then? That is … a lot.
It has been too long since we last did some performance tests, but the last time we did (https://aaltodoc.aalto.fi/handle/123456789/20173?show=full, https://aaltodoc.aalto.fi/bitstream/handle/123456789/20173/master_Tahvanainen_Heikki_2016.pdf) I can see that at least 100000 items was doable (though, I believe this was using a single Subscription). However it should be noted that in these tests we could also control the server side i.e. define limits as high as needed in the server side.
I’ll continue a bit in a second post.
15:28, EET
April 3, 2012
Offline
Going for slower than the default 1000ms for the publishInterval normally shouldn’t need changes to the 20 maxkeepalivecount + 60 lifetimecount. IF you would go faster then typically they must be increased. Otherwise e.g. 10ms interval would require a keepalive in 200ms if no datachanges and 600ms without a publishrequest to send that keepalive would cause the server to delete the subscription due to no interaction.
However, typically there is also just a few Subscriptions (like ~1-10). I do not think we have done a similar setup than yours is (or too long time ago to remember). But each keepalive/datanotification will use a PublishRequest. But with ~90 Subscriptions, this means there is “a contest” for them in the server side.
Servers typically have some limit of how many publishrequests the client can queue. We try 2x subscriptions by default, so 180 here. If server responds that is too many we will begin calculating a setpoint to be at the limit. Some servers might have a limit of just 1-10 reqs per Session. Our server side implementation would default to max 100 per Session.
Once we receive a reply we will send another publishrequest (this happens before it is processed by the client in the so called PublishTask Thread of the UaClient).
Assuming the server really took the 180 request in it’s queue, this is probably fine (the client side will send another as soon as once is received). But if it can take only e.g. 10 it can be a different matter. I believe 10 is the highest the OPC UA Specification goes currently in the Profiles/Facets (https://reference.opcfoundation.org/v104/Core/docs/Part7/5.2/, search “Publish Min”). But I have no details on the server you are connected to, thus I do not know the limit you have there.
But! if it was deleted by the server, that still should not result in the “handlePublishResponse: no subscription with ID…” log.
15:45, EET
April 3, 2012
Offline
Hmm.. IF we could know for certain that a connection break would have happened it could also maybe explain things.
Note that I still do recommend updating to 4.x first, but after that if it continues:
Add a ServerStatusListener to UaClient like MyServerStatusListener in the SampleConsoleClient sample. Check if the state changes from Running and then back to it later.
If we had to recreate the subscriptions to the server, there would be a time-window in which the server could respond with a PublishResponse for a Subscription we have just created before we have processed the CreateSubscriptionResponse for it. Though, I would expect only a single “no subscription with ID” in this case, as the Subscription would be without items (they are recreated as the last step, we would have the ID for the subsription at that point).
15:57, EET
April 3, 2012
Offline
And the “reset part”. UaClient.removeSubscription and then addSubscription again should “reset” it. Though it should be noted that this is just a workaround. And it would only be needed if the SubscriptionAliveListener.onLifetimeTimeout was called. It is sort of the … opposite of your problem (since you basically _have no_ Subscription with the correct id, you would also not see the callback; i.e. this is only useful if you stop receiving data for a subscription, but it must have been created to the server first, and if it was created, it would have _some id_ due to that, so it is a different problem if this callback is called by the SDK).
Assuming defaults UaClient does handle reconnections automatically, in that case .reconnect() must NOT be called manually doing so would mess up things, as SDK does internally call it as well (in the later/current 4.x calling it manually in this situation would print a warning). It can only be called if the automatic reconnect is disabled (which should not be done without reason). And in some future version we most likely will change it so that a call without it being disabled would throw.
IF you actually have called UaClient.reconnect() manually while the autoreconnect is on, it could have resulted in the situation with “no subscription with ID”, as in practice it is possible that a subscription was created twice (by the manual call + SDK internal reconnect). Only one would be tracked by the client, but the server would have them both, leading the changes form the other being logged as the “no subscription with”.
Most Users Ever Online: 1919
Currently Online:
10 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 735
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
