The client code was included in the original post, as well as attached as a
zip file in my last update. The client class is called ClientSampleMain. It
just creates a large String message and sends it via TCP.
As to your points below:
1) I looked at the javadoc again, and its actually: get(byte[] dst, int
offset, int length) so I did have it incorrect. I have updated my example
and re-attached the zip file. This is not the issue, though its wrong
anyway. I did it like this to verify that the correct bytes from the buffer
are copied.
2) Thats one of my problems, if I set it to false, the parser never gets
re-invoked, even though i tell it i need more bytes. The only way I can get
it to re-invoked is to set it to true. I showed why in the included code
from the framework.
Oleksiy Stashok wrote:
>
> Hi,
>
> can I ask you to provide specifically the client code, which
> reproduces the issue?
> Just several notes:
>
> 1) buffer.get(bytes, startIndex, endIndex);
> not sure this is correct.
> Here startIndex and endIndex are values for bytes[] array, not buffer.
>
> 2) // If hasMoreBytesToParse is false, we do not get re-invoked!!!
> //hasMoreBytesToParse = false;
> hasMoreBytesToParse = true;
> isExpectingMoreData = true;
>
> hasMoreBytesToParse should be false there.
> "hasMoreBytesToParser" means "I have *parsed* a message, but there is
> still some data remaining", so when there is no completed message -
> this value should be false.
>
> But I'll try to help more, once you'll provide me the client code,
> which will reproduce the issue.
>
> Thanks.,
>
> WBR,
> Alexey.
>
> On May 7, 2009, at 1:32 , Parker Lord wrote:
>
>>
>> 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.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> 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/p23430837/Sample.zip Sample.zip
--
View this message in context: http://www.nabble.com/ProtocolParser-Issue-with-Reallocation-of-ByteBuffer-tp23416360p23430837.html
Sent from the Grizzly - Development mailing list archive at Nabble.com.