11:06, EET
January 30, 2014
Hi,
is it possible programmatically to clear subscription notification buffer? (without making new subscription of course)
Maybe I am wrong but looks that after setPublishingEnabled(false) than again setPublishingEnabled(true)
SubscriptionNotificationListener.onDataChange(…) receives first values from buffer than it receives values after setPublishingEnabled(true).
BR,
Goran
12:15, EET
December 21, 2011
12:17, EET
December 21, 2011
15:04, EET
January 30, 2014
“The buffer should be cleared whenever there are messages”, you mean should be cleared after all messages are consumed?
Here is my problem that I have in visualization. I bound screen to the subscription so each time when I switch to another screen
I stop publishing of “non active screen” subscription and start publishing “active screen” subscription. This generally works ok except when
steady state of variables values occur. I am using SubscriptionNotificationListener to receive values.
For example I have on first screen variable which counts from 0 to 255.
I switch to second screen before variable reach 255, for example 185.
Now I am in second screen and wait counter to reach 255.
When I return to first screen the value will be 187 and should be 255.
That is because after firstScreenSubscription.setPublishingEnabled(true) it received messages from notification buffer and because variable is in steady
state no further changes will be received and value will stay 187.
Than I add one poll just before firstScreenSubscription.setPublishingEnabled(true) to pickup real value but I can’t control timing and in log I see
that poll works but after it is overwritten with old messages from notification buffer.
That is why I asked is it possible to clear buffer as it is possible it will resolve my problem, just clear it before poll.
Here is my log:
06.02.2015 15:29:15,241 DEBUG screen activation – !!!!!! ~~~~~~~~ activate()
// start poll
06.02.2015 15:29:15,241 DEBUG pollSubscription – Number of items in subscription: 1
06.02.2015 15:29:15,243 DEBUG notifyChange – Attrib of type class java.lang.Byte has value 255 in state VALID
06.02.2015 15:29:15,244 DEBUG notifyChange – Attrib of type class java.lang.Number has value 255 in state VALID
// end poll, start publishing again
06.02.2015 15:29:15,244 DEBUG notifyChange – Set publishing true
06.02.2015 15:29:15,361 DEBUG SubscriptionNotificationListener.onDataChange – item ns=4;s=AllDataTypesDynamic/ItemByte has changed, new value 210
// value 255 is overwritten with old value 210 from notification buffer
The same result is also when poll is after firstScreenSubscription.setPublishingEnabled(true) as poll is very quick.
Could you please help with some advice related to timing control?
BR,
Goran
12:26, EET
December 21, 2011
What I mean is that the client side SDK dispatched messages from the receive buffer independent of the PublishingEnabled setting. But I am thinking, whether the server might keep the old samples in its buffer and send them after publishing is again re-enabled. Which server are you connecting to?
If you increase the logging level to DEBUG, you should see more about the actual traffic in the SDK level.
15:01, EET
January 30, 2014
Hi Aro,
I am using local UaDemoServer.
Yes, I see, managing of subscription is independent from buffer. I tried also to remove/add new subscription listener from/to subscription and the result is the same. As listener become active it consumes old messages from buffer anyway.
The question is why there is only few messages in the buffer? Obviously setPublishingEnabled(false) influence that in the buffer will be only 1-3 messages
and after stop publishing, buffer will not receive any. Can we say that these changes 1-3 registered after set publishing to false are orphans?
Currently I don’t have idea how to resolve this issue.
Thanks,
Goran
13:20, EET
January 30, 2014
14:09, EET
December 21, 2011
I got this comment from Unified Automation, regarding the behaviour:
There is nothing you can do on the client side and there is also nothing that can be changed on the server side. The behavior is like defined by OPC UA.
If the client want to stop monitoring and clean up buffers for monitored items, the client must change the monitoring mode of the monitored items to DISABLED. This clears the buffers of monitored items and stops the sampling.
By changing the monitoring mode back to REPORTING, the server starts sampling into empty queues and delivers only new values.
14:37, EET
December 21, 2011
15:18, EET
January 30, 2014
Thanks a lot Aro for this post. I will try with change of monitoring mode for these items but I see potential problem as I have same item in multiple subscriptions.
Related to PublishingInterval, SamplingInterval, QueueSize everything is default:
s.setPublishingInterval(publishInterval); // ~200
s.setLifetimeCount(lifeTimeCount); // ~1000
s.setMaxKeepAliveCount(maxKeepAliveCount); // ~50
s.setMaxNotificationsPerPublish(maxNotificationsPerPublish);// ~1000
s.setNotificationBufferSize(100);
MonitoredItem sampling interval is 500ms, queue size is default 1
BR,
Goran
14:50, EET
January 30, 2014
Hi Aro,
again thanks for the post. Problem with multiple screens and multiple subscriptions resolved. Thanks to UA too.
It works as changing of monitoring mode is for particular item but per subscription. So if I change monitoring mode of item in one subscription
will not influence monitoring mode in another subscription. I thought it is opposite but luckily it is not.
BR,
jev
Most Users Ever Online: 1919
Currently Online:
21 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: 738
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1524
Posts: 6451
Newest Members:
jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettingerModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1