dev@grizzly.java.net

Re: ProtocolParser Issue with Reallocation of ByteBuffer

From: Parker Lord <plord_at_seecontrol.com>
Date: Wed, 6 May 2009 16:32:18 -0700 (PDT)

Added the zip file with the sample code.



Jeanfrancois Arcand-2 wrote:
>
> Salut,
>
> Parker Lord wrote:
>> The full set of files for my test case is included in the post.
>>
>> The last file is the client to invloke the server. The first set of files
>> make up the server.
>> Let me know if you need me to sip them up and attach them.
>
> My bad I've missed the client. But if you can ZIp that will be perfect.
>
> Thanks!
>
> -- Jeanfrancois
>
>>
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> Parker Lord wrote:
>>>> I have been struggling with an issue for a few days now and am at a
>>>> loss
>>>> as to what is wrong. I am trying to build a ProtocolParser to parse XML
>>>> messages which could be larger than 8K. I have read all the relevant
>>>> postings on the forum here and have tried two different approaches,
>>>> both
>>>> of which exhibit the same behavior. I upgrade to 1.9.15 today as well,
>>>> and still no resolution. My issue is that everything works when I run
>>>> in
>>>> the debugger and have a breakpoint set in the code. If I disable
>>>> breakpoints, I get this error:
>>>>
>>>> May 6, 2009 2:39:29 PM atlantes.connector.test.SampleProtocolParser
>>>> hasNextMessage
>>>> INFO: GrizzlyWorker-3 before expand: buffer
>>>> java.nio.HeapByteBuffer[pos=0
>>>> lim=8192 cap=8192] isExpectingMoreData false hasMoreBytesToParse false
>>>> May 6, 2009 2:39:29 PM atlantes.connector.test.SampleProtocolParser
>>>> hasNextMessage
>>>> INFO: GrizzlyWorker-3 after expand: buffer
>>>> java.nio.HeapByteBuffer[pos=8192 lim=16384 cap=16384]
>>>> isExpectingMoreData
>>>> true hasMoreBytesToParse true
>>>> May 6, 2009 2:39:29 PM com.sun.grizzly.DefaultProtocolChain
>>>> executeProtocolFilter
>>>> SEVERE: ProtocolChain exception
>>>> java.lang.IllegalStateException: ByteBuffer is full:
>>>> java.nio.HeapByteBuffer[pos=0 lim=0 cap=16384]
>>>> at com.sun.grizzly.filter.ReadFilter.execute(ReadFilter.java:143)
>>>> at com.sun.grizzly.filter.ReadFilter.execute(ReadFilter.java:103)
>>>> at
>>>> com.sun.grizzly.filter.ParserProtocolFilter.superExecute(ParserProtocolFilter.java:207)
>>>> at
>>>> com.sun.grizzly.filter.ParserProtocolFilter.execute(ParserProtocolFilter.java:131)
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:136)
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:103)
>>>> at
>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:89)
>>>> at
>>>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
>>>> at
>>>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
>>>> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
>>>> at
>>>> com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:335)
>>>> at
>>>> com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:320)
>>>> at java.lang.Thread.run(Thread.java:595)
>>>>
>>>>
>>>> When I have a breakpoint set (or in a few cases when it works), the
>>>> output looks like this:
>>>>
>>>> May 6, 2009 2:38:41 PM atlantes.connector.test.SampleProtocolParser
>>>> hasNextMessage
>>>> INFO: GrizzlyWorker-2 before expand: buffer
>>>> java.nio.HeapByteBuffer[pos=0
>>>> lim=8192 cap=8192] isExpectingMoreData false hasMoreBytesToParse false
>>>> May 6, 2009 2:38:41 PM atlantes.connector.test.SampleProtocolParser
>>>> hasNextMessage
>>>> INFO: GrizzlyWorker-2 after expand: buffer
>>>> java.nio.HeapByteBuffer[pos=8192 lim=16384 cap=16384]
>>>> isExpectingMoreData
>>>> true hasMoreBytesToParse true
>>>> May 6, 2009 2:38:42 PM atlantes.connector.test.SampleProtocolParser
>>>> extractMessage
>>>> INFO: GrizzlyWorker-2 before extract: buffer
>>>> java.nio.HeapByteBuffer[pos=0 lim=10265 cap=16384] isExpectingMoreData
>>>> true hasMoreBytesToParse true
>>>> May 6, 2009 2:38:42 PM atlantes.connector.test.SampleProtocolParser
>>>> extractMessage
>>>> INFO: GrizzlyWorker-2 after extract: buffer
>>>> java.nio.HeapByteBuffer[pos=10265 lim=10265 cap=16384]
>>>> isExpectingMoreData true hasMoreBytesToParse true
>>>>
>>>> It seems that when the call to hasNextMessage() returns with a larger
>>>> buffer having been set in the currentThread, when it next retrieves it
>>>> from the thread and checks it, it seems to now have become full!!!!!
>>>> Some sort of race condition or thread switching issue is going on, but
>>>> I
>>>> cant test since by debugging the code, it works.
>>> Can you share a test case?
>>>
>>>
>>> Another problem I
>>>> noticed and I am not sure if it is related. In the examples I have seen
>>>> here, when the buffer is reallocated, hasMoreBytesToParse is set to
>>>> false. If I set this to false, hasNextMessage does not get called back.
>>>> You can see this clearly in ParserProtocolFilter postExecute() method:
>>>>
>>>> public boolean postExecute(Context context) throws IOException {
>>>> ProtocolParser parser = (ProtocolParser)
>>>> context.getAttribute(ProtocolParser.PARSER);
>>>>
>>>> if (parser == null) {
>>>> return true;
>>>> }
>>>>
>>>> if (parser.hasMoreBytesToParse()) {
>>>> // Need to say that we read successfully since bytes are
>>>> left
>>>>
>>>> context.setAttribute(ProtocolChain.PROTOCOL_CHAIN_POST_INSTRUCTION,
>>>> ProtocolChainInstruction.REINVOKE);
>>>> return true;
>>>> }
>>>>
>>>> and then in DefaultProtocolChain postExecuteProtocolFilter() :
>>>>
>>>> ProtocolChainInstruction postInstruction =
>>>> (ProtocolChainInstruction) ctx.removeAttribute(
>>>> PROTOCOL_CHAIN_POST_INSTRUCTION);
>>>>
>>>> if (postInstruction != null &&
>>>> postInstruction == ProtocolChainInstruction.REINVOKE) {
>>>> reinvokeChain = true;
>>>> } else if (continousExecution
>>>> && currentPosition == protocolFilters.size() -1
>>>> &&
>>>> (Boolean)ctx.removeAttribute(ProtocolFilter.SUCCESSFUL_READ)
>>>> == Boolean.TRUE) {
>>>> reinvokeChain = true;
>>>> }
>>>>
>>>> return reinvokeChain;
>>>>
>>>>
>>>> The only chance to get reinvoked is to have hasMoreBytesToParse be set
>>>> to true, not false. Any help would be appreciated. Here is all the
>>>> source code:
>>> Great I will take a look. How do you stress the server?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>
>
> Sample code now attached
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
http://www.nabble.com/file/p23417557/Sample.zip Sample.zip
-- 
View this message in context: http://www.nabble.com/ProtocolParser-Issue-with-Reallocation-of-ByteBuffer-tp23416360p23417557.html
Sent from the Grizzly - Development mailing list archive at Nabble.com.