Hi there,
Firstly, I've been a way from the Grizzly scene for several months, so it's
great to come back to a project which looks more active than ever judging
by the amount of development and discussion.
I've been testing out our Grizzly 2.1.2 based LDAP SDK using SSL and I've
run into this SSL concurrency bug:
http://java.net/jira/browse/GRIZZLY-1079
However, I am unable to move to 2.1.6 (or any versions before that) because
our SSL based unit tests are failing
in org.glassfish.grizzly.ssl.SSLEncoderTransformer.wrapAll() with an
IllegalArgumentException when updating the message position:
java.lang.IllegalArgumentException
at java.nio.Buffer.position(Buffer.java:218)
at
org.glassfish.grizzly.memory.ByteBufferWrapper.position(ByteBufferWrapper.java:161)
at
org.glassfish.grizzly.memory.ByteBufferWrapper.position(ByteBufferWrapper.java:61)
at
org.glassfish.grizzly.ssl.SSLEncoderTransformer.wrapAll(SSLEncoderTransformer.java:139)
at
org.glassfish.grizzly.ssl.SSLEncoderTransformer.transformImpl(SSLEncoderTransformer.java:104)
at
org.glassfish.grizzly.ssl.SSLEncoderTransformer.transformImpl(SSLEncoderTransformer.java:66)
at
org.glassfish.grizzly.AbstractTransformer.transform(AbstractTransformer.java:73)
at
org.glassfish.grizzly.filterchain.AbstractCodecFilter.handleWrite(AbstractCodecFilter.java:103)
at org.glassfish.grizzly.ssl.SSLFilter.accurateWrite(SSLFilter.java:565)
at org.glassfish.grizzly.ssl.SSLFilter.handleWrite(SSLFilter.java:207)
at
org.glassfish.grizzly.filterchain.ExecutorResolver$8.execute(ExecutorResolver.java:111)
at
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:286)
at
org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:223)
at
org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:155)
at
org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:134)
at
org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:78)
at
org.glassfish.grizzly.filterchain.DefaultFilterChain.write(DefaultFilterChain.java:408)
at org.glassfish.grizzly.nio.NIOConnection.write(NIOConnection.java:338)
at org.glassfish.grizzly.nio.NIOConnection.write(NIOConnection.java:330)
at com.forgerock.opendj.ldap.LDAPConnection.search(LDAPConnection.java:756)
I don't think that we're misusing the Grizzly APIs, but at the same time
I'm very surprised no one else has hit this issue. The relevant bit if
Grizzly code is here:
private TransformationResult<Buffer, Buffer> wrapAll(
final SSLEngine sslEngine,
final Buffer originalMessage) throws TransformationException {
TransformationResult<Buffer, Buffer> transformationResult = null;
Buffer targetBuffer = null;
Buffer currentTargetBuffer = null;
final ByteBufferArray originalByteBufferArray =
originalMessage.toByteBufferArray();
for (int i = 0; i < originalByteBufferArray.size(); i++) {
final ByteBuffer originalByteBuffer =
originalByteBufferArray.getArray()[i];
currentTargetBuffer = allowDispose(memoryManager.allocate(
sslEngine.getSession().getPacketBufferSize()));
final ByteBuffer currentTargetByteBuffer =
currentTargetBuffer.toByteBuffer();
try {
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.log(Level.FINE, "SSLEncoder engine: {0} input:
{1} output: {2}",
new Object[]{sslEngine, originalByteBuffer,
currentTargetByteBuffer});
}
final SSLEngineResult sslEngineResult =
sslEngine.wrap(originalByteBuffer,
currentTargetByteBuffer);
originalMessage.position(
originalMessage.position() +
sslEngineResult.bytesConsumed());
In my case originalMessage is a ByteBufferWrapper wrapping a
HeapByteBuffer. On entry to the method the buffer's position is 0 and its
limit is 39. The call to sslEngine.wrap() encodes the full content of the
buffer and updates its position to 39. Clearly, the last line above is
going to fail, since it's going to set the new position to 39+39=78.
Am I missing something? Let me know what you think and I can raise a JIRA
issue if you agree.
Matt