Static memory for incoming UDP packets

Question

Objective:

To pass data from incoming UDP datagrams to 4 threads waiting on their respective queues. The application is supposed to work non-stop for pumping traffic to a DUT and process the incoming messages. This is what I am doing:

1. Public byte[] receiveData = new byte[512]
2. receivePacket = new DatagramPacket(receiveData, 0 , receiveData.length)
[The above 2 steps are in constructor of the listener class]
3. while (1)
a. ApplicationStart.serversocket.receive(receivePacket)
b. recvData = new String(receivePacket.getData()
. 
. {Processing of data}
.

c. recvData = null

Problem:

The memory is continuously increasing. I suspect this is because it is waiting for GC to claim the unused memory. I wish I can allocate some static memory outside the infinite while loop. The problem I face if I do this is that the “receivePacket.getData()” returns a byte array and to work on the data, I need to convert it into a string. All the data is in text format (to be specific it is MGCP packets). Please suggest any way to make sure that the memory is not exhausted. I don’t want to manually call the garbage collector. I am not sure of the overhead for GC.

Thanks

Answer 1

First, you shouldn't need to call the GC by hand, and it is generally a bad idea to do so.

Having said that, it is unclear what you mean by "the memory is continuously increasing".

If you mean that your application's memory allocation as observed from the outside is increasing, then that is normal. Java will allocate new objects as long as it can, and only run the GC when there is no space immediately available. From the outside, it looks like the JVM is using more and more memory.

If you mean that the JVM is reporting that it is running out of heap space (i.e. by throwing OutOfMemoryError), then you have a problem. However, this problem won't be cured by running the GC. Instead, you need to run a Java memory profiler to find the source of the leak, and fix it.

(Background: Java memory leaks are a bit different to (for instance) C / C++ memory leaks. In C / C++ a leak happens when your application neglects to free / delete an object when it is no longer needed. In Java, a memory leak happens when your application accidentally keeps a reference to an object that is no longer going to be used. If the GC thinks that the application might use the object again, it cannot reclaim it ... and hence the object stays around.)

Answer 2

Thanks.

By "the memory is continuously increasing", i actually meant the memory as visible in "top" output and memory usage displayed in "jprofiler". The "jprofiler" shows memory usage getting high where "new String()" is called. That's why i thought of allocating static memory beforehand.

Is there any way of allocating static memory this way? As i mentioned, i dont know any way of converting an incoming byte array to string without doing "new String()" which i am looking to avoid by some means.

Any help is highly appreciated. Thanks Deepak

Answer 3

Well. I sure hope its homework and not an offshored project...

Answer to your actual question:

You can create a number of preallocated packets, and add them to a queue. Grab an usued package from the start of the queue, and receive into it. When a handler-thread has handled the packet, it puts it at the back of queue.

Step 3.b should be avoided, as it creates a new byte array and copies the content from the packet into it, so rewrite the threads to handle packets (or byte arrays) as input.

It IS possible that you are receiveing packets faster than you can handle them; and then your code will use up all memory. (As you allocate the packets and strings and putting them in the handler threads' queues.)

If you are using a blocking queue, and waiting for "free" packets to read into, that won't happen; at least not in the same way. The UDP packets will be dropped or buffered (or probably both) somewhere in the OS's or javas network stack, so you need to take care of that. Which is why most "message oriented" protocol ends up using TCP/IP though they actually transport "datagrams"