Thanks Ryan and Alexey! :-)
While testing Ryan's fix I simplified our code a bit and, in doing so,
switch over to a HeapBuffer which fixed the problem for me for the reasons
you state below.
However, if I substitute the HeapBuffer for a ByteBufferWrapper my tests no
longer hit the IllegalArgumentException due to Ryan's fix, but now instead
go into an infinite loop. I'm currently trying to diagnose what's going on
and I'll update the issue when I have a better idea.
Is it possible to publish the Grizzly sources for Maven snapshots like
1.7-SNAPSHOT as it would help with debugging? Currently Maven is failing to
find them:
09/11/2011 20:32:14 GMT+01:00: [INFO] Downloaded
http://maven.forgerock.org/repo/snapshots/org/glassfish/grizzly/grizzly-framework/2.1.7-SNAPSHOT/grizzly-framework-2.1.7-SNAPSHOT-sources.jar
09/11/2011 20:32:15 GMT+01:00: [INFO] Downloaded
https://maven.java.net/content/repositories/snapshots/org/glassfish/grizzly/grizzly-framework/2.1.7-SNAPSHOT/grizzly-framework-2.1.7-SNAPSHOT-sources.jar
09/11/2011 20:32:15 GMT+01:00: [ERROR] Could not download sources for
org.glassfish.grizzly:grizzly-framework:2.1.7-SNAPSHOT
Cheers,
Matt
On 9 November 2011 17:23, Oleksiy Stashok <oleksiy.stashok_at_oracle.com>wrote:
> 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> 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
>>
>>
>>
>
>