Log In
Register
Forum
Topic RSS
11:20, EEST
June 8, 2016
Offline
Using Prosys-OPC-UA-Java-SDK-Client-Binary-2.2.2-638.jar
We get sporadic INFO log “Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions” talking to Prosys OPC UA Simulation Server whilst subsrcibing to: Objects.Simulation.Counter1 et al.
1. what is the cause of this?
2. how we should avoid this?
3. can we detect this via MonitoredDataItemListener?
4. how should we react to this?
5. would we have to expect this message from a real server?
12:42, EEST
April 3, 2012
Offline
In which situation this did happen? (i.e. during normal communication or when disconnecting? Or when deleting/removing Subscriptions?)
1. If there are no Subscriptions to the server and server receives/processes PublishRequest, it responses with that status code. If the UaClient has Subscriptions when it receives that statuscode it logs that info because this situation should not happen.
2-4. You should not need to do anything, i.e. this is something that the SDK should handle for you. The thing is that we are not exactly sure what should be done in this situation. The current log is to inform that something out of ordinary has happened. One option would be to call DeleteSubscription for all subscriptions and recreate them, but it might be a bit overkill solution. Does everything work after you receive this log? Does it appear only once or does it repeat that? Currently this situation cannot be handled in a listener (normally you could add a UaClientListener to the UaClient and return false from validatePublishResponse in order to skip handling, but that only works for non-bad responses).
5. This should not happen during normal operation. On disconnecting maybe depending on server implementation.
The Spec Part 4 section 5.13.8.1 on DeleteSubscriptions states that
“Successful completion of this Service causes all MonitoredItems that use the Subscription to be
deleted. If this is the last Subscription for the Session, then all Publish requests still queued for
that Session are de-queued and shall be returned with Bad_NoSubscription.”
so if you were removing subscriptions, this might happen because UaClient does queue a number of PublishRequests to the server.
If you are disconnecting this might also happen, because the server does deletesubscriptions internally.
– Bjarne
17:48, EEST
June 8, 2016
Offline
We are now experiencing the same problem talking to a S7-1500.
2017-03-24 10:59:34,894 DEBUG [Blocking-Work-Executor-17] client.UaClient:? handlePublishResponse: response=0
2017-03-24 10:59:34,894 INFO [Blocking-Work-Executor-17] client.UaClient$a:? Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
2017-03-24 10:59:34,997 DEBUG [Blocking-Work-Executor-21] client.UaClient:? handlePublishResponse: response=0
2017-03-24 10:59:34,997 INFO [Blocking-Work-Executor-21] client.UaClient$a:? Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
2017-03-24 10:59:34,999 DEBUG [Blocking-Work-Executor-22] client.UaClient:? handlePublishResponse: response=0
2017-03-24 10:59:34,999 INFO [Blocking-Work-Executor-22] client.UaClient$a:? Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
2017-03-24 10:59:35,096 DEBUG [Blocking-Work-Executor-26] client.UaClient:? handlePublishResponse: response=0
2017-03-24 10:59:35,096 INFO [Blocking-Work-Executor-26] client.UaClient$a:? Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
2017-03-24 10:59:35,100 DEBUG [Blocking-Work-Executor-25] client.UaClient:? handlePublishResponse: response=0
2017-03-24 10:59:35,100 INFO [Blocking-Work-Executor-25] client.UaClient$a:? Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
Notice how “fast” this goes?
Bjarne Boström said
1. If there are no Subscriptions to the server and server receives/processes PublishRequest, it responses with that status code. If the UaClient has Subscriptions when it receives that statuscode it logs that info because this situation should not happen.
Initially, we are doing this:
subscription = new Subscription();
subscription.addNotificationListener(this.subscriptionNotificationListener);
client.addSubscription(subscription);
Are you saying we should not do this as long as subscription is empty? What if we add it non-empty but then empty the subscription? Do we fall in that case again?
13:47, EEST
April 17, 2013
Offline
Hello,
As a first thing, the currently newest Java SDK version is 2.2.6 and you should update to the latest version. As you mentioned, you are currently using version 2.2.2. According to my own tests, the version difference should not affect this directly but there has been some changes in the way that subscriptions are handled.
Initially you mentioned that the error was “sporadic” with Simulation Server. Now it seems that with the S7-1500 OPC UA server the error is happening constantly. So, it may be that we are actually looking at two different problems here even though the symptom is the same (Got Bad_NoSubscription as a PublishResponse).
The mentioned error should only happen in situations where the client application thinks it has a valid subscription but the server application does not contain the same subscription. For example, shutting down the server application or removing subscriptions might trigger this logging.
What is the situation when this logging happens with Simulation Server? Can we somehow reproduce the same issue with Simulation Server ourselves?
As Bjarne said, a single log line of this condition is normal and expected in certain situations.
However, if you receive this error continuously then there is a real problem somewhere. Based on the provided information I think there is an actual interoperability issue with the S7-1500 OPC UA server.
If I understood correctly, the mentioned log lines come when you create an ’empty’ subscription. Does the same condition happen if you create a subscription that does contain a valid MonitoredDataItem?
Does the same error happen if you connect to the S7-1500 OPC UA server with an unmodified SampleConsoleClient, browse to some variable node and create a subscription?
15:52, EEST
June 8, 2016
Offline
I can confirm that we had a working workaround with 2.2.7 by making sure there is at least one item in the subscripton before we add it to the client. Again, the version was probably relevant. Now this “works for us”.
I see 2.3.0 has quite some changes with regard to subscriptions?
14:43, EET
March 23, 2017
Offline
Hello all
we have same issue with library Prosys 2.3.2-781
2017-10-31 13:16:40,650 INFO [xecutor-50] client.UaClient$a. a – Got Bad_NoSubscription as a PublishResponse, although we have connected Subscriptions
what should be a reason of this?
Is it PLC problem? S7-1200
Is it OPC server problem? – Kepware 5.20
Do you need some more information?
Thank you very much
Ondrej Pilik
16:01, EET
December 21, 2011
Offline
Do you get it occasionally or constantly? Did you experience a connection break before it started or do you have any other hint what might have started it on your client application.
If it is occasional, you can simply ignore it, but if the client goes out of sync with the server and keeps on reporting these constantly, you may need to reconnect to the server. Also in this case, it would be good to analyse the situation and scenario a bit more, if you can reproduce it.
Most Users Ever Online: 1919
Currently Online:
16 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: 727
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
ellis87832073466, zkxwilliemae, gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
