BasicStream allocation

[Cyril]

Hello,

We have an application that creates an ICE server who receives big objects (around 4 Mo) from a client (service sendData()). Sometimes we get an OutOfMemoryException : Java Heap Space.

I specify that :

- we are using a high value for the Ice.MessageSizeMax parameter (10240 and even bigger).
- we have an ice thread pool that may contain up to 10 threads (minimum 1)
- we are using the 3.2.1 version of ICE, but I've done tests with a 3.3.0 version, and the results are the same.

While profiling the application, I've noticed that a call from the client always creates several BasicStream objects that hold a reference to a an array of byte[]. No problem so far. The trouble is that these arrays of bytes aren't necessarily released once the GC passed. The more threads there are server side, the more memory is not released by the GC. After 3 calls to the sendData service I had 46 Mo (-Xmx=128Mo) of data referenced by the BasicStreams!

I've read this thread (IceInternal.BasicStream seems to hold on to objects, but I still think that BasicStream objects are cached after a request.

I've got several questions :
- For one thread server side (Ice.ThreadPool.Server.SizeMax=Ice.ThreadPool.Serv er.Size=10), the server starts with 3 BasicStreams. When the sendData service is called, the server creates 6 more BasicStreams, and one is garbaged. For the next call, the server is always using these 8 BasicStreams. What is the logic in all that (<=> when is a BasicStream garbage collected?)?
- Is there a limit to the number of BasicStream per thread?
- Is it possible to tune this behaviour?

I thought that a lower value of Ice.MessageSizeMax would prevent this problem (because the buffer used by the BasicStreams is smaller), but it didn't...

Thank you in advance,

[bernard]

Hi Cyril,

Welcome to our forums!

You should try:

Ice.CacheMessageBuffers=0

See the Ice Properties reference for details.

Best regards,
Bernard

[Cyril]

Thank you very much it fixed the problem!

Regards,
Cyril