ramkrishna.s.vasudevan commented on HBASE-16859:

bq.Then also once can make an IS around that and use but the extra byte[] and 
in btw copy to there will happen.
I saw that impl. It uses both buffer and inputstream. So if nothing is there in 
buffer it copies from the IS to the buffer and then reads from buffer only.
So in our case also for every request the copy would happen for 4KB but ideally 
among that 4KB (default size) we don need that much. We only need the header 
and param size len to be copied. 
And anyway after that there is no other copy because we work on ByteBuff 
Have you tried to test the performance of write by creating 
cis = CodedInputStream.newInstance(new ByteBuffInputStream(buf));
cis = CodedInputStream.newInstance(new ByteBuffByteInput(buf, 0, buf.limit()), 
I think the per instance byte[] will add to the gc for sure. But other than 
than should be more or less ok. I can test it. I am just saying this because in 
case PB does not accept this contribution then I think we can solve it. Just 

> Use Bytebuffer pool for non java clients specifically for scans/gets
> --------------------------------------------------------------------
>                 Key: HBASE-16859
>                 URL: https://issues.apache.org/jira/browse/HBASE-16859
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 2.0.0
>         Attachments: HBASE-16859_V1.patch, HBASE-16859_V2.patch, 
> HBASE-16859_V2.patch
> In case of non java clients we still write the results and header into a on 
> demand  byte[]. This can be changed to use the BBPool (onheap or offheap 
> buffer?).
> But the basic problem is to identify if the response is for scans/gets. 
> - One easy way to do it is use the MethodDescriptor per Call and use the   
> name of the MethodDescriptor to identify it is a scan/get. But this will 
> pollute RpcServer by checking for scan/get type response.
> - Other way is always set the result to cellScanner but we know that 
> isClientCellBlockSupported is going to false for non PB clients. So ignore 
> the cellscanner and go ahead with the results in PB. But this is not clean
> - third one is that we already have a RpccallContext being passed to the RS. 
> In case of scan/gets/multiGets we already set a Rpccallback for shipped call. 
> So here on response we can check if the callback is not null and check for 
> isclientBlockSupported. In this case we can get the BB from the pool and 
> write the result and header to that BB. May be this looks clean?

This message was sent by Atlassian JIRA

Reply via email to