CAR 311294 Any known workarounds

[JÞB]

FTP Close Session.vi will not unregister a session if server is unresponsive.

This is fixed in 2012 but I've been fighting some memory leaks in existing systems.  I've been unable to duplicate durring testing however, during testing we do not write to the FTP server production data goes to.  And, we have no control of the networks' responsiveness.. AHA this bug may be my next most likely candidate!

So is there a knon workaround for this that can be implemented in 8.6 - 2011?

[Travis-E]

Hey Jeff,

Unfortunately, there seems to be no work arounds available. The issue was recieved and held until it was reported to be resolved in 2012.

[Ben]

---

@Jeff Bohrer wrote:

FTP Close Session.vi will not unregister a session if server is unresponsive.

This is fixed in 2012 but I've been fighting some memory leaks in existing systems.  I've been unable to duplicate durring testing however, during testing we do not write to the FTP server production data goes to.  And, we have no control of the networks' responsiveness.. AHA this bug may be my next most likely candidate!

So is there a knon workaround for this that can be implemented in 8.6 - 2011?

---

Thinking out to try and help...

If yo uwrite a small exe that is invoked using the sys exec run command the LV clean-up for the samll exe may clean-up after itself.

Not elegant but if your FTP operations do not occur too often, it may be a work-around.

Ben

[JÞB]

Thank you both!

Ben,  I believe you are right that if I could do all FTP opperations through an isolated app that the memory leak would be cleaned up.  with a system running 150K transactions per week I think it is not feasable for me though.

(I actually shook my magic 8-ball and got "Cannot Determine Now")

Three key elements exist to cause this leak to occur

• Must have LabVIEW 2011 or older
• Must be transacting with FTP
• Server must be unresponsive

The IT dept is simply going to need to find a means to improve FTP Server responsiveness.