Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 23 May 2016 15:19:12 +0000 (UTC)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12971903.1463948100000.266686.1464016752902@Atlassian.JIRA>
In-Reply-To: <JIRA.12971903.1463948100000@Atlassian.JIRA>
References: <JIRA.12971903.1463948100000@Atlassian.JIRA> <JIRA.12971903.1463948100531@arcas>
Subject: [jira] [Comment Edited] (SOLR-9147) avoid expensive byte[] resize
 in EmbeddedSolrServer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 23 May 2016 15:19:15 -0000


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

Uwe Schindler edited comment on SOLR-9147 at 5/23/16 3:18 PM:
--------------------------------------------------------------

What failure 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.


was (Author: thetaphi):
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org