Log In
Register
Topic RSS
13:55, EEST
September 1, 2025
Offline
Hi,
I have tried to restart the opc ua server in my java application. I invoked the shutdown(1, “Message”) and the start() methods of the prosys sdk to achieve it. Even though the server restart is successful and the server status flip can be seen, the server URI becomes unreachable after the restart(Tried to connect through a UAExpert UAClient). If the connection was preestablished the nodes stay reachable. It keeps us from starting a new connection. It seems to be some issue with improper shutdown and start of the server. But do anyone have any idea on what could be the issue here?
15:56, EEST
April 3, 2012
Offline
Hi,
If you know for sure that it will be restarted, you can use .shutdown(1, “Message”, false), then it doesn’t clear nodes (and try to reinitialize nodemanagers). If not, then please try adding server.getAddressSpace().getInstanceDeclarationHierarchyCache().clear(); between shutdown and start and let us know if it helped. Probably we should make SDK do that automatically in the future.
15:43, EEST
September 1, 2025
Offline
Thanks for the response.
Yes, We tried to stop and start the server using shutdown(1, “Message”) and it is shutting down the server and clearing up the nodemanagers. The reinitialization and start of the server is able to bring back the server to Running state also. Just that the server URI created during the initialization is not reachable. The reinitialization and start is following the same steps followed during the application startup, so that the data set for application identity, servername(OPCUAServer), port, endpoints are all the same.
Endpoints accessible prior to restart of the opcuaserver –
opc.tcp://localhost:5840(default)
opc.tcp://localhost:5840/OPCUAServer
opc.tcp://localhost:5840/OPCUAServer/External
Endpoints accessible post the restart of the opcuaserver –
opc.tcp://localhost:5840(default)
The missing 2 endpoints are present in the discovery URL list object of the UAServer class but not accessible when tried to establish a connection through a client.
The server.getAddressSpace().getInstanceDeclarationHierarchyCache().clear(); or shutdown(1, “Message”, false) did not help here
17:28, EEST
April 3, 2012
Offline
Sorry for a bit late reply. I believe the cause is the 3 endpoints compared to typical 1-2. Can you explain your use-case a bit more? Typically a server only has the base url part (that runs Discovery endpoints only) and then the ServerName-including part. Or sometimes there is no server name and the whole server runs in the base url part. Having more than that would be quite uncommon.
Have you used com.prosysopc.ua.server.UaServer.addEndpoint(String, SecurityMode, UserTokenPolicy…) to add the 3rd? Or the 2nd as well? I have now managed to reproduce that any endpoint added this way wont survive restarting, the one added “naturally” via .setServerName does work.
We will investigate why this happens, though I must note we have a known issue regarding that the .addEndpoint only basically adds alternative Endpointurl, we do not yet support scenarios where the endpoints would have different security settings (thus basically only the modes set to the UaServer apply).
18:39, EEST
April 3, 2012
Offline
(A bit of investigation…)
IF you used the .addEndpoint (see prev. post), it is possible the following workaround might work. Call the following in sequence for the UaServer:
.shutdown (using ‘true’ or version without the parameter which use true by default)
.init
.addEndpoint
.start
The ‘true’ (either parameter or default from versions without it) will internally call UaServer.close automatically, this resets initialization flag thus UaServer.start would call .init automatically again (if not called manually before it). The .init resets the endpoints to be based on the ServerName, thus any .addEndpoint(s) would be lost.
That at least resolved the scenario I managed to create with using .addEndpoint, however using ‘false’ for the .shutdown did also resolved it, so it is possible your case is something else as you say it didn’t help.
10:04, EEST
September 1, 2025
Offline
In our use case, we do not actually use the 1st endpoint. We have set the Servername as OPCUAServer which should create the 2nd endpoint and added the 3rd endpoint using the .addendpoint(). Both the endpoints are required for 2 different types of users to access.
Yes we have tried to perform the sequence of operations you mentioned:
.shutdown
.init
.addEndpoint
.start
Along with these steps, we also tried with the setApplicationIdentity prior to calling the init to follow the same process which we use during the application startup. Still the 2nd and 3rd endpoint are inaccessible
16:02, EEST
April 3, 2012
Offline
What version of the SDK you are using?
Could it be possible to get some sample that reproduces this, e.g. based on the sampleconsoleserver example? If yes, please send it to jsdk-support@prosysopc.com
