Hi,
>
> 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.
Ok.
>
>
> 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.
hasMoreBytesToParse should be really false.
The issue you see should be fixed on trunk.
Can you pls. try it out?
Thanks.
WBR,
Alexey.
>
>
>
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>