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