[
https://issues.apache.org/jira/browse/PLC4X-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878330#comment-16878330
]
Julian Feinauer commented on PLC4X-132:
---------------------------------------
Yesterday I discussed with Tim and he was able to reproduce the problem.
Currently the `connect()` method is not idempotent for most Implementations of
PlcConnection.
It seems that ins ome situations with the Pool or OPM or simply by misusage of
the user multiple calls to connect occur.
This leads to the generation of "zombie connections" (as the a new is build but
the handle to the old one is discarded).
[~timbo2k] Could you share your code here that reproduces the issue?
We will provide a patch for that and add some code to prove that the problem is
solved.
> [S7] Communication to S7 PLC dies in some situations
> ----------------------------------------------------
>
> Key: PLC4X-132
> URL: https://issues.apache.org/jira/browse/PLC4X-132
> Project: Apache PLC4X
> Issue Type: Bug
> Components: Driver-S7
> Affects Versions: 0.4.0
> Reporter: Julian Feinauer
> Priority: Blocker
>
> The following is from the Mailing Thread [1]:
> In the last weeks we observed multiple times strange behavior when connecting
> to Siemens S7 devices.
> We have not yet been able to trace it down entirely but I have the assumption
> that it is an issue with the PooledPlcDriverManager.
> Whats the issue?
> When doing requests (either via OPM or the “regular” API) we come at a point
> where all subsequent requests simply fail (and in some cases we were no
> longer able to send requests to the PLC from other instances, so it looks
> like the internal server went down).
> Whats the setup?
> When I remember correctly, all situations where this occurred used the Pool
> as Basis.
> We had it both with OPM and the normal API but NOT with the Scraper.
> I remember that I spent like a hole day at the Hackathon in Mallorca to get
> all timeout things to work correctly, as the S7 does not like when you simply
> cancel your request futures.
> Currently there are two “suspects” from my side.
> First, the pool calls the “.connect()” method on a now Connection it
> establishes but by API convention you also have to do that in your code so it
> gets called multiple times, which could fuck up stuff.
> Second, connection can also time out (but its no future in our API) so in the
> Scraper I implemented it as Future with timeout (as I’m unsure how everything
> behaes if the pool starts to initialize a connection but then the “waitTime”
> times out and it abandons this).
> [1]
> https://lists.apache.org/thread.html/328a6780b34b4fd2e3298e9e70340293ebb397b1978a7b631030067e@%3Cdev.plc4x.apache.org%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
