users@grizzly.java.net

Re: Should I use Context to store the clients references ?

From: Survivant 00 <survivant00_at_gmail.com>
Date: Wed, 16 Jul 2008 15:14:31 -0400

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.


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.

but I suppose it's only when we create a new buffer (like double size)
right ?

WorkerThread workerThread = (WorkerThread) Thread.currentThread();
                        workerThread.setByteBuffer(processingBuffer);



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
>>
>>
>>
>>
>
>