lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (SOLR-9147) avoid expensive byte[] resize in EmbeddedSolrServer
Date Mon, 23 May 2016 15:19:12 GMT


Uwe Schindler commented on SOLR-9147:

What ailure do you mean? There are 2 probs here:
- fobiddenapis is used to find calls to "broken functions" in the JDK and also commons-io
(like Readers without Charset,...). Lucene and Solr also have a list of other signatures that
are disallowed (like creating Threads without a name, using log4j instead of slf4j,...). The
problem with the update of commons-io was, that there is currently no signature list for the
2.5 version of commons-io bundled with the checking tool. So instead of disabling, I re-added
the signatures of the 2.4 version, which should be fine for now. I opened an issue to add
support for commons-io-2.5:
- The Jar Checksum failure on Jenkins is comming from the following: Jenkins uses the "jar-checksums"
task and recalculates all checksums and this task also writes them to disk. In the final check
of Jenkins (after running all tests, recalculating checksums,...) the Git checkout is checked
for modifications. If the checksums aren't correct, this fails. This is what happened. The
problem was that you created the checksum files by hand, not with the ant task, so there was
just the newline difference.

> avoid expensive byte[] resize in EmbeddedSolrServer
> ---------------------------------------------------
>                 Key: SOLR-9147
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: Server
>            Reporter: Mikhail Khludnev
>            Assignee: Mikhail Khludnev
>             Fix For: 6.1, master (7.0)
>         Attachments: SOLR-9147.patch, SOLR-9147.patch
> This issue makes modest step toward EmbeddedSolrServer efficiency.
> It replaces {{}} which has quite expensive resizes with
incrementally growing BAOS from commons-io 2.5.  
> h4. Note
> There is no expectation for performance gain in case of StreamingResponseCallback.  

This message was sent by Atlassian JIRA

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

View raw message