The problem occurs when the
 JacORB client gets a BIG reply. In handling the big reply, the VM runs
 throws an java.lang.OutOfMemoryError exception

[jacorb.orb.giop] ERROR : unexpected exception during doWork
org.omg.CORBA.NO_MEMORY: java.lang.OutOfMemoryError: Java heap space
        at org.jacorb.orb.BufferManager.getBuffer(BufferManager.java:252)
        at org.jacorb.orb.BufferManager.getBuffer(BufferManager.java:208)
        at org.jacorb.orb.giop.GIOPConnection.getMessage(GIOPConnection.java:38\
8)
        at org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.ja\
va:464)
        at org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:71)
        at org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:61)
        at java.lang.Thread.run(Thread.java:595)

The client invocation hangs at this point instead of getting the
 CORBA.NO_MEMORY exception. A work around is to have a timeout
 on the invocation, however that brings out the real problem. In
 handling the java.lang.OutOfMemoryError the client thread just
 bails out without cleaning up the tcp buffer. In a big reply scenario,
 this backsup to the server and can potentially deadlock the server.
 At the minimum it will eat up server resources (memory, file
 descriptor etc.). A proper solution may be:

 1. Have the client first cleanup the current GIOP package from the
    tcp buffer.
 2. Once cleanup is done, throw a org.omg.CORBA.NO_MEMORY exception
    to the client app.

I will attach my test next. I have used a TAO based c++ server as I didn't want
a VM related issues there. This problem is independent of the VM version,
although different VM's may have slightly differing behavior. Bottom line at
some point the VM will exhaust all its heap and throw a OutOfMemoryError
exception, which point JacORB handles incorrectly.

Ciju