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
AccessLevel issue
January 29, 2014
14:33, EET
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

I’m using a custom NodeManager, and I’m seeing some weirdness with AccessLevel.

After I first start my server, the tags that should be writable appear with AccessLevel Readable and Writable. If I click on a node in the tree that is not supposed to be Writeable I see Readable for both attributes, but every node I look at after that shows only Readable for AccessLevel.

I’m using UAExpert as a client, but I don’t think the problem is in the client – restarting the client doesn’t help, but restarting the server does.

January 29, 2014
15:16, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Make sure you override IoManager.getAccessLevel()/getUserAccessLevel(). It’s been a bit odd otherwise.

January 30, 2014
21:35, EET
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

Okay, I overrode getAccessLevel() and getUserAccessLevel(). I can see the code returning the right values, but UAExpert still shows only Readable for the R/W tag after I have looked at the read-only tag.

January 31, 2014
8:29, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

I cannot reproduce the problem myself. I added these to MyBigIoManager:

@Override
protected EnumSet getAccessLevel(
ServiceContext serviceContext, NodeId nodeId,
UaVariable variable) throws StatusException {
DataItem d = getDataItem(nodeId);
if (d.getName().endsWith("1"))
return AccessLevel.READWRITE;
return AccessLevel.READONLY;
}

@Override
protected EnumSet getUserAccessLevel(
ServiceContext serviceContext, NodeId nodeId, UaVariable node) {
DataItem d = getDataItem(nodeId);
if (d.getName().endsWith("1"))
return AccessLevel.READWRITE;
return AccessLevel.READONLY;
}

And I get proper access levels to UaExpert with both.

DO you get the same behaviour with the Java Client (or SampleConsoleClient?)

January 31, 2014
15:19, EET
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

Yes, I see the same problem with the SampleConsoleClient. What’s the Java client? That would be a nice thing to have to play with when I run into issues like this.

I’m logging what getAccessLevel and getUserAccessLevel return, and you can see below that Tdint is always returning READWRITE for both. Tint returns READONLY for AccessLevel and READWRITE for userAccessLevel. Could that be the issue?

Anyway, with the sample client, I see the same issue – I browse to Tdint, read the access levels and they’re both 3. Then browse to Tint and see the access levels are both 1 – I assume the toolkit is applying the accesslevel as a mask to useraccesslevel? After that, I browse back to Tdint, and then both access levels are 1.

Looking at Tdint:
2014-01-31 10:12:07,408 [Blocking-Work-Executor-2] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:12:07,408 [Blocking-Work-Executor-2] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
… lots of these …
2014-01-31 10:12:34,435 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:12:34,435 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tdint is READWRITE

Looking at Tint:
2014-01-31 10:12:36,656 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tint is READONLY
2014-01-31 10:12:36,656 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tint is READWRITE

2014-01-31 10:13:06,436 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tint is READWRITE
2014-01-31 10:13:06,436 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tint is READONLY

Back to Tdint:
2014-01-31 10:13:09,832 [Blocking-Work-Executor-1] INFO – AccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:13:09,832 [Blocking-Work-Executor-1] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE

2014-01-31 10:13:16,012 [Blocking-Work-Executor-2] INFO – UserAccessLevel: ns=2;s=Tdint is READWRITE
2014-01-31 10:13:16,012 [Blocking-Work-Executor-2] INFO – AccessLevel: ns=2;s=Tdint is READWRITE

January 31, 2014
16:04, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Yes that might explain it. The IoManager should indeed be masking the UserAccessLevel with AccessLevel, but your results do not seem like it does, indeed.

Java Client is this one.

January 31, 2014
19:46, EET
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

I think I wasn’t clear about the masking. The log messages above show what I’m returning – for the read-only tag, I’m returning READONLY for AccessLevel and READWRITE for UserAccessLevel. Both UserAccessLevel and AccessLevel are sent to the client as READONLY, which seems correct.

That is where the bug is, though – When I changed getUserAccessLevel to return READONLY for the read-only tag as well, the problem disappeared. There must be something weird going on in the masking code.

Thanks for the help.

January 31, 2014
20:49, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

Sorry, Tim, I got lost again. Where do you think the bug is?

February 2, 2014
12:18, EET
Avatar
TimK
Member
Members
Forum Posts: 41
Member Since:
June 27, 2012
sp_UserOfflineSmall Offline

I think you’ll see this problem if you change your BigIoManager test above to always return READWRITE for UserAccessLevel, and leave the AccessLevel code as above.
Look at a tag ending with 1 – it will be READWRITE. Then look at a tag ending with 2 – it will be READONLY. Go back to the tag with a 1 and you’ll see it as READONLY.

February 3, 2014
9:06, EET
Avatar
Jouni Aro
Moderator
Moderators
Forum Posts: 960
Member Since:
December 21, 2011
sp_UserOfflineSmall Offline

OK, thanks: I finally got it! And I found the bug, which is a bit silly. The IoManager was doing this:

userAccessLevel.retainAll(accessLevel);

which modified the READWRITE “constant”, making it in effect READONLY…

You can fix this in your code, by making getUserAccessLevel to return a copy of the enum set, instead of the original:

return EnumSet.copyOf(AccessLevel.READWRITE);

The fix to IoManager will be in the next version.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
16 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 124

pramanj: 86

ibrahim: 74

rocket science: 65

kapsl: 57

Sabari: 51

gjevremovic: 49

Xavier: 43

fred: 41

TimK: 41

Member Stats:

Guest Posters: 0

Members: 1749

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1323

Posts: 5649

Newest Members:

WalterFOUNC, datafastproxiespx01, LenkaLok, seoninet, justinevillanuev, namtrott5457, DonaldWibip, AlfredoEthix, andreidla, everangel7021

Moderators: Jouni Aro: 960, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 860, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 222, Lusetti: 0

Administrators: admin: 1