when a message receive,we read it from a socket channel,but if we think all
data isn't read completely, we return false ,and we will regist a read event
in socket selector, we will read from the socketchannel use the buffer in
old workthread.
in my ProtocolParser I will not clear the buffer before read all data
completely,so when buffer's postion equals buffer's limit, read from channel
will return size 0.
if I save data in my context and clear the buffer, return false after clear
buffer,it will correct?
Harsha Godugu wrote:
>
> windshome wrote:
>
>>Oh,I think you are not understand me, my problem is when the bytebuffer is
>>full,but all my data hasn't read
>>complete(my data size is 2MB), how can i read all data?
>>
> Hi: Please note that the bytebuffer size that is used for i/o here, in
> Grizzly, will have a constant threshold. That means, say, if the
> application can send /receive data (on both server/client side), the
> size of such a buffer during the process could vary from zero to the
> threshold. This threshold has got a limit. It can be 8K, 16K or 256k to
> the max... based on the system limits and application needs. It can not
> be 8Mb or some gig.. The idea is, the bytebuffer that we use in
> grizzly (for i/o) is really a BUFFER, meaning a temporary place to read
> /write to/from a channel. That means, the underlying application needs
> to store the flushed bits somewhere else. So, as soon as you read say
> 8K bytes and then if expect more to read, we need store the read bytes
> somewhere else (in some other object/file/shared memory..etc) and then
> wait to read the rest of the data until your protocol handler tells you
> that there are no next messages to parse!
>
> hths
> -Harsha
>
>>Jeanfrancois Arcand-2 wrote:
>>
>>
>>>Salut,
>>>
>>>windshome wrote:
>>>
>>>
>>>>I process the data to make a digital signature, and return signed data
to
>>>>client.
>>>>
>>>>
>>>Interesting :-) The number of ByteBuffer created is equal to the number
>>>of active Threads by default in Grizzly. Right now our default thread
>>>pool doesn't purge inactive threads, so it may or may not be a problem
>>>if you need a lot of threads. You might want to replace the default
>>>thread pool with a one from java.util.concurrent.* that can purge
>>>inactive thread and their associated byte buffer.
>>>
>>>Are you able to determine the size of your expected traffic? If your VM
>>>is properly tuned (I will let Charlie gives some hints in case you are
>>>interested) it shouldn't be a problem, assuming you don't need 1000
>>>threads :-)
>>>
>>>A+
>>>
>>>-- Jeanfrancois
>>>
>>>
>>>
>>>
>>>>Jeanfrancois Arcand-2 wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>sorry for the delay...
>>>>>
>>>>>windshome wrote:
>>>>>
>>>>>
>>>>>>I write a server base grizzly,I write a client which send data to
>>>>>>server
>>>>>>and
>>>>>>receive response from server. I send 50 bytes data and 2k data to
>>>>>>server
>>>>>>ok,but when I send 20K and 2MB data,server no response.
>>>>>>I view the code of grizzly,find the ByteBuffer of a workthread capity
>>>>>>is
>>>>>>8192,then I modify it to 81920,then 20k data can receive by server.
>>>>>>
>>>>>>If my Server set the init size of ByteBuffer is 81920,I think it would
>>>>>>use
>>>>>>to much memory,who can tell me some method,will dynamic just the
>>>>>>buffer,can
>>>>>>receive some bytes data ,or some MB data?
>>>>>>
>>>>>>
>>>>>What are you doing with the bytes? Are you saving the bytes somewhere
on
>>>>>disk/db (freeing your memory) or you must keep them in memory?
>>>>>
>>>>>Thanks
>>>>>
>>>>>-- Jeanfrancois
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>My Server's protocol parser code :
>>>>>>
>>>>>>
>>>>>> final ProtocolFilter parserProtocolFilter = new
>>>>>>ParserProtocolFilter() {
>>>>>> public ProtocolParser newProtocolParser() {
>>>>>> return new ProtocolParser() {
>>>>>> private boolean isExpectingMoreData = false;
>>>>>> private ByteBuffer byteBuffer;
>>>>>> private Request message;
>>>>>>
>>>>>> public boolean hasMoreBytesToParse() {
>>>>>> return false;
>>>>>> }
>>>>>>
>>>>>> public boolean isExpectingMoreData() {
>>>>>> return isExpectingMoreData;
>>>>>> }
>>>>>>
>>>>>> public Object getNextMessage() {
>>>>>> return message;
>>>>>> }
>>>>>>
>>>>>> public boolean hasNextMessage() {
>>>>>>
>>>>>>
>>>>>> ByteBuffer dup = byteBuffer.duplicate();
>>>>>> System.out.println( "byteBuffer.position2()="
>>>>>> +
>>>>>>byteBuffer.position() );
>>>>>> if (byteBuffer.position() == 0){
>>>>>> System.out.println("byteBuffer.position()
>>>>>>==
>>>>>>0");
>>>>>> isExpectingMoreData = true;
>>>>>> return false;
>>>>>> }
>>>>>> dup.flip();
>>>>>>
>>>>>>
>>>>>> if( dup.remaining()< 4 ){
>>>>>> isExpectingMoreData = true;
>>>>>> return false;
>>>>>> }
>>>>>>
>>>>>> byte[] bs = new byte[4];
>>>>>> dup.get(bs);
>>>>>> int len= (bs[0] << 24) + (bs[1] << 16) +
>>>>>> (bs[2]
>>>>>><<
>>>>>>8) + (bs[3] << 0);
>>>>>>
>>>>>> if( dup.remaining() < len ){
>>>>>> isExpectingMoreData = true;
>>>>>> return false;
>>>>>> }
>>>>>> byte[] data = new byte[len];
>>>>>> dup.get( data );
>>>>>>
>>>>>> try {
>>>>>> message = new ByteRequest(data);
>>>>>> } catch (Exception e) {
>>>>>> e.printStackTrace();
>>>>>> message=null;
>>>>>> return false;
>>>>>> }
>>>>>> return true;
>>>>>>
>>>>>> }
>>>>>>
>>>>>> public void startBuffer(ByteBuffer bb) {
>>>>>> byteBuffer = bb;
>>>>>> }
>>>>>>
>>>>>> public boolean releaseBuffer() {
>>>>>> byteBuffer = null;
>>>>>> message = null;
>>>>>> return false;
>>>>>> }
>>>>>>
>>>>>> };
>>>>>> }
>>>>>> };
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/who-can-help-me-how-a-server-base-grizzly-receive-2MB-data-from-client-tp15174927p15198655.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.