>
Simon,
I found something a bit odd but that might be because you've edited
the code before posting it.
In the hasNextMessage() method there's this snippet of code:
86 }
87 /*
88 * Validates that the buffer contains at least 2 bytes
so we can proceed to input validation
89 */
90 if(bufferContent.length < 2)
91 {
92 isExpectingMoreData = true;
93 return !isExpectingMoreData;
94
95 // 1.1)
96 if(CR == bufferContent[0])
97 {
98 if(LF == bufferContent[1])
99 {
100 // 1.1.1)
101 if(bufferContentString.contains(PASS.toString()))
102 {
103 if(LOG.isTraceEnabled())
104 {
105 LOG.trace("Found: PASS");
106 }
107 isExpectingMoreData = false;
108 message = PASS.toString();
109 position = PASS.toBytes().length;
110 }
Note on line 93 the return without any closing curly bracket.
However, this shouldn't compile
as the code below is unreachable. Am I correct in assuming that there
should be
a closing bracket on line 94?
(the indention is a bit off due to being cut'n'pasted into my mail
client).
cheers
Erik
> Thanks!
>
> Simon
>
> -----Original Message-----
> From: Erik Svensson [mailto:erik_at_phlogiston.se]
> Sent: March-07-08 1:35 PM
> To: users_at_grizzly.dev.java.net
> Subject: Re: [Q] Testing ProtocolFilter
>
>
> On Mar 7, 2008, at 17:03 , Simon Trudeau wrote:
>
>> Have you filled up a ticket about the compacting issue?
>
> That I haven't.
>
>> Have you posted the code for your protocol parser? Here's mine, maybe
>> you can give me some tips! :.)
>
> I haven't done that either. We're looking at using grizzly inhouse
> and it was in that context I wrote
> the protocol parser. I had thoughts about writing a tutorial/blog
> post about it but there aren't all that much time right now.
> At work I have more pressing concerns. I
>
> I attach my protocol parser to this mail so you can look at it. It's
> not tested with 1.7.2, though.
>
> Basically it uses a class XFlowMessage that contains the parser to
> parse the byte buffer into xflow messages.
>
>> I will add your buffer compacting tip!
>
> I'll look at your code and see if I can come up with something. Just
> the thing the wife wants me to do on a friday evening :-)
>
> cheers
>
> /Erik
>
>
>
>>
>> Simon
>>
>> -----Original Message-----
>> From: Erik Svensson [mailto:erik.svensson_at_six.se]
>> Sent: March-07-08 10:56 AM
>> To: users_at_grizzly.dev.java.net
>> Subject: Re: [Q] Testing ProtocolFilter
>>
>> On 3/7/08 4:40 PM, "Simon Trudeau" <strudeau_at_bluetreewireless.com>
>> wrote:
>>
>>> I would like to know, how can I test my protocol filter. I would
>>> like
>> to
>>> simulate, using unit tests, a truncated message.
>>>
>>>
>>>
>>> I try invoking the connectorHandler's send() method twice (part1 and
>>> part2 of my message) with a Thread.sleep in between but the protocol
>>> parsers doesn't think tokens are missing, it sees the two different
>>> operations as two different message. Does this has something with
>> TCP/IP
>>> where the stack is configured to "know" the packet received has been
>>> truncated or do I need to investigate my ProtocolFilter further. How
>>> should I test this?
>>>
>>>
>>>
>>> client.connect(new
>>> InetSocketAddress(InetAddress.getLocalHost(), serverPort));
>>>
>>> ByteBuffer outputByteBuffer1 = ByteBuffer.wrap(new
>>> String("\r\nPA").getBytes());
>>>
>>> ByteBuffer outputByteBuffer2 = ByteBuffer.wrap(new
>>> String("SS\r\n\0").getBytes());
>>>
>>> client.send(outputByteBuffer1);
>>>
>>> Thread.sleep(25);
>>>
>>> client.send(outputByteBuffer2);
>>>
>>
>> I haven't looked at your previously posted code but I've written a
>> ProtocolParser. tcp knows nothing about messages nor does it know
>> anything
>> about the semantics of your message.
>> Your ProtocolParser needs to be able to determine if it has
>> received a
>> complete message and then return true when the 'I need more data'-
>> method
>> is
>> called.
>>
>> I also found that I had to do a compact() on my incoming bytebuffer
>> when
>> the
>> ReleaseBuffer() is called.
>> Otherwise, if you can't read a complete message the bytebuffer will
>> just
>> fill up until there's no more space and you don't get any more
>> messages.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>> <MyProtocolParser.java>----------------------------------------------
>> -
>
>> ----------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>