Hi,
On Jul 16, 2008, at 21:14 , Survivant 00 wrote:
> just one more question.
>
> suppose this case.
>
> a client go rampage.. it send invalid data for X reason..
>
> with the actual code, when the capacity is reach, it will create a
> new buffer (2x size), but I want to aloid a max size.. like 20 000.
> the default is 8192(somthing like that) I did a system,out of
> processingbuffer.capacity
>
> what is the clean way to exit the parsing loop and return a state or
> exception to the next filter ? The next filter should be able to
> detect this error and close the client connection.
It could be done by returning true from hasNextMessage().
And parser's getNextMessage() method implementation should return some
Error message, so your next filter will get it and be able to parse.
> and just for my information.
>
> I tought the the buffer could be flush between the loop in the
> filter. That's why I put the remaining data in the buffer into the
> WorkerThread.
With ParserProtocolFilter you don't need to care about ByteBuffer...
Once isExpectingMoreData() returns true - filter will save the
ByteBuffer and reuse it only with current connection next time.
> but I suppose it's only when we create a new buffer (like double
> size) right ?
>
> WorkerThread workerThread = (WorkerThread) Thread.currentThread();
> workerThread.setByteBuffer(processingBuffer);
startBuffer() method is called first, where we associate current
Thread's ByteBuffer with parser's processingBuffer...
So we need this:
> WorkerThread workerThread = (WorkerThread) Thread.currentThread();
> workerThread.setByteBuffer(processingBuffer);
only, when we create new ByteBuffer.
Thanks.
WBR,
Alexey.
>
>
>
>
> 2008/7/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:
> Ok, once it works, I can describe the changes.
>
> + First of all I don't use internal buffer in the parser to store
> temporary data there.
> + Fixed parser logic... I know we don't have good tutorial on that
> yet, so your blog could help
> hasMoreBytesToParse: should return true only if one message
> was parsed successfully, but there is still some remaining data in
> the buffer.
> releaseBuffer(): should compact the buffer, not clear... as
> possibly there is some remaining. Buffer should become ready for
> next read operation (unflipped).
>
>
>>
>> do you have a good link or documentation about the code behind the
>> ByteBufferFactory ?
> ByteBufferFactory is Factory class for creating ByteBuffers. It's
> actually wrapper on top of ByteBuffer.allocate(...)/
> allocateDirect()...
> But it also implements ByteBuffer views functionality. It means
> ByteBufferFactory preallocates very big ByteBuffer(4M) and then,
> when ByteBufferFactory.allocateView(...) is called - it basically
> doesn't allocate new buffer, but just cuts the chunk of big
> preallocated buffer and returns this chunk.
>
> Seems that's it.
>
> Thanks.
>
> WBR,
> Alexey.
>
>> I want to know what it's done under the hood, suppose that I want
>> to do it in a project that doesn't use grizzly.. could be usefull
>> to understand that.
>>
>> and thanks again for your help.
>>
>> now I'm almost ready to blog all about this.
>>
>>
>> 2008/7/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:
>> Pls. try attached version.
>>
>> WBR,
>> Alexey.
>>
>>
>>
>> On Jul 16, 2008, at 15:45 , Survivant 00 wrote:
>>
>>> I got a exception when I send the second request
>>>
>>> it's really simple to reproduce
>>>
>>> start the main class
>>>
>>> GrizzlyGateway
>>>
>>> it will listen on the port 5000
>>>
>>>
>>> open a telnet localhost 5000
>>>
>>> in the console.. send theses 2 requests.. One by one
>>>
>>> feed|aaa[eoq]
>>> feed|bbb[eoq]
>>>
>>>
>>> you will see that in the server console
>>>
>>>
>>> GrizzlyGateway started
>>> Simulate a disconnection from the 3th party
>>> Reconnecting...
>>> listening for incomming TCP Connections on port : 5000
>>> query = feed|aaa
>>> SENDING FEED TO CLIENT = [SYMBOL=[aaa] BID = 31.46111239671892|
>>> ASK = 41.85483961272104]
>>> SENDING FEED TO CLIENT = [SYMBOL=[aaa] BID = 19.410604221055426|
>>> ASK = 40.98782811588009]
>>> 2008-07-16 09:41:07 com.sun.grizzly.DefaultProtocolChain
>>> executeProtocolFilter
>>> GRAVE: ProtocolChain exception
>>> java.lang.IllegalStateException: ByteBuffer is full:
>>> java.nio.HeapByteBuffer[pos=0 lim=0 cap=8192]
>>> at com.sun.grizzly.filter.ReadFilter.execute(ReadFilter.java:
>>> 120)
>>> at com.sun.grizzly.filter.ReadFilter.execute(ReadFilter.java:95)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .filter.ParserProtocolFilter.execute(ParserProtocolFilter.java:108)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .DefaultProtocolChain
>>> .executeProtocolFilter(DefaultProtocolChain.java:137)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>>> at
>>> com
>>> .sun
>>> .grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>>> at
>>> com
>>> .sun
>>> .grizzly
>>> .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
>>> at
>>> com
>>> .sun
>>> .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:
>>> 56)
>>> at
>>> com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
>>> SENDING FEED TO CLIENT = [SYMBOL=[aaa] BID = 10.932414591862527|
>>> ASK = 25.136572649558214]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2008/7/16 Oleksiy Stashok <Oleksiy.Stashok_at_sun.com>:
>>> Hi,
>>>
>>> I made some changes to the parser code - please try it.
>>> The idea is to not use internal bytebuffer in the parser, but
>>> reuse one from WorkerThread...
>>> Let me know if it works, if not - please provide some unit test,
>>> using which I can test the parser myself.
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>
>>> <
>>> nio_quotestock_demo_v3
>>> .zip
>>> >
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>>
>
>