[ https://issues.apache.org/jira/browse/HBASE-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709140#comment-15709140 ]
ramkrishna.s.vasudevan commented on HBASE-16859: ------------------------------------------------ {code} /** Create a new CodedInputStream wrapping the given {@link ByteInput}. */ public static CodedInputStream newInstance(ByteInput buf, boolean bufferIsImmutable) { return new ByteInputDecoder(buf, bufferIsImmutable); } public static CodedInputStream newInstance(ByteInput buf, int off, int len, boolean bufferIsImmutable) { return new ByteInputDecoder(buf, off, len, bufferIsImmutable); } {code} These are added by us. So I think then CodedOutputStream#newInstance making it public also we should push when we push this CIS related changes I believe. > 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 > > > 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 (v6.3.4#6332)