[ 
https://issues.apache.org/jira/browse/SOLR-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13679534#comment-13679534
 ] 

Noble Paul commented on SOLR-4224:
----------------------------------

Is this not fixed in trunk?
                
> refactor JavaBinCodec input stream definition to enhance reuse
> --------------------------------------------------------------
>
>                 Key: SOLR-4224
>                 URL: https://issues.apache.org/jira/browse/SOLR-4224
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>            Reporter: Patrick Hunt
>            Assignee: Mark Miller
>            Priority: Minor
>             Fix For: 5.0, 4.4
>
>         Attachments: SOLR-4224.patch
>
>
> JavaBinCodec currently requires use of the concrete "FastInputStream" when 
> unmarshalling a record. A JavaBinCodec API that takes an interface or 
> abstract implementation would allow greater reuse.
> In my particular case I am trying to use JavaBinCodec to marshal/unmarshal 
> from an data source that doesn't allow buffering. The semantics are such that 
> I can read only a single record from the input source. The buffering in 
> FastInputStream is reading information contained in the second record. No 
> state other than the input data source itself is available to "cache" the 
> FastInputStream between calls. As a result I'm losing the second record. I 
> would like to provide an InputStream/DataInput that doesn't do any buffering.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to