plc4j - ads : Why Connection terminated by remote when load-symbol-and-data-type-tables is true

[lecuyalex]

I recently been asked to update from version 0.9.1 to 0.12.0. In version 0.9.1, I could connect to the PLC without any issues. However, since updating to version 0.12.0, the connection is consistently terminated by the remote. Now, it only connects when load-symbol-and-data-type-tables is set to false.

var connectionString  = "ads:tcp://10.10.11.77?source-ams-net-id=172.31.16.1.1.1&source-ams-port=39&target-ams-net-id=5.62.206.200.1.1&target-ams-port=851";
          var driverManager = PlcDriverManager.getDefault();
          driverManager.getConnectionManager().getConnection(connectionString);
          System.out.println("Connected!");

Exception in thread "main" org.apache.plc4x.java.api.exceptions.PlcConnectionException: java.util.concurrent.ExecutionException: org.apache.plc4x.java.api.exceptions.PlcIoException: Connection terminated by remote
	at org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection.connect(DefaultNettyPlcConnection.java:154)
	at org.apache.plc4x.java.DefaultPlcDriverManager.getConnection(DefaultPlcDriverManager.java:80)
	at com.epsilia.Beckhoff.execute(Beckhoff.java:14)
	at com.epsilia.Main.main(Main.java:6)
Caused by: java.util.concurrent.ExecutionException: org.apache.plc4x.java.api.exceptions.PlcIoException: Connection terminated by remote
	at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073)
	at org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection.connect(DefaultNettyPlcConnection.java:145)
	... 3 more
Caused by: org.apache.plc4x.java.api.exceptions.PlcIoException: Connection terminated by remote
	at org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection.lambda$1(DefaultNettyPlcConnection.java:137)
	at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
	at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:492)
	at io.netty.util.concurrent.DefaultPromise.setValue0(DefaultPromise.java:636)
	at io.netty.util.concurrent.DefaultPromise.setSuccess0(DefaultPromise.java:625)
	at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:105)
	at io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:84)
	at io.netty.channel.AbstractChannel$CloseFuture.setClosed(AbstractChannel.java:1164)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.doClose0(AbstractChannel.java:755)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.close(AbstractChannel.java:731)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.close(AbstractChannel.java:620)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.closeOnRead(AbstractNioByteChannel.java:105)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:174)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:842)

[lecuyalex]

Update.
When load-symbol-and-data-type-tables is true.It works approximately 1 out of 10 times.

[splatch]

Its still rather good result, some of older Beckhoff devices do not have symbol table. They are able to handle only direct addressing (decimal format). I've seen some old TwinCAT2 device going nuts when symbol table was attempted to read - connection was also terminated. Is your device capable of handling symbolic addresses?
Also, the AMS router layer which handles TCP connection might terminate second connection from same host/port pair if its attempted too often. I am not certain on internal logic of AMS router, but I've seen cases when I had to restart program in order to re-establish connection.
It is really blurry how PLC decides if connection is terminated.