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 >> > > >> > > >> > > >> > >> > >> > >> >> >>
