TCP Memory Leak?

[LJM282]

I have a relatively simple TCP server (attached).  When connected from a localhost client, the server runs without expanding memory, however, when connected from a network client the memory usage of the server expands rapidly.

Two instances of this server VI are opened dynamically and run from the main VI of the application, each with a separate listening port as the input.

This VI has been built using LabVIEW 8.2.1.  No memory issues arise if no client is connected.

What am I missing?

[altenbach · Accepted solution]

It's hard to tell without the missing globals and other info. Here are some ideas: 

• Try to create the listener once outside the big loop instead of creating a new listener every two seconds (or after each connection). Close the connection only after the big while loop has completed.
• Whenever the error condition of the big case happens, you have generated a connection ID that never gets closed. Can you probe how often an error occurs here and if so, what error you get?
• It is possible that when you close the connection and then immediately try to create a new listener on the same port, the port might still be in use finishing up the old connection.

Can you attach a fully functional set of VIs (client and server) that demonstrates the problem?

[jon_mcbee]

The easiest way to fix a TCP memory leak is to use wire nuts on the ends of the reference and error cluster, see the image below.  Make sure to use the correct gauge or you may not fully resolve the leak.

 

Message Edited by jmcbee on 04-01-2009 11:34 AM

Message Edited by jmcbee on 04-01-2009 11:44 AM

[LJM282]

---

altenbach wrote:

• Try to create the listener once outside the big loop instead of creating a new listener every two seconds (or after each connection). Close the connection only after the big while loop has completed.

---

We tried this and the problem seems to have gone away.  Thanks.

[AnalogKid2DigitalMan]

Better get those red coercion dots on you nuts looked into 😉

-AK2DM

[jon_mcbee]

---

AnalogKid2DigitalMan wrote:

Better get those red coercion dots on you nuts looked into 😉

-AK2DM

---

I guess that is what I get for connecting with functions that aren't my type

[JK1]

I checked out the wire-nuts from the JKI and i couldnt really figure out how its going to solve the memory leaks.  I could barely find a variant inside with the connector panes of different size.  I really expected something terrific when i saw it would solve memory leaks. What is behind the simple variant!!! are there some easter eggs hidden in the block diagrams???

Is it really meant to fix the memory leaks??

Message Edited by JK1 on 04-03-2009 04:33 AM

[JK1]

---

The easiest way to fix a TCP memory leak is to use wire nuts on the ends of the reference and error cluster, see the image below.  Make sure to use the correct gauge or you may not fully resolve the leak.

---

 Still i couldnt get the essence of the above post.  Find the pics attached which says lot about the wire-nuts.  There are four nuts of various sizes!!!! marked with gauge sizes with different colours.  This post has got 13 kudos!!!!! altogether and hence i am toooo intrested in knowing what is it really capable off.

Message Edited by JK1 on 04-03-2009 04:56 AM

[F._Schubert]

You might find some more info here, also take a look at the comments where users describe their ideas on that technology

http://blog.jkisoft.com/news/announcing-the-new-jki-wire-nut-toolkit-for-labview/#comments

Note that it was just released on 1st April, so it is really new stuff.

Felix 

[Baji]

I too tried the same wire nuts.I am also wondering about the statement  "Make sure to use the correct gauge or you may not fully resolve the leak"

The VI has only a variant and it is supposed to resolve all the memory leaks as said the above statement.(I am wondering there is some magic inside the block diagram