[
https://issues.apache.org/jira/browse/PLC4X-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187677#comment-17187677
]
Christofer Dutz commented on PLC4X-132:
---------------------------------------
I just pushed a change, that should now correctly report the problem and give
some hints on the log output if somethings goes wrong. And definitely it should
no longer just block indefinitely.
Thanks for taking the time to report this.
> [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
(v8.3.4#803005)
