search

eclipse / milo

Eclipse Milo™ - an open source implementation of OPC UA (IEC 62541).
http://www.eclipse.org/milo
Eclipse Public License 2.0
1.15k stars 427 forks source link

Subscribtion fails if a ManagedExecutorService is provided #58

Closed tosuns closed 7 years ago

tosuns commented 8 years ago

Hello,

I'm trying to get my opcua client to work in a JavaEE environment and want to provide a ManagedExecutorService instead of an simple JavaSE ExecutorService, to avoid a possible memory leak. It is recommanded to use ManagedExecutorServices in JavaEE environments, but the connection to the opcua server fails during the creation of a subscribtion with the following exception:

Caused by: UaException: status=Bad_Timeout, message=timed out waiting for secure channel at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$handlerAdded$2(UaTcpClientMessageHandler.java:140) at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:581) at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:655) at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:367) ... 1 more

Do you have an idea, what would cause this exception ?

If I use a JavaSE or don't provide any ExecutorService, everything works fine, but after undepolying my application I get warnings:

The web application [/web-app] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@9e7c533]) and a value of type [io.netty.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@5e58365]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

kevinherron commented 8 years ago

Is this an external/3rd party UA server you are connecting to? I can't imagine what difference using a ManagedExecutorService makes... the timeout you're seeing is because the UaTcpClientMessageHandler timed out waiting for the OpenSecureChannelResponse from the server. It uses Netty's HashedWheelTimer to schedule the timeout, which doesn't use the stack's executor, so if the executor is really preventing things from working it's preventing the delivery of the OpenSecureChannelResponse somehow.

Can you Wireshark the connection while using a ManagedExecutorService to see if there's a difference in what's being sent/received? If the managed service isn't working or running tasks like expected it's possible nothing is being sent or received at all...

kevinherron commented 7 years ago

If you make any progress on this or can point to a concrete issue in Milo that needs to be fixed feel free to re-open an issue.