JoelBender
Atomic File Write Hangs
I am attempting to send a device hex file from a laptop to an embedded device using bacpypes and atomic file writes. Most of the time this works but every once in a while the atomic write just stops running.
It is doing two things in a while loop, send a data chunk, then read a multi state value. Has anyone ever seen the atomic write files hang indefinitely?
Is your application using threads? If you attach a debugger to the application layer (by adding --debug bacpypes.app or something similar) is it receiving the ack? Are you getting acks from the other device at the network layer but they are somehow not making it to the application layer?
Using WireShark to watch the file transfer I do see my device sending the correct ACK. I have not debugged the code yet, but I will be doing so.
An update before we all leave for the holidays. I have two devices sending out writegroups. At some points in time the devices send out a burst of writegroups (6 or more). At this point my python script just halts. No idea why. Hoping someone there has an idea.
Another update, it seems writegroups are not the underlying issue but YABE. If I open YABE and select a devices device object YABE reads all the necessary information. If I never click off of the device object YABE periodically re-reads the object. Constantly reading the object seems to cause bacpypes to halt.
If I were to start debugging bacpypes is there a good place for me to start looking?
Start with adding a --debug bacpypes.core to the application and see if an exception is raised. The run() function will trap exceptions with the "catch all" statement at the bottom (where it says except Exception as err) and that can usually be traced back to some kind of message or service. There's a difficult to debug condition in threaded applications where the request context is created in one thread but the response comes/goes in another (the requests coming from YABE and the responses generated by your main thread maybe?) and the two can't "see" each other so the application stalls.
How far into the re-reads does it stall? Can you run the samples/MultipleReadPropertyHammer.py application in another session or window? The point list will have to be filled in, but you can run both your application and the "hammer" on the same machine as long as they aren't using the same UDP port.
Thank you for the response Joel. Is there a way to email you I have two wireshark captures of the failure. My most recent failure shows that my atomic write file is never ack's by the device, however my device is still active on BACnet. My second captured failure shows my device did ack the atomic file write. In both cases there are multiple read request immediately after the atomic write file.
If they're not too big, email them to me, joel{at}carrickbender.com but I'm skeptical that I can reproduce the problem with just the network traffic. There are probably going to be some subtle changes to the application especially if you are using threads. Edit: I managed to recover my Dropbox account, so you can share big(er) ones with that, or Google Drive.
I myself am not using threads. I took your WhoIsIam example and added the read/write code from your other examples. I do not think this is using multiple threads. I have also 100% confirmed it is the wait function and looking into solutions.