[
https://issues.apache.org/jira/browse/SOLR-9147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296504#comment-15296504
]
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:
https://github.com/policeman-tools/forbidden-apis/issues/102
- 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: https://issues.apache.org/jira/browse/SOLR-9147
> 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 {{java.io.ByteArrayOutputStream}} 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
