+1 you are awesome! :) Am Fr., 28. Feb. 2020 um 16:46 Uhr schrieb Etienne Robinet < [email protected]>:
> 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 > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > > > > > > > > > >
