Hi Matt,
glad to see you back :))
AFAK Ryan is helping you with the issue.
IMO our tests pass because Grizzly (tests) uses HeapMemoryManager by
default, which is not directly wrapping ByteBuffer, so
SSLEngine.wrap(...) operation doesn't change position of the original
Grizzly Buffer.
We have to extend our SSL tests to use different memory managers.
Thanks.
WBR,
Alexey.
On 11/07/2011 10:07 PM, Matthew Swift wrote:
> 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
> <mailto: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
>>
>
>