11:20, EEST
March 31, 2022
Hello,
After updating the server and client SDK to 5.0.0 the communication starts from time to time (not always) to throw the following exception:
com.prosysopc.ua.ServiceException: Bad_SecureChannelClosed (code=0x80860000, description=”The secure channel has been closed.”)
ServiceResult=Bad_SecureChannelClosed (0x80860000) “The secure channel has been closed.”
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:424)
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:1903)
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:334)
…
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_SecureChannelClosed (code=0x80860000, description=”The secure channel has been closed.”)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.close(SourceFile:419)
at com.prosysopc.ua.stack.application.SessionChannel.closeSecureChannel(SourceFile:352)
at com.prosysopc.ua.client.UaClient.cgE(SourceFile:5408)
at com.prosysopc.ua.client.UaClient.reconnect(SourceFile:3809)
at com.prosysopc.ua.client.UaClient$a.chg(SourceFile:298)
at com.prosysopc.ua.client.UaClient$a.run(SourceFile:248)
at java.base/java.lang.Thread.run(Thread.java:833)
Beside the update there were no changes in the script, so this must be cause by the update.
Seems to be caused by some timeouts, however, in the release notes I did find anything about that.
Do you have any idea what could be the cause? Or what can I try to get rid of it?
Thanks!
12:04, EEST
April 3, 2012
Hi,
Uh oh, that doesn’t sound good..
From what SDK version did you update to 5.0.0?
I could see a theoretical case if you updated from before we had limits on maximum number of securechannels (some of the later 4.x updates) and you would have more clients connected to the server than the limit (default is max sessions +10%), the server will now drop connections that do not contain an activated Session, if it is at limit. But after UaClient.connect returns successfully, you do have an activated session and after that it should not break “randomly”. If there is a connection break and reconnect happens, then it would not be activated until reconnect is successful. Though, this would basically mean there would always be some clients failing the connection, and it would just change which one is “left out”.
Can you give a rough estimate on the number of clients connecting to this server?
Any option to check via https://www.prosysopc.com/blog/opc-ua-wireshark/ and send a capture to uajava-support@prosysopc.com?
14:44, EEST
March 31, 2022
Hi, thanks for the reply!
I actually updated from 4.10.6-24 (to 5.0.0-95)
I have discovered this via JUnit testing (I did not deploy to the production, and will probably not as the risk is relatively high).
The test suite is starting a server and creating a client once when initialized:
private static UaServer server;
private static UaClient client;
@BeforeAll
static void setup() throws Exception {
// create server
server = new UaServer();
server.setPort(14840);
server.setServerName(“OPCUA/Test”);
server.getSecurityModes().add(SecurityMode.NONE);
server.setUserTokenPolicies(UserTokenPolicies.SECURE_USERNAME_PASSWORD);
var appDescription = new ApplicationDescription();
appDescription.setApplicationName(new LocalizedText(“TestServer”));
appDescription.setApplicationUri(“urn:test:opcua”);
appDescription.setProductUri(“https://test.com/opcua”);
appDescription.setApplicationType(ApplicationType.Server);
server.setApplicationIdentity(ApplicationIdentity.createCertificate(appDescription, “Test”, 512));
server.start();
// create client
client = new UaClient(“opc.tcp://127.0.0.1:14840/OPCUA/Test”);
client.setApplicationIdentity(new ApplicationIdentity());
client.setSecurityMode(SecurityMode.NONE);
client.setUserIdentity(new UserIdentity(USERNAME, PASSWORD));
client.setTimeout(10, TimeUnit.MINUTES);
}
For each test I create a new connection:
@BeforeEach
void connect() throws ServiceException {
client.connect();
}
And I disconnect it after each test:
@AfterEach
void disconnect() {
if (client.isConnected()) {
client.disconnect();
}
}
(I tried to add Thread.sleep(1000) here to give the disconnecting some time, but it did not help)
Then, there are about 10 tests that connect to the server and read/write some data or attributes:
@Test
void browses_deviceSet_node() throws Exception {
var references = client.getAddressSpace().browse(new NodeId(nsIndex, “DeviceSet”));
assertThat(references).hasSize(2);
var displayNames = references.stream()
.map(ReferenceDescription::getDisplayName)
.map(LocalizedText::getText)
.collect(Collectors.toSet());
assertThat(displayNames).contains(“Device1”, “Device2”);
}
@Test
void reads_device_attributes() throws Exception {
var browseName = client.readAttribute(new NodeId(nsIndex, DEVICE_NODE_ID_REAL_1), Attributes.BrowseName);
assertAll(
() -> assertThat(browseName.getStatusCode().getValue().getValue()).isEqualTo(StatusCodes.Good.getValue()),
() -> assertThat(((QualifiedName) browseName.getValue().getValue()).getName()).isEqualTo(“Device1”)
);
}
@Test
void writes_serialNumber_value() throws Exception {
var value = client.writeValue(new NodeId(nsIndex, “Device1/SerialNumber”), “Updated”);
assertAll(
() -> assertThat(value).isTrue(),
() -> assertThat(currentValue).isEqualTo(“Updated”)
);
}
Not really very demanding, but one or two tests fail with the mentioned exception almost every run of the test suite.
15:24, EEST
April 3, 2012
That is similar to how we run our own integration tests. Hmm… this case is odd because if there would be something badly wrong I’m quite sure it would have occurred during our tests (and we do manual ones as well) or now that we are updating our own applications to use it as well.
But I’ll guess it has to be some sort of (our) bug still.
Is there option to make a self-contained test that compiles (if, please send to uajava-support@prosysopc.com and mention this forum thread)? I tried the above and while I can make it compile with some manual changes, it most likely is not the exact one you use, since basically every test will fail to Bad_NodeIdUnknown as the DI model is not loaded (assumption since you refer “DeviceSet”).
15:36, EEST
April 3, 2012
Hmm.. actually, please ignore parts of the above.
We mostly use “client.setStatusCheckInterval(0);” in our tests (that was one difference I noticed vs. yours). This shouldn’t affect anything in practice (skipping details here), but if I remove that then I was able to see the same error as you do in few of the tests. So I have something to reproduce this now.
15:47, EEST
March 31, 2022
15:52, EEST
March 31, 2022
15:57, EEST
April 3, 2012
We will investigate this. Not sure if it affects anything real (we haven’t yet noticed this at least when we have tested our apps using 5.x). Basically the ‘0’ just stops UaClient from checking the server status, this has a dual purpose in real apps: it checks if the server is still up and is a way to detect connection breaks and it keeps the Session from timing out, it is not that useful in tests (and “pollutes” wireshark logs we sometimes look based on the tests). But our 4.x wont fail the test even if I comment that out, so something in 5.x has broken this.
16:16, EEST
March 31, 2022
16:24, EEST
April 3, 2012
I think we made a mistake as part of fixing another issue (in 5.0.0) and basically this error now happens if you happen to immediately use the same UaClient object after you have .disconnect()’d it. The so called “PublishTask” thread (more like the worker thread of UaClient; there is a separate ReadThread for the socket), hasn’t shut down properly (and the “another issue” was sort of related to this), manages to make a status check as it’s last action (after which it would have seen the shutdown flag), causing a .reconnect, and then the SDK user .connect happens concurrently and most likely the secure channel is kinda replaced inbetween and the status check will timeout as it is in the other channel. Or something like that, I think.
15:03, EEST
April 3, 2012
We have now fixed this in our latest beta build. It will be included in the next release (no date on that yet; probably in few weeks). If you (or anyone else reading this) wish to try earlier, ask via uajava-support@prosysopc.com and mention this thread.
15:33, EEST
March 16, 2017
Bjarne Boström said
We have now fixed this in our latest beta build. It will be included in the next release (no date on that yet; probably in few weeks). If you (or anyone else reading this) wish to try earlier, ask via uajava-support@prosysopc.com and mention this thread.
so 5-0-2 contains the fix, right?
17:02, EEST
December 21, 2011
rocket science said
so 5-0-2 contains the fix, right?
Yes, that is fixed. See the “Changes to Client SDK”
Most Users Ever Online: 1919
Currently Online:
35 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: 734
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16, edgardo3518Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1