[jira] [Updated] (SOLR-3139) StreamingUpdateSolrServer doesn't send UpdateRequest.getParams()
[ https://issues.apache.org/jira/browse/SOLR-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3139: - Attachment: SOLR-3139.patch Make params handling similar to what is done in HttpSolrServer. I am planning to commit this shortly. > StreamingUpdateSolrServer doesn't send UpdateRequest.getParams() > > > Key: SOLR-3139 > URL: https://issues.apache.org/jira/browse/SOLR-3139 > Project: Solr > Issue Type: Bug > Components: clients - java >Reporter: Andrzej Bialecki > Fix For: 4.0 > > Attachments: SOLR-3139.patch > > > CommonsHttpSolrServer properly encodes the request's SolrParams depending on > GET or POST. However, StreamingUpdateSolrServer only looks at the params to > determine whether they contain optimize/commit ops, and otherwise discards > them. > This is unexpected - it should properly encode and send SolrParams per > request, in a similar way as CommonsHttpSolrServer does. Currently this bug > prevents one from e.g. selecting a different update chain per request when > using the streaming server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2990) solr OOM issues
[ https://issues.apache.org/jira/browse/SOLR-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2990: - Component/s: (was: clients - java) contrib - Solr Cell (Tika extraction) > solr OOM issues > --- > > Key: SOLR-2990 > URL: https://issues.apache.org/jira/browse/SOLR-2990 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.0 > Environment: CentOS 5.x/6.x > Solr Build apache-solr-4.0-2011-11-04_09-29-42 (includes tika 1.0) > java -server -Xms2G -Xmx2G -XX:+HeapDumpOnOutOfMemoryError > -XX:HeapDumpPath=/var/log/oom/solr.dump.1 -Dsolr.data.dir=/opt/solr.data > -Djava.util.logging.config.file=solr-logging.properties -DSTOP.PORT=8907 > -DSTOP.KEY=STOP -jar start.jar >Reporter: Rob Tulloh > > We see intermittent issues with OutOfMemory caused by tika failing to process > content. Here is an example: > Dec 29, 2011 7:12:05 AM org.apache.solr.common.SolrException log > SEVERE: java.lang.OutOfMemoryError: Java heap space > at > org.apache.poi.hmef.attribute.TNEFAttribute.(TNEFAttribute.java:50) > at > org.apache.poi.hmef.attribute.TNEFAttribute.create(TNEFAttribute.java:76) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:74) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.(HMEFMessage.java:63) > at > org.apache.tika.parser.microsoft.TNEFParser.parse(TNEFParser.java:79) > at > org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:242) > at > org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:242) > at > org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:129) > at > org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:195) > at > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at > org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:244) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1478) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2483) DIH - an uppercase problem in query parameters
[
https://issues.apache.org/jira/browse/SOLR-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-2483:
-
Component/s: (was: clients - java)
> DIH - an uppercase problem in query parameters
> --
>
> Key: SOLR-2483
> URL: https://issues.apache.org/jira/browse/SOLR-2483
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.1
> Environment: Windows Vista
> Java 1.6
>Reporter: Lubo Torok
> Labels: DataImportHandler, entity, newdev, parameter, sql
>
> I have two tables called "PROBLEM" and "KOMENTAR"(means 'comment' in English)
> in DB. One problem can have more comments. I want to index them all.
> schema.xml looks as follows
> ... some fields ...
>
> ... some fields...
> data-config.xml:
>
> pk="problem_id">
>
>
>
> If you write '${problem.PROBLEM_ID}' in lower case, i.e.
> '${problem.problem_id}' SOLR will not import the inner entity. Seems strange
> to me and it took me some time to figure this out.
> Note that primary key in "PROBLEM" is called "ID". I defined the alias
> "problem_id" (yes,lower case) in SQL. In schema, there is this field defined
> as "problem_id" again in lower case. But, when I run
> http://localhost:8983/solr/dataimport?command=full-import&debug=true&verbose=on
> so I can see some debug information there is this part
> ...
>
> −
>
> −
>
> −
>
> select to_char(id) as problem_id, nazov as problem_nazov, cislo as
> problem_cislo, popis as problem_popis from problem
>
> 0:0:0.465
> --- row #1-
> test zodpovedneho
> 2533274790395945
> 201009304
> csfdewafedewfw
> -
> −
>
> −
>
> select id as komentar_id, nazov as komentar_nazov, text as komentar_text from
> komentar where to_char(fk_problem)='2533274790395945'
>
> ...
> where you can see that, internally, the fields of "PROBLEM" are represented
> in uppercase despite the user (me) had not defined them this way. The result
> is I guess that parameter referring to the parent entity ${entity.field}
> should always be in uppercase, i.e. ${entity.FIELD}.
> Here is an example of the indexed entity as written after full-import command
> with debug and verbose on:
>
> −
>
> −
>
> test zodpovedneho
>
> −
>
> 2533274790395945
>
> −
>
> 201009304
>
> −
>
> csfdewafedewfw
>
> −
>
> java.math.BigDecimal:5066549580791985
>
> −
>
> a.TXT
>
>
> here are the field names in lower case. I consider this as a bug. Maybe I am
> wrong and its a feature. I work with SOLR only for few days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1888) Annotated beans source generation with maven plugin
[
https://issues.apache.org/jira/browse/SOLR-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-1888:
-
Component/s: (was: clients - java)
> Annotated beans source generation with maven plugin
> ---
>
> Key: SOLR-1888
> URL: https://issues.apache.org/jira/browse/SOLR-1888
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.5
> Environment: java, maven
>Reporter: Matthias Epheser
> Fix For: 4.0
>
> Attachments: maven-solr-plugin.zip
>
>
> As I stumbled over a lot of copy pasting while creating java annotated beans
> representing a schema.xml, i decided to make a shortcut and create a maven
> plugin.
> Think about it as source generation similar to castor/jaxb code generation
> from an xsd. You just point to a schema.xml and connect to the
> generate-sources phase. This leads to a java bean in
> target/generated-sources/solr that contains all fields from the schema well
> annotated.
> The mapping reads the section and maps field="string" to
> solr.StringField to java.lang String etc. Multivalured fields generate lists,
> dynamic fields Maps. Currently the code generation is plain simple, just a
> fileWriter with some intends. The getValidJavaName(String name) may act more
> professional than now.
> Just install the plugin contained in the zip using mvn install and connect it
> to an existing solrj project:
> {{
>
>org.apache.solr
>maven-solr-plugin
>
> test-data/solr/conf/schema.xml
> org.test.MyBean
>
>
>
> generate-sources
>
> generate
>
>
>
>
> }}
> The generated fiels will be automatically added to the classpath after the
> first run of mvn generate/compile. So just execute mvn eclipse:eclipse once
> after that. After every change in the schema, generate again and your bean
> will be updated and fields and getters and setters will be present.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1212) TestNG Test Case
[ https://issues.apache.org/jira/browse/SOLR-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1212: - Component/s: (was: clients - java) > TestNG Test Case > - > > Key: SOLR-1212 > URL: https://issues.apache.org/jira/browse/SOLR-1212 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Environment: Java 6 >Reporter: Karthik K > Fix For: 4.0 > > Attachments: SOLR-1212.patch, testng-5.9-jdk15.jar > > Original Estimate: 1h > Remaining Estimate: 1h > > TestNG equivalent of AbstractSolrTestCase , without using JUnit altogether . > New Class created: AbstractSolrNGTest > LICENSE.txt , NOTICE.txt modified as appropriate. ( TestNG under Apache > License 2.0 ) > TestNG 5.9-jdk15 added to lib. > Justification: In some workplaces - people are moving towards TestNG and > take out JUnit altogether from the classpath. Hence useful in those cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
dev@lucene.apache.org
[ https://issues.apache.org/jira/browse/SOLR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1196: - Component/s: (was: clients - java) > Incorrect matches when using non alphanumeric search string !@#$%\^\&\*\(\) > --- > > Key: SOLR-1196 > URL: https://issues.apache.org/jira/browse/SOLR-1196 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 > Environment: Solr 1.3/ Java 1.6/ Win XP/Eclipse 3.3 >Reporter: Sam Michael > > When matching strings that do not include alphanumeric chars, all the data is > returned as matches. (There is actually no match, so nothing should be > returned.) > When I run a query like - (activity_type:NAME) AND title:(\!@#$%\^&\*\(\)) > all the documents are returned even though there is not a single match. There > is no title that matches the string (which has been escaped). > My document structure is as follows > > NAME > Bathing > > > The title field is of type text_title which is described below. > positionIncrementGap="100"> > > > generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="1" > splitOnCaseChange="1"/> > > > > > > ignoreCase="true" expand="true"/> > generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="1" > splitOnCaseChange="1"/> > > > > > - > Yonik's analysis as follows. > -features:foo features:(\!@#$%\^&\*\(\)) > -features:foo features:(\!@#$%\^&\*\(\)) > -features:foo > -features:foo > The text analysis is throwing away non alphanumeric chars (probably > the WordDelimiterFilter). The Lucene (and Solr) query parser throws > away term queries when the token is zero length (after analysis). > Solr then interprets the left over "-features:foo" as "all documents > not containing foo in the features field", so you get a bunch of > matches. > As per his suggestion, a bug is filed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1976) Commit on StreamingUpdateSolrServer can happen before all previously added docs have been sent to Solr
[ https://issues.apache.org/jira/browse/SOLR-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1976: - Priority: Minor (was: Major) I tried to reproduce this with a testcase but so far after doing few thousand iterations of clean, add, commit, check result-size: no success Stephen: can you provide a testcase that show this error? > Commit on StreamingUpdateSolrServer can happen before all previously added > docs have been sent to Solr > -- > > Key: SOLR-1976 > URL: https://issues.apache.org/jira/browse/SOLR-1976 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.4.1 >Reporter: Stephen Duncan Jr >Priority: Minor > > Because of it's multi-threaded nature, calling commit on > StreamingUpdateSolrServer can send the commit before all the added documents > have been sent to Solr. Calling blockUntilFinished() does not change this. > It needs to be possible to send a commit that will commit all the documents > that have been added previously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2300) snapinstaller on slave is failing
[
https://issues.apache.org/jira/browse/SOLR-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-2300:
-
Component/s: (was: clients - java)
replication (scripts)
> This setup is giving issue only in linux. Is this known bug on linux?
I think the deletion problem is a combination of using nfs and solr (or some
other process) holding some file open.
I realize this issue is pretty old but have you tried with more recent version
of Solr, does the problem still exist?
> snapinstaller on slave is failing
> -
>
> Key: SOLR-2300
> URL: https://issues.apache.org/jira/browse/SOLR-2300
> Project: Solr
> Issue Type: Bug
> Components: replication (scripts)
>Affects Versions: 1.3
> Environment: Linux, Jboss 5.0GA, solr 1.3.0
>Reporter: sakunthala padmanabhuni
>
> Hi,
> We are using Solr on Mac OSX and it is working fine. Same setup we have
> moved to Linux. We have master, slave setup. Every 5 minutes, index will be
> replicated from Master to Slave and will be installed on slave. But on Linux
> on the slave when the snapinstaller script is called, it is failing and
> showing below error in logs.
> /bin/rm: cannot remove
> `/ngs/app/esearcht/Slave2index/data/index/.nfs000111030749':
> Device or resource busy
> This error is occuring in snapinstaller script at below lines.
> cp -lr ${name}/ ${data_dir}/index.tmp$$ && \
> /bin/rm -rf ${data_dir}/index && \
> mv -f ${data_dir}/index.tmp$$ ${data_dir}/index
> It is not able to remove the index folder. So the index.tmp files are keep
> growing in the data directory.
> Our data directory is "/ngs/app/esearcht/Slave2index/data". When checked
> with ls -al in the index directory, there are some .nfs files still there,
> which are not letting index directory to be deleted. And these .nfs files
> are still being used by SOLR in jboss.
> This setup is giving issue only in linux. Is this known bug on linux?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3375:
-
Affects Version/s: (was: 3.6.1)
(was: 4.0)
Fix Version/s: 3.6.1
Thanks Roger for the detailed report. I already fixed some bugs in trunk that I
introduced in SOLR-2020 and I believe that this problem should be fixed there
(r1327635).
I will leave this issue open so that if there will be a 3.6.1 release this fix
must be backported. In the meanwhile on 3.x the only workaround is to use the
CommonsHttpSolrServer.
> Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
> -
>
> Key: SOLR-3375
> URL: https://issues.apache.org/jira/browse/SOLR-3375
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 3.6
>Reporter: Roger Håkansson
> Fix For: 3.6.1
>
> Attachments: SolrTest.java, commonshttpsolrserver-dump.txt,
> httpsolrserver-dump.txt
>
>
> I've written an application which sends PDF files to Solr for indexing, but I
> also need to index some meta-data which isn't contained inside the PDF.
> I recently upgraded to 3.6.0 and when recompiling my app, I got some
> deprecated messages which mainly was to switch from CommonsHttpSolrServer to
> HttpSolrServer.
> The problem I've noticed since doing this, is that all extra fields which I
> add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
> matter, anything above char 127 is sent as '?'. This was not the behaviour of
> CommonsHttpSolrServer.
> I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
> entity.addPart(name, new StringBody(value));
> The problem is that StringBody(String text) maps to
> StringBody(text, "text/plain", null);
> and in
> StringBody(String text, String mimeType, Charset charset)
> we have this piece of code:
> if (charset == null) {
> charset = Charset.forName("US-ASCII");
> }
> this.content = text.getBytes(charset.name());
> this.charset = charset;
> So unless charset is set everything is converted to US-ASCII.
> On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
> this line
> parts.add(new StringPart(p, v, "UTF-8"));
> which adds everything as UTF-8.
> The simple solution would be to change the faulty line in HttpSolrServer.java
> to
> entity.addPart(name, new StringBody(value,Charset.forName("UTF-8")));
> However, this doesn't work either since my tests have shown that neither
> Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
> (8859-1 I guess).
> So changing HttpSolrServer.java to
> entity.addPart(name, new StringBody(value,Charset.forName("ISO-8859-1")));
> actually gives me the same result as using CommonsHttpSolrServer.
> But my investigations have shown that there is a difference in how
> Commons-HttpClient and HttpClient-4.x works.
> Commons-HttpClient sends all parameters as regular POST parameters but
> URLEncoded (/update/extract?param1=value¶m2=value2) while
> HttpClient-4.x sends them as multipart/form-data messages and I think that
> the problem is that each multipart-message should have its own charset
> parameter.
> I.e HttpClient-4.x sends
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> åäö
> ---
> But it should probably send something like this
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> Content-Type: text/plain; charset=utf-8
> åäö
> ---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3374) HttpClient jar not included in distribution
[ https://issues.apache.org/jira/browse/SOLR-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3374: - Fix Version/s: 3.6.1 Assignee: Sami Siren HttpSolrServer in 3.6.0 is buggy (SOLR-3375) so even if the libs were there you should probably not use it. I am marking this to be fixed in 3.6.1 to get this fixed if there's another release from 3.x (trunk should be fine). > HttpClient jar not included in distribution > --- > > Key: SOLR-3374 > URL: https://issues.apache.org/jira/browse/SOLR-3374 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.6 >Reporter: Roger Håkansson >Assignee: Sami Siren >Priority: Minor > Fix For: 3.6.1 > > > In 3.6 CommonsHttpSolrServer is deprecated in favor for HttpSolrServer > however in the distribution under solrj-lib, non of the required jar files > for HttpClient 4.x is included -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2870) Test failure in SolrExampleJettyTest
[
https://issues.apache.org/jira/browse/SOLR-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-2870:
-
Attachment:
TEST-org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.xml
> Test failure in SolrExampleJettyTest
>
>
> Key: SOLR-2870
> URL: https://issues.apache.org/jira/browse/SOLR-2870
> Project: Solr
> Issue Type: Bug
> Environment: r1196292 (trunk)
>Reporter: Sami Siren
> Attachments:
> TEST-org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.xml
>
>
> I saw this non reproducible error today once. I also saw similar error with
> SolrExampleEmbeddedTest.
> {code}
> type="java.lang.RuntimeException">java.lang.RuntimeException:
> java.lang.AssertionError: directory of test was not closed, opened from:
> org.apache.solr.core.MockDirectoryFactory.create(MockDirectoryFactory.java:33)
> at
> org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:474)
> at
> org.apache.lucene.util.LuceneTestCase.checkResourcesAfterClass(LuceneTestCase.java:532)
> at
> org.apache.lucene.util.LuceneTestCase.afterClassLuceneTestCaseJ4(LuceneTestCase.java:442)
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch This patch implements a simple overseer (cluster leader). Currently it does not do more than assign shard ids to cores so there is no added functionality. I wanted to post what I currently have here to get some feedback and improvement ideas. Two new top level zkNodes are created: /node_assignments /node_states Basically the integration point is the ZKController: When a core is registered its state is registered locally and nodes current state is published under /node_states When overseer assigns a shard id the state is stored locally (to overseer) and the assignments for the node are published under /node_assignments. Overseer gets the number of shards required for a collection from the collections properties in ZK. So if you wanted to add a new collection you'd create a new collection node and record the required number of shards (among other things like the used configuration) into its properties. Even if a node hosts multiple cores it only creates single node (/node_states/) and reads a single node (/node_assignments/). It might be simpler to have multiple subnodes (one for each core) > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880-merge-elections.patch The attached patch merges the election code. The OverseerElectionTest should be removed because it now has nothing special to test. SliceLeaderElector should perhaps be renamed to LeaderElector or something like that. > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2821) Improve how cluster state is managed in ZooKeeper.
[ https://issues.apache.org/jira/browse/SOLR-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2821: - Attachment: SOLR-2821.patch Here's a patch that changes the serialization format to json for all the data types currently stored in ZK. The cloudstate serialization code is awfully verbose but so is the current xml code too. If all the objects were maps or lists the ser/deser would be super simple as Yonik said. > Improve how cluster state is managed in ZooKeeper. > -- > > Key: SOLR-2821 > URL: https://issues.apache.org/jira/browse/SOLR-2821 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2821.patch > > > Currently, we have issues supporting both incremental cluster state updates > (needed because reading the state with many ZK requests does not scale) and > allowing shard/node properties to change on the fly. We be nice to have a > solution that allows faster cluster state reads and easy on the fly > shard/node prop changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch Here's a patch that fixes a bug that causes some state updates to be missed when overseer node crashes. It also removes the "_" prefixes from the mentioned property names and use numShards as shard count property name. > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: current.patch The attached patch removes the numShards property from the collection node. It also simplifies Overseer by converting it to use ZkStateReader instead of maintaining the read side of cloudstate internally and by removing bunch of not useful code. I also removed the unneeded IOException from method signatures that I added when I converted the serialization to json (they become obsolete when Yonik improved the ser/deser code). > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: (was: current.patch) > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch The correct patch. > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2481) Add support for commitWithin in DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2481: - Attachment: SOLR-2481.patch updated the patch so that it applies to current trunk. > Add support for commitWithin in DataImportHandler > - > > Key: SOLR-2481 > URL: https://issues.apache.org/jira/browse/SOLR-2481 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Sami Siren >Priority: Trivial > Attachments: SOLR-2481.patch, SOLR-2481.patch > > > It looks like DataImportHandler does not support commitWithin. Would be nice > if it did. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch This patch -fixes a bug in overseer where when two cores were registered close to each other the edits for the latter would have gone to a stale cloudState. -the zk nodes the overseer requires are now done in single method call before the live node is created -some old cruft is also removed > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch the last patch missed some edits, here's a new one. > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch Attached patch allows overseer to track shard leaders and update cloud state accordingly. Shard leader is marked with prop leader="true" in its cloudstate props. Also some of the tests are improved so that they are less likely to fail due to timing issues. > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, > SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2880) Investigate adding an overseer that can assign shards, later do re-balancing, etc
[ https://issues.apache.org/jira/browse/SOLR-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2880: - Attachment: SOLR-2880.patch another patch: got rid of CoreAssignment - ZkController now receives shardids through cloudstate, pumped up some counters to get rid of problems with timings, small improvements in OverseerTest > Investigate adding an overseer that can assign shards, later do re-balancing, > etc > - > > Key: SOLR-2880 > URL: https://issues.apache.org/jira/browse/SOLR-2880 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 4.0 > > Attachments: SOLR-2880-merge-elections.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, SOLR-2880.patch, > SOLR-2880.patch, SOLR-2880.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3006) Schema related problems are not logged
[
https://issues.apache.org/jira/browse/SOLR-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3006:
-
Attachment: SOLR-3006.patch
This trivial patch seems to do what I wanted.
> Schema related problems are not logged
> --
>
> Key: SOLR-3006
> URL: https://issues.apache.org/jira/browse/SOLR-3006
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.0
> Environment: example run like: java -jar start.jar
>Reporter: Sami Siren
>Priority: Minor
> Attachments: SOLR-3006.patch
>
>
> If there's a problem in analyzer config or for example some mandatory
> attribute is missing from fieldType definition the resulting exception is not
> currently shown on log (console).
> The only thing visible, logged two times, is this:
> {code}
> SEVERE: Could not start Solr. Check solr/home property and the logs
> org.apache.solr.common.SolrException: No cores were created, please check the
> logs for errors
> {code}
> If I load the solr web page it shows the actual error(s). It would be nice if
> the problem was also logged on console/log.
> There's some suspicious looking lines in AbstractPluginLoader at around line
> 169:
> {code}
> SolrException e = new SolrException
> (ErrorCode.SERVER_ERROR,
> "Plugin init failure for " + type + ":" + ex.getMessage(), ex);
> {code}
> where the SolrException is created with a constructor that sets the logged
> flag to true. Still there is a line
> {code}
> SolrException.logOnce(log,null,e);
> {code}
> a little later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3036) XMLoader should support setting overwrite=false in request params
[ https://issues.apache.org/jira/browse/SOLR-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3036: - Affects Version/s: 4.0 > XMLoader should support setting overwrite=false in request params > - > > Key: SOLR-3036 > URL: https://issues.apache.org/jira/browse/SOLR-3036 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3036.patch > > > I checked most of the other updatehandlers and they already support this so > to make the story complete why not add it to the xml one too. The other > reason is that I just realized that solrj uses the xml format by default but > that should go into other issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3036) XMLoader should support setting overwrite=false in request params
[ https://issues.apache.org/jira/browse/SOLR-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3036: - Attachment: SOLR-3036.patch > XMLoader should support setting overwrite=false in request params > - > > Key: SOLR-3036 > URL: https://issues.apache.org/jira/browse/SOLR-3036 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3036.patch > > > I checked most of the other updatehandlers and they already support this so > to make the story complete why not add it to the xml one too. The other > reason is that I just realized that solrj uses the xml format by default but > that should go into other issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3036) XMLoader should support setting overwrite=false in request params
[ https://issues.apache.org/jira/browse/SOLR-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3036: - Attachment: SOLR-3036.patch +test > XMLoader should support setting overwrite=false in request params > - > > Key: SOLR-3036 > URL: https://issues.apache.org/jira/browse/SOLR-3036 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3036.patch, SOLR-3036.patch > > > I checked most of the other updatehandlers and they already support this so > to make the story complete why not add it to the xml one too. The other > reason is that I just realized that solrj uses the xml format by default but > that should go into other issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3036) XMLoader should support setting overwrite=false in request params
[ https://issues.apache.org/jira/browse/SOLR-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3036: - Attachment: SOLR-3036.patch fix asserts in test > XMLoader should support setting overwrite=false in request params > - > > Key: SOLR-3036 > URL: https://issues.apache.org/jira/browse/SOLR-3036 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3036.patch, SOLR-3036.patch, SOLR-3036.patch > > > I checked most of the other updatehandlers and they already support this so > to make the story complete why not add it to the xml one too. The other > reason is that I just realized that solrj uses the xml format by default but > that should go into other issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3036) XMLoader should support setting overwrite=false in request params
[ https://issues.apache.org/jira/browse/SOLR-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3036: - Attachment: SOLR-3036.patch fix previous fix (time to get some more coffee) > XMLoader should support setting overwrite=false in request params > - > > Key: SOLR-3036 > URL: https://issues.apache.org/jira/browse/SOLR-3036 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3036.patch, SOLR-3036.patch, SOLR-3036.patch, > SOLR-3036.patch > > > I checked most of the other updatehandlers and they already support this so > to make the story complete why not add it to the xml one too. The other > reason is that I just realized that solrj uses the xml format by default but > that should go into other issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3037) When using binary format in solrj the codec screws up parameters
[ https://issues.apache.org/jira/browse/SOLR-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3037: - Attachment: SOLR-3037.patch fix serialization for params and add the beginnings of a test case for BinaryUpdateRequestHandler > When using binary format in solrj the codec screws up parameters > > > Key: SOLR-3037 > URL: https://issues.apache.org/jira/browse/SOLR-3037 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3037.patch > > > There's a bug in JavaBinUpdateRequestCodec when it serializes the params. So > you cannot use params (like overwrite=false) when using the binary wire > format. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3063) Bug in LeaderElectionIntgrationTest
[ https://issues.apache.org/jira/browse/SOLR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3063: - Attachment: SOLR-3063.patch patch > Bug in LeaderElectionIntgrationTest > --- > > Key: SOLR-3063 > URL: https://issues.apache.org/jira/browse/SOLR-3063 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren >Priority: Minor > Attachments: SOLR-3063.patch > > > #getLeader() tries to get leader props from stale zkStateReader (one that has > not set watches). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3065) Let overseer process cluster state changes asynchronously
[ https://issues.apache.org/jira/browse/SOLR-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3065: - Attachment: SOLR-3065.patch -process cluster state updates asynchronously (now once per 500ms) -make sure overseer is still leader before updating the state > Let overseer process cluster state changes asynchronously > - > > Key: SOLR-3065 > URL: https://issues.apache.org/jira/browse/SOLR-3065 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren >Priority: Minor > Attachments: SOLR-3065.patch > > > Currently the overseer updates clusterstate.json on almost every change - one > change at a time. This is not efficient when there are a lot of changes > happening in short period of time (for example when a number of hosts are > started at once). > It would be better if changes were published on timely manner instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3068) Occasional NPE in ThreadDumpHandler
[ https://issues.apache.org/jira/browse/SOLR-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3068: - Attachment: SOLR-3068.patch add check against nulls > Occasional NPE in ThreadDumpHandler > --- > > Key: SOLR-3068 > URL: https://issues.apache.org/jira/browse/SOLR-3068 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Sami Siren >Priority: Trivial > Attachments: SOLR-3068.patch > > > Seen this now few times, looks like the thread has died a way between > requesting the ids and requesting the ThreadInfos. > SEVERE: java.lang.NullPointerException > at > org.apache.solr.handler.admin.ThreadDumpHandler.getThreadInfo(ThreadDumpHandler.java:87) > at > org.apache.solr.handler.admin.ThreadDumpHandler.handleRequestBody(ThreadDumpHandler.java:75) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1523) > at org.apache.solr.util.TestHarness.query(TestHarness.java:354) > at org.apache.solr.util.TestHarness.query(TestHarness.java:337) > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:397) > at > org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers(MinimalSchemaTest.java:116) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) > at > org.apache.lucene.util.LuceneTestCase$3$1.evaluate(LuceneTestCase.java:529) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) > at > org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3075) Overseer does not check cloudstate for previously assigned shardId but generates a new one
[ https://issues.apache.org/jira/browse/SOLR-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3075: - Attachment: SOLR-3075.patch -fix + test -also convert #testOverseerFailure to use MockZKController > Overseer does not check cloudstate for previously assigned shardId but > generates a new one > -- > > Key: SOLR-3075 > URL: https://issues.apache.org/jira/browse/SOLR-3075 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Sami Siren > Attachments: SOLR-3075.patch > > > Overseer does not check if core has already been assigned an shardId before > assigning it a new shardId -> same core could end up having multiple shardIds > in CloudState. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3080: - Attachment: SOLR-3080.patch Here's an initial patch to implement this feature. I still need to add some more junit tests. I noticed that CoreAdminHandler allows "creating" multiple cores with same name and if you do that you can end up having one core in multiple places unless you remove it in between. Is this behavior of CoreAdminHandler intentional? Also I was not sure if the slice should be deleted when there are no more shards with that id (currently it is not deleted). > We should consider removing shard info from Zk when you explicitly unload a > SolrCore. > - > > Key: SOLR-3080 > URL: https://issues.apache.org/jira/browse/SOLR-3080 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3080.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3088) create shard placeholders
[ https://issues.apache.org/jira/browse/SOLR-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3088: - Attachment: SOLR-3088.patch Initial patch. Once the changes in SOLR-3108 gets committed this patch needs to be updated to so that the System property is no longer used. > create shard placeholders > - > > Key: SOLR-3088 > URL: https://issues.apache.org/jira/browse/SOLR-3088 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley > Fix For: 4.0 > > Attachments: SOLR-3088.patch > > > When creating a new collection, a placeholder for each shard should be > created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3088) create shard placeholders
[ https://issues.apache.org/jira/browse/SOLR-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3088: - Attachment: SOLR-3088.patch an updated patch that applies with current trunk > create shard placeholders > - > > Key: SOLR-3088 > URL: https://issues.apache.org/jira/browse/SOLR-3088 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley > Fix For: 4.0 > > Attachments: SOLR-3088.patch, SOLR-3088.patch > > > When creating a new collection, a placeholder for each shard should be > created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3768) Typo in some of the .alg files: ForcMerge instead of ForceMerge
[
https://issues.apache.org/jira/browse/LUCENE-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated LUCENE-3768:
---
Attachment: LUCENE-3768.patch
a fix for this issue
> Typo in some of the .alg files: ForcMerge instead of ForceMerge
> ---
>
> Key: LUCENE-3768
> URL: https://issues.apache.org/jira/browse/LUCENE-3768
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/benchmark
>Affects Versions: 4.0
>Reporter: Sami Siren
> Attachments: LUCENE-3768.patch
>
>
> Some of the alg files have a typo and have ForcMerge when they should have
> ForceMerge. This causes following exception to display when those are used:
> {code}
> [java] java.lang.Exception: Error: cannot understand algorithm!
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:63)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.exec(Benchmark.java:109)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.main(Benchmark.java:84)
> [java] Caused by: java.lang.ClassNotFoundException: ForcMerge not found
> in packages [org.apache.lucene.benchmark.byTask.tasks]
> [java] at
> org.apache.lucene.benchmark.byTask.utils.Algorithm.taskClass(Algorithm.java:283)
> [java] at
> org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:73)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:61)
> [java] ... 2 more
> {code}
> Caused by: java.lang.ClassNotFoundException: ForcMerge not found in packages
> [org.apache.lucene.benchmark.byTask.tasks]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3080) We should consider removing shard info from Zk when you explicitly unload a SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3080: - Attachment: SOLR-3080.patch Here's a new patch. when running in cloud mode I am preventing creation of core if the name is not locally unique. > We should consider removing shard info from Zk when you explicitly unload a > SolrCore. > - > > Key: SOLR-3080 > URL: https://issues.apache.org/jira/browse/SOLR-3080 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3080.patch, SOLR-3080.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3768) Typo in some of the .alg files: ForcMerge instead of ForceMerge
[
https://issues.apache.org/jira/browse/LUCENE-3768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated LUCENE-3768:
---
Attachment: LUCENE-3768.patch
A new patch that adds a junit test that parses through the examples.
I am not sure if there is a better way to access the conf dir from a test.
> Typo in some of the .alg files: ForcMerge instead of ForceMerge
> ---
>
> Key: LUCENE-3768
> URL: https://issues.apache.org/jira/browse/LUCENE-3768
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/benchmark
>Affects Versions: 4.0
>Reporter: Sami Siren
> Attachments: LUCENE-3768.patch, LUCENE-3768.patch
>
>
> Some of the alg files have a typo and have ForcMerge when they should have
> ForceMerge. This causes following exception to display when those are used:
> {code}
> [java] java.lang.Exception: Error: cannot understand algorithm!
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:63)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.exec(Benchmark.java:109)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.main(Benchmark.java:84)
> [java] Caused by: java.lang.ClassNotFoundException: ForcMerge not found
> in packages [org.apache.lucene.benchmark.byTask.tasks]
> [java] at
> org.apache.lucene.benchmark.byTask.utils.Algorithm.taskClass(Algorithm.java:283)
> [java] at
> org.apache.lucene.benchmark.byTask.utils.Algorithm.(Algorithm.java:73)
> [java] at
> org.apache.lucene.benchmark.byTask.Benchmark.(Benchmark.java:61)
> [java] ... 2 more
> {code}
> Caused by: java.lang.ClassNotFoundException: ForcMerge not found in packages
> [org.apache.lucene.benchmark.byTask.tasks]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3165) Cannot use DIH in Solrcloud + Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3165:
-
Attachment: SOLR-3165.patch
Here's a stab at fixing this issue. I noticed there were two places where DIH
wanted to access conf dir: the config file (read) and some kind of state file
(read/write) access.
I added ZKPropertiesWriter that writes the contents of the state file into zk.
> Cannot use DIH in Solrcloud + Zookeeper
> ---
>
> Key: SOLR-3165
> URL: https://issues.apache.org/jira/browse/SOLR-3165
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 4.0
>Reporter: Agnieszka
> Attachments: SOLR-3165.patch
>
>
> There is a problem with configure DIH in Solrcloud + Zookeeper configuration
> from wiki:
> http://wiki.apache.org/solr/SolrCloud.
> Standard configuration in solrconfig.xml:
> {code:xml}
>class="org.apache.solr.handler.dataimport.DataImportHandler">
>
>db-data-config.xml
>
>
> {code}
> After starting solr with zookeeper I've got errors:
> {noformat}
> Feb 20, 2012 11:30:12 AM org.apache.solr.common.SolrException log
> SEVERE: null:org.apache.solr.common.SolrException
> at org.apache.solr.core.SolrCore.(SolrCore.java:606)
> at org.apache.solr.core.SolrCore.(SolrCore.java:490)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:705)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:442)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:313)
> at
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:262)
> at
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:98)
> at
> org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
> at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
> at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.mortbay.start.Main.invokeMain(Main.java:194)
> at org.mortbay.start.Main.start(Main.java:534)
> at org.mortbay.start.Main.start(Main.java:441)
> at org.mortbay.start.Main.main(Main.java:119)
> Caused by: org.apache.solr.common.SolrException: FATAL: Could not create
> importer. DataImporter config invalid
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:120)
> at
> org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:542)
> at org.apache.solr.core.SolrCore.(SolrCore.java:601)
> ... 31 more
> Caused by: org.apache.solr.common.cloud.ZooKeeperException:
> ZkSolrResourceLoader does not support getConfigDir() - likely, w
> at
> org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
> at
> org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:47)
> at
> org.apache.solr.handler.dataimport.DataImporter.(DataImporter.java:112)
> at
> org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:114)
> ... 33 more
> {noformat}
> But the db-
[jira] [Updated] (SOLR-3187) SystemInfoHandler leaks filehandles
[ https://issues.apache.org/jira/browse/SOLR-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3187: - Attachment: SOLR-3187.patch fix for this issue > SystemInfoHandler leaks filehandles > --- > > Key: SOLR-3187 > URL: https://issues.apache.org/jira/browse/SOLR-3187 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5, 4.0 >Reporter: Sami Siren >Priority: Minor > Attachments: SOLR-3187.patch > > > The some of the input/output/error streams when running external process are > not closed properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3187) SystemInfoHandler leaks filehandles
[ https://issues.apache.org/jira/browse/SOLR-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3187: - Attachment: SOLR-3187.patch another try, add check for process being null. I also removed the "ulimit -n" thing since this information is already available through UnixOperatingSystemMXBean. > SystemInfoHandler leaks filehandles > --- > > Key: SOLR-3187 > URL: https://issues.apache.org/jira/browse/SOLR-3187 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5, 4.0 >Reporter: Sami Siren >Priority: Minor > Attachments: SOLR-3187.patch, SOLR-3187.patch > > > The some of the input/output/error streams when running external process are > not closed properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2020: - Attachment: SOLR-2020.patch This patch completes the conversion. All tests pass but there's still some cleanup work to do + couple of places where I cut corners. > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-HttpSolrServer.patch, > SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3148) SystemInfoHandler does not expose all available info
[
https://issues.apache.org/jira/browse/SOLR-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3148:
-
Affects Version/s: 3.6
> SystemInfoHandler does not expose all available info
>
>
> Key: SOLR-3148
> URL: https://issues.apache.org/jira/browse/SOLR-3148
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.6, 4.0
>Reporter: Sami Siren
>Assignee: Sami Siren
>Priority: Minor
> Fix For: 3.6, 4.0
>
>
> The following info is not returned even when they are available (on java 1.6
> and 1.7):
> {code}
> getSystemLoadAverage()
> getOpenFileDescriptorCount()
> getMaxFileDescriptorCount()
> getCommittedVirtualMemorySize()
> getTotalPhysicalMemorySize()
> getTotalSwapSpaceSize()
> getProcessCpuTime()
> {code}
> This is happening because the following exception is thrown:
> {code}
> java.lang.IllegalAccessException: Class
> org.apache.solr.handler.admin.SystemInfoHandler can not access a member of
> class com.sun.management.UnixOperatingSystem with modifiers "public native"
> {code}
> It seems to be enough to call setAccessible(true) on the method to get rid of
> that exception.
> Additionally I see a strange value for the ulimit key:
> "ulimit":"(error executing: ulimit -n)",
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3148) SystemInfoHandler does not expose all available info
[
https://issues.apache.org/jira/browse/SOLR-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3148:
-
Fix Version/s: 3.6
> SystemInfoHandler does not expose all available info
>
>
> Key: SOLR-3148
> URL: https://issues.apache.org/jira/browse/SOLR-3148
> Project: Solr
> Issue Type: Bug
>Affects Versions: 3.6, 4.0
>Reporter: Sami Siren
>Assignee: Sami Siren
>Priority: Minor
> Fix For: 3.6, 4.0
>
>
> The following info is not returned even when they are available (on java 1.6
> and 1.7):
> {code}
> getSystemLoadAverage()
> getOpenFileDescriptorCount()
> getMaxFileDescriptorCount()
> getCommittedVirtualMemorySize()
> getTotalPhysicalMemorySize()
> getTotalSwapSpaceSize()
> getProcessCpuTime()
> {code}
> This is happening because the following exception is thrown:
> {code}
> java.lang.IllegalAccessException: Class
> org.apache.solr.handler.admin.SystemInfoHandler can not access a member of
> class com.sun.management.UnixOperatingSystem with modifiers "public native"
> {code}
> It seems to be enough to call setAccessible(true) on the method to get rid of
> that exception.
> Additionally I see a strange value for the ulimit key:
> "ulimit":"(error executing: ulimit -n)",
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2020: - Attachment: SOLR-2020.patch Improved patch with cleanups + additional tests. > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Fix For: 4.0 > > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-HttpSolrServer.patch, > SOLR-2020.patch, SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2020: - Attachment: SOLR-2020.patch Few more small fixes. I think this is getting close to be committed. > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Fix For: 4.0 > > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-HttpSolrServer.patch, > SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2020: - Attachment: SOLR-2020.patch minor fixes, javadocs, maven pom files > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Fix For: 4.0 > > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-HttpSolrServer.patch, > SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2020: - Attachment: SOLR-2020-3x.patch Here's a patch to 3.x branch that deprecates CommonsHttpSolrServer.java > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Fix For: 4.0 > > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, > SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, > SOLR-2020.patch, SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
