FULL PRODUCT VERSION :
The behaviour changed from se 5 to se 6 and 7.


ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.24-23-server #1 SMP Thu Nov 27 19:19:15 UTC 2008 i686 GNU/Linux
Linux 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 i686 i386 GNU/Linux


EXTRA RELEVANT SYSTEM CONFIGURATION :
Nothing about hardware

A DESCRIPTION OF THE PROBLEM :
3-4 years ago I wroted a client/server application with java.nio and Socket Channels and Socket SSL Support with javax.net.ssl.SSLEngine.
With Java SE 5 all worked fine.
Now I begin having problems with SE 6 and 7.
The problem is that method (handshake already done).

result = SSLEngine.unwrap(sslBuffer, buffer)

have 2 different behaviour with SE 5 and 6 (or 7).

REGRESSION. Last worked in version 5.0

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
// sslReadBuffer contains data to unwrap

SSLEngineResult result;

do {
      result = sslEngine.unwrap(sslReadBuffer, readBuffer);
      handshakeStatus = result.getHandshakeStatus();
      sslStatus = result.getStatus();
} while(
   (sslStatus == SSLEngineResult.Status.OK) &&
    (handshakeStatus == SSLEngineResult.HandshakeStatus.NEED_UNWRAP) &&
    (result.bytesProduced() == 0)
);

1) In SE 5 it go out from the while with the sslReadBuffer.position() == sslReadBuffer.limit() and readbuffer with data.
2) In SE 6 it go out (same condition met) with the sslReadBuffer.position() < sslReadBuffer.limit() and readBuffer with data, but not all data!!!



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect the same behaviour from any java major version
ACTUAL -
in SE 5.

for 90 bytes in sslReadBuffer unwrap produces 13 bytes in readBuffer and sslReadBuffer.remaining() == 0.

in SE 6 or 7.

for 90 bytes in sslReadReadBuffer unwrap produce 1 byte in readBuffer and sslReadBuffer.remaining() > 0.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
The only workaround is to run client version and server version with SE 5.
But my client is running in many places and connect to server via internet I cannot control client jvm versions.
The strange think is that the problem starts a month ago, very strange.