Closed 644036249 closed 1 year ago
splatch
commented
1 year ago Sorry but your report does not contain code sample, just pictures of it.
By checking pictures themselves it is clear to me that you open connection multiple times to the same device but never close it. Please implement proper resource management in your application by calling connection.close().
Feel free to re-open issue in case if issue remains after above fixes are made.
glcj
commented
1 year ago Hello everyone,
As @splatch points out, it is recommended that you post sample code (test) in order to identify the problem.
You have to differentiate the problem between the Cache handler and the driver itself. The number of tasks that the driver raises is limited (of the Netty and those of the S7 driver itself).
In the version of the S7H driver found in [1], it identifies the thread pools in order to differentiate between them.
When you open the request again, add a screenshot of the jconsole to be able to identify your problem, which is already quite strange.
Kind regards,
What happened?
Did I find that there are many times during the PLC4J testing The threads in the waiting state were generated when I was not connected to the PLC. I wanted to test and read data from the PLC, but these times Waiting will occupy memory and ultimately cause the laptop to crash. However, the connection was made using getConnect and was also abnormally closed using jdk8's try(). May I ask if this problem can be solved at present and how to solve it?
Version
v0.10.0
Programming Languages
Protocols