lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <>
Subject [jira] [Commented] (SOLR-4224) refactor JavaBinCodec input stream definition to enhance reuse
Date Mon, 10 Jun 2013 14:32:20 GMT


Noble Paul commented on SOLR-4224:

Is this not fixed in trunk?
> refactor JavaBinCodec input stream definition to enhance reuse
> --------------------------------------------------------------
>                 Key: SOLR-4224
>                 URL:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message