I’ve encountered the same issue in 8.0.4. The OPC-UA module has failed and restarting the module did not help.
I moved this to a new topic so you have a chance to give us some useful information.
What does “failed” mean? What failed? The connection to the built-in UA server? to another UA server? A driver connection? Do you have any logs?
Hi Kevin, thanks for your reply.
Some correction and information about this.
The version used is 8.0.6 which we recently upgraded from 8.0.5 (not 8.0.4).
I had an OPC connection set up for a server on the network.
I have left the gateway while others worked on it, including upgrading the gateway from 8.0.5 to 8.0.6.
I’ve returned to the project to find that the OPC wasn’t connecting and the Internal error page when going to OPC UA>OPC Connections in config.
The module for OPC UA is faulted with the following error:
java.lang.IllegalStateException: getString(BIND_ADDRESS_LIST) must not be null
at com.inductiveautomation.ignition.gateway.opcua.server.OpcUaServerSettingsRecord.getBindAddressList(OpcUaServerSettingsRecord.kt:136)
at com.inductiveautomation.ignition.gateway.opcua.OpcUaModule$setup$config$1.(OpcUaModule.kt:235)
at com.inductiveautomation.ignition.gateway.opcua.OpcUaModule.setup(OpcUaModule.kt:229)
at com.inductiveautomation.ignition.gateway.opcua.OpcUaModuleHook.setup(OpcUaModuleHook.kt)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$LoadedModule.setup(ModuleManagerImpl.java:2326)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.startupModule(ModuleManagerImpl.java:1169)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl$4.call(ModuleManagerImpl.java:864)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.executeModuleOperation(ModuleManagerImpl.java:920)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.restartModuleInternal(ModuleManagerImpl.java:839)
at com.inductiveautomation.ignition.gateway.modules.ModuleManagerImpl.restartModule(ModuleManagerImpl.java:831)
at com.inductiveautomation.ignition.gateway.web.pages.config.ModulePage$RestartAction.execute(ModulePage.java:563)
at com.inductiveautomation.ignition.gateway.web.components.ConfirmationPanel$1.onClick(ConfirmationPanel.java:50)
at org.apache.wicket.markup.html.link.Link.onLinkClicked(Link.java:189)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:258)
at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:216)
at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:240)
at org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:226)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:814)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:253)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:210)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:281)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:188)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:245)
at com.inductiveautomation.ignition.gateway.bootstrap.GatewayFilter.doFilter(GatewayFilter.java:74)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:530)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
at java.base/java.lang.Thread.run(Unknown Source)
8.0.6 (b2019111216)
Azul Systems, Inc. 11.0.4
The same error is thrown when I revert the module to 8.0.5 and the error goes away when I load a gateway backup before the upgrade although I do this sparingly since other users are actively using the gateway and the gateway backup is quite old.
It may be the case that it is unrelated to the upgrade and something else, but I’m quite lost as to what happened.
P.S. both the built-in and the external OPC UA server are faulted
It seems that the Bind Address List setting has a null value somehow.
If you can get to the OPC UA > Server Settings page you can correct this yourself, but if the UA module faulted this page may not be available and support will need to fix it up in the internal DB.
You can fix this yourself by accessing the secret internal DB page at http://localhost:8088/web/status/sys.internaldb
and running this query:
update OPCUASERVERSETTINGS set BINDADDRESSLIST = 'localhost' where 1=1;
Then restart your gateway.
Very nice, I was able to access the Server settings page and add the addresses for the external UA server and for the built-in server.
The external server now is connected and I can browse its content, but as for the built in server the connection has faulted and the error is as follows:
UaException: status=Bad_InternalError, message=unsupported protocol: null
at org.eclipse.milo.opcua.stack.client.DiscoveryClient.getEndpoints(DiscoveryClient.java:189)
at com.inductiveautomation.ignition.gateway.opcua.client.ClientManager.initializeObject(ClientManager.kt:76)
at com.inductiveautomation.ignition.gateway.opcua.util.ManagedObject$get$deferred$1.invokeSuspend(ManagedObject.kt:31)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
8.0.6 (b2019111216)
Azul Systems, Inc. 11.0.4
UaException: status=Bad_ConnectionRejected, message=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost/127.0.0.1:4096
at org.eclipse.milo.opcua.stack.client.transport.uasc.ClientChannelFsm$ClientChannelActions.lambda$connect$0(ClientChannelFsm.java:130)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:502)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:495)
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:474)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:415)
at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:540)
at io.netty.util.concurrent.DefaultPromise.setFailure0(DefaultPromise.java:533)
at io.netty.util.concurrent.DefaultPromise.tryFailure(DefaultPromise.java:114)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:327)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:343)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:665)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:612)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:529)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:491)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:905)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost/127.0.0.1:4096
at java.base/sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:327)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:340)
… 6 more
Caused by: java.net.ConnectException: Connection refused: no further information
… 10 more
8.0.6 (b2019111216)
Azul Systems, Inc. 11.0.4
The security is set to none/Basic128Rsa15 with User Source set to opcua-module
Now it sounds like the endpoint URL on your local/loopback connection is not right.
Go through endpoint discovery and use this endpoint URL:
opc.tcp://localhost:4096/discovery
If that doesn’t work try port 62541 instead.
1 Like
Hey Kevin,
The endpoint discovery for both the ports result in a rejected connection
UaException: status=Bad_ConnectionRejected, message=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information: localhost/127.0.0.1:4096 (and 62541 as well)
I think your OPC server settings must still be wrong for the machine then because it sounds like it isn’t binding successfully on startup. Can you upload some logs?
It appears that the cpu usage is extremely high (100% most of the time) and 93% usage by Zulu Platform x86, the log is spammed by ClockDriftDetector and high usage on a several opc-ua-executor threads.
Is the .idb file the correct log file?
Restarting the gateway seemed to have solved the high cpu usage,
but the built-in server is still disconnected.
Live Update: As soon as a designer session was opened the CPU usage skyrocketed
Need logs and a thread dump.
Looks like the bind failed because your server settings are still wrong. Can you screenshot that page?
Bind failed for endpoint opc.tcp://localhost:0/discovery
Looks like you have the port set to 0?
Who mangled all your settings?
Well set the “Bind Port” and restart again, should get you a little further.
Looks like setting the Bind Port to 62541 solved the problem.
In conclusion the problem was that for one reason or another the Server Setting was completely cleared.
It might just be a coincidence that the update to 8.0.6 just happened to be around the same time, but it was configured on the same machine that was working prior.
I’ll monitor if the high CPU usage comes back, but for now it seems to be normal even after opening the designer.
Thanks to Kevin for quickly finding out what went wrong. 