Hi Matt,
Welcome back! Yes, please log an issue and we'll address it asap.
-rl
On 11/7/11 9:56 AM, Matthew Swift wrote:
> 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
>