Done!
http://java.net/jira/browse/GRIZZLY-1111
Let me know if you need any help testing. I'd also be interested to know
why no one else has seen this (incl. Grizzly unit tests): do you think that
we're doing something unusual or wrong?
Many thanks,
Matt
On 7 November 2011 19:21, Ryan Lubke <ryan.lubke_at_oracle.com> wrote:
> 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
>
>
>