Hello again, I forked the projected, created my branch, apllied my modification and sent a PR !
Hope this will help in any way, Have a nice weekend, Etienne On 2020/02/28 14:48:44, Julian Feinauer <[email protected]> wrote: > Hi Etienne, > > indeed a great Job and nice how you managed to solve the issue yourself. > Would also love to see a PR : ) > > Julian > > Am 28.02.20, 15:08 schrieb "Christofer Dutz" <[email protected]>: > > Hi Etienne, > > great to hear you fixed this problem ... we would be super-happy if you > could provide us with a pull-request. > I think we wrote down the procedure on our website: > https://plc4x.apache.org/developers/contributing.html > > So in general: > - Fork the Apache PLC4X repo on github > - Add this fork as remote to your checkout > - Commit and push your changes to your fork > - Create a Pull-Request in the Github UI > > Looking forward to your PR ( > > Chris > > > > Am 28.02.20, 15:04 schrieb "Robinet, Etienne" <[email protected]>: > > Quick update, > I managed to fix this issue, it was really a problem with the > tpudReference. The tpud was generated as Integer but later casted to > short. > So the app send a request with tpudRef=65536 but got a response with > tpudRef=0 and couldn't handle it. I added this quick fix in the S7 > protocol > and it has worked for over 100k exchanges, will do a long time test > soon: > https://i.imgur.com/mOIu3hN.png > > As I have a quite modified version from 0.7.0-SNAPSHOT, how is the > procedure to submit my work any time soon to you so you can review it > and > maybe use the things you need for merging ? > > BR, > > Etienne > > Le ven. 28 févr. 2020 à 13:59, Robinet, Etienne <[email protected]> a > écrit : > > > Good afternoon, > > this is the version I am using. > > I noticed that the application blocks when the tpduReference is > back to 0 > > (going over the limit of Short). Do you know by any chance if this > could be > > the reason? > > Was the library already designed to fetch such a number of data in a > > single run? By browsing a code I saw that this tpduRef is given by > the > > AtomicIntegerwith initial value 10. > > > > > > Here the last correctly handled response: > > > > > > > TPKTPacket[payload=COTPPacketData[parameters={},payload=S7MessageResponseData[tpduReference=65534,parameter=S7ParameterReadVarResponse[numItems=1],payload=S7PayloadReadVarResponse[items={S7VarPayloadDataItem[returnCode=OK,transportSize=BYTE_WORD_DWORD,dataLength=16,data={0,-61}]}],errorClass=0,errorCode=0],eot=true,tpduRef=0]] > > > > And here the response that blocks: > > > > > > > TPKTPacket[payload=COTPPacketData[parameters={},payload=S7MessageResponseData[tpduReference=0,parameter=S7ParameterReadVarResponse[numItems=1],payload=S7PayloadReadVarResponse[items={S7VarPayloadDataItem[returnCode=OK,transportSize=BYTE_WORD_DWORD,dataLength=16,data={0,-61}]}],errorClass=0,errorCode=0],eot=true,tpduRef=0]] > > > > > > > > > > Le ven. 28 févr. 2020 à 13:42, Christofer Dutz > <[email protected]> > > a écrit : > > > >> Exactly > >> > >> Am 28.02.20, 10:37 schrieb "Robinet, Etienne" <[email protected]>: > >> > >> By new driver do you mean the ones from the /develop branch > >> (0.7.0-SNAPSHOT) ? > >> > >> Etienne > >> > >> Le ven. 28 févr. 2020 à 10:32, Christofer Dutz < > >> [email protected]> > >> a écrit : > >> > >> > H Etienne, > >> > > >> > the old drivers were unfortunately blocking ones ... with > the new > >> drivers > >> > all requests have timeouts and will get cancelled if no > responses > >> come in > >> > in a given timeframe. > >> > > >> > Chris > >> > > >> > Am 28.02.20, 10:12 schrieb "Robinet, Etienne" > <[email protected]>: > >> > > >> > Well, after 1 hour it froze again. The thing is that > this time > >> it does > >> > not > >> > seem to be any memory leakage nor network overloading. > The > >> program just > >> > stops, and the camel context tells me, when I shut it > down, > >> that there > >> > is 1 > >> > inflight exchange. The programm froze at the same point > as the > >> IDE app: > >> > when the PollingConsumer created an PlcReadRequest and > waits > >> for the > >> > response. It is known that the receive() method of the > >> PollingConsumer > >> > is > >> > blocking if no message is coming. > >> > > >> > Etienne > >> > > >> > Le ven. 28 févr. 2020 à 09:34, Etienne Robinet < > >> [email protected]> a > >> > écrit : > >> > > >> > > Hi there, > >> > > > >> > > I am currently testing some fix/workaround. I tried a > simple > >> test > >> > case > >> > > like the previous one but I moved the connection to > the PLC > >> outside > >> > the > >> > > while loop and only connecting again if the connection > drops. > >> > > Without temp, I don't get memory leaks (it seems) but > the IDE > >> froze > >> > after > >> > > +- 60k MessageHandles. > >> > > But with a 100ms sleep, I managed to get some decent > result. > >> I am > >> > > currently testing my route again, and TCP ports/ > Memory seem > >> not > >> > getting > >> > > overloaded/leaking! > >> > > > >> > > I changed the Camel integration by putting the > PlcConnection > >> in the > >> > > Endpoint class with a getter that can be used by > >> Consumer/Producer > >> > to send > >> > > requests. Idk if this is the correct way to do it, but > it > >> seems it > >> > kinda > >> > > fixed/patched for a while my problem. > >> > > > >> > > Cheers, > >> > > > >> > > Etienne > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > >> > >> > > > > >
