[JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}) - Build # 2709 - Failure! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_96_1462925234.1364928350913 X-Jenkins-Job: Lucene-Solr-trunk-Windows X-Jenkins-Result: FAILURE Precedence: bulk --=_Part_96_1462925234.1364928350913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2709/ Java: [[ Exception while replacing ENV. Please report this as a bug. ]] {{ java.lang.NullPointerException }} No tests ran. Build Log: [...truncated 145 lines...] FATAL: null java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.Reader.read(Reader.java:140) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1128) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1104) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1050) at org.apache.commons.io.IOUtils.toString(IOUtils.java:359) at hudson.FilePath.readToString(FilePath.java:1557) at hudson.tools.DownloadFromUrlInstaller.isUpToDate(DownloadFromUrlInstaller.java:45) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:69) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:203) at hudson.tasks.Ant$AntInstallation.forNode(Ant.java:375) at hudson.tasks.Ant.perform(Ant.java:151) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:798) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580) at hudson.model.Run.execute(Run.java:1575) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) --=_Part_96_1462925234.1364928350913-- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4661: --- Attachment: hoss_test.zip bq. Step to reproduce this issue is simple. Just apply commit on master without posting any documents Ah... ok, wait a minute - this looks promising. in reviewing the logs you sent to solr-user@lucene i didn't notice that this empty commit was happening, but in attempting to reproduce i think i see what you're talking about. Steps i followed... {panel} 1) took the Solr 4.2 example/solr dir and cloned it as master-home 2) edited the /replication handler to match what you posted in this issue (but adjusted the replicaiton time to 30 seconds for a faster test) 3) cloned master-home as slave-home 4) ran two instances of Solr 4.2 using hte following commands... {noformat} java -Denable.master=true -Dmaster.port=8999 -Djetty.port=8999 -Dsolr.solr.home=/home/hossman/tmp/ave_version_higher/master-home -jar start.jar /home/hossman/tmp/slave_version_higher/master.log java -Denable.slave=true -Dmaster.port=899-Djetty.port= -Dsolr.solr.home=/home/hossman/tmp/slave_version_higher/slave-home -jar start.jar /home/hossman/tmp/slave_version_higher/slave.log {noformat} 5) ran two scripts to monitor replication details using the following commands... {noformat} while true; do date --utc curl -sS http://localhost:/solr/collection1/replication?command=detailsindent=truewt=json; echo echo sleep 2; done slave_rep_details.txt while true; do date --utc curl -sS http://localhost:8999/solr/collection1/replication?command=detailsindent=truewt=json; echo echo sleep 2; done master_rep_details.txt {noformat} 6) triggered an indexing of all the example docs on master, and waited for replication. {noformat} java -Durl=http://localhost:8999/solr/collection1/update -jar post.jar *.xml {noformat} 7) triggered an explicit commit on master... {noformat} java -Durl=http://localhost:8999/solr/collection1/update -jar post.jar - {noformat} 8) shutdown both servers and the scripts (Ctrl-C) {panel} I've attached the full logs and home dirs at the completion of this test, but as a summmary of the results... {panel} a) slave master index files are identical except for segments.gen b) the master's replication details indicate that the current commit being used is indexVersion#1364927050819, generation#2 but it's list of commits does not include this, it contains a single commit of indexVersion#1364927114002, generation#3 c) the slave's replication details indicate that the current commit being used is indexVersion#1364927050819, generation#2 and that this is the only commit it has locally. The slave's information about hte master is consistent with what the master itself reports. {panel} I'm not certain, but I believe this is just an optimization where the searcher is not re-opened when the currently opened commit is identical to the new commit -- this optimization is working on the master, but aparently not on the slave (maybe the slave can't tell that the commits are identical?) FWIW: after running this test, i restarted the master and it's replication details were consistent with the list of commit points -- it was using generation #3. You can also observe the exact same behavior from master's replication details (current generation lower then the generation of any commit point) if you do a hard commit with openSearcher=false. I think most of the behavior here makes sense -- the slave is replicating the commits from the master, even if the master isn't using them yet because it hasn't opened a new searcher. The key questions i wonder about: 1) why was segments.get different when i ran my experiment? is that normal? 2) Assuming i'm correct about their being an optimization to not open a new searcher if the commits are identical, can we make this same optimization work on slaves in the case of replication? Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620143#comment-13620143 ] Erick Erickson commented on SOLR-4662: -- bq: so that solr.solr.home isn't cluttered I'm not sure about this either. There's no assumption when walking the tree that any instancedirs appear as immediate children of solr_home, you can have as many levels to the tree as you want. What _is_ enforced is that when a core.properties file is found, Solr doesn't look any deeper. In other words there is no nesting of cores allowed. You can mix-and-match the level down the tree where the core is defined, subject to the above rule. So you could have a tree with only one directory in solr_home that was the root of a tree with all your cores like: solr_home cores level1a level1.1 core1.1.1 core1.1.2 core1.1.3 level1.2 core2.1.1 core2.1.2 level2a core2a.1.1 I'm not totally anti the idea, but would rather not start putting a bunch of stuff back into solr.xml if we can help it. Can this be made to work in your use-case or is there another reason besides clutter you'd want to root the cores someplace other than solr_home? Being able to cleanly separate the running solr from the data does come to mind, i.e. I might like to rm -rf solr_home and put in a new release without touching my data. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
RE: [JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]]
Hi, I restarted Jenkins master with slightly more permgen. I am not sure if this is the slave or the master having the problems. If it does not help I will raise permgen on slaves. Currently Jenkins has a problem with too many tests, too. We currently need -Xmx2048M on the master, because whenever you display the test results of a build, the garbage collector drives crazy and takes 200% CPU. There seems to be a memory leak in the Jenkins XML parser (DOM tree not streaming!!! -- horrible, maybe we have now too many tests for Jenkins, at least it does not scale well). If this stays broken, I will disable test result analysis, which disables all nice graphs, and also no longer displays failed tests in mails :( In addition: I installed JDK 8 b83, which has the G1 garbage collector bug making the full GC hang fixed (thanks to Dawid Weiss and John Cuthbertson). I removed the extra stack size JVM option used as workaround for 32 bit builds. The changelog, explicitly mentioning Apache Lucene, is here: http://download.java.net/jdk8/changes/jdk8-b83.html Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] Sent: Tuesday, April 02, 2013 8:46 PM To: dev@lucene.apache.org; dsmi...@apache.org; er...@apache.org Subject: [JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]] {{ java.lang.NullPointerException }}) - Build # 2709 - Failure! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_96_1462925234.1364928350913 X-Jenkins-Job: Lucene-Solr-trunk-Windows X-Jenkins-Result: FAILURE Precedence: bulk --=_Part_96_1462925234.1364928350913 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2709/ Java: [[ Exception while replacing ENV. Please report this as a bug. ]] {{ java.lang.NullPointerException }} No tests ran. Build Log: [...truncated 145 lines...] FATAL: null java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:17 5) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.Reader.read(Reader.java:140) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1128) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1104) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1050) at org.apache.commons.io.IOUtils.toString(IOUtils.java:359) at hudson.FilePath.readToString(FilePath.java:1557) at hudson.tools.DownloadFromUrlInstaller.isUpToDate(DownloadFromUrlInstal ler.java:45) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFrom UrlInstaller.java:69) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodePr operty.java:107) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:203) at hudson.tasks.Ant$AntInstallation.forNode(Ant.java:375) at hudson.tasks.Ant.perform(Ant.java:151) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild. java:798) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java: 580) at hudson.model.Run.execute(Run.java:1575) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) --=_Part_96_1462925234.1364928350913-- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620148#comment-13620148 ] Mark Miller commented on SOLR-4661: --- The slave will actually do a reload if conf files are being replicated - so it's sure to open a new searcher currently. They generally shouldn't change every time though. It's a surprise that the master wouldn't open a new searcher - not sure where that would get short circuited - would have to dig a little. Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
RE: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing
Hi John, today I installed JDK8 b83 on one of the Jenkins build servers used by Apache Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit builds without the extra workaround stacksize option again. Thanks for fixing this issue. Uwe - Uwe Schindler uschind...@apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -Original Message- From: hotspot-gc-dev-boun...@openjdk.java.net [mailto:hotspot-gc-dev- boun...@openjdk.java.net] On Behalf Of john.cuthbert...@oracle.com Sent: Tuesday, March 19, 2013 2:21 AM To: hotspot-gc-...@openjdk.java.net Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing Changeset: fa08949fe0cb Author:johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot- gc/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620174#comment-13620174 ] Hoss Man commented on SOLR-4661: bq. Assuming i'm correct about their being an optimization to not open a new searcher if the commits are identical, I did some more experimenting and confirmed i was wrong about this -- from Solr's perspective a new searcher is definitely getting opened and warmed. I'm not sure, but skimming the code I *think* this discrepancy between the commit point in use and the commit point on disk may just be a result of using DirectoryReader.openIfChanged in SolrCore.openNewSearcher ... i got lost a bit in the code, but is it possible the reader DirectoryReader is returning null because only the generation changed by the comment, but not any of the actual indexed data? Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Created] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
Michael McCandless created LUCENE-4898: -- Summary: Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT Key: LUCENE-4898 URL: https://issues.apache.org/jira/browse/LUCENE-4898 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Attachments: LUCENE-4898.patch This throws an IllegalArRgumentException today, but it's easy to fix with a small change to DirectoryReader. This is useful to do, if you have an NRT reader and want to open a reader against a previous commit point while sharing the SegmentReaders they have in common. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
[ https://issues.apache.org/jira/browse/LUCENE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4898: --- Attachment: LUCENE-4898.patch Patch. Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT Key: LUCENE-4898 URL: https://issues.apache.org/jira/browse/LUCENE-4898 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Attachments: LUCENE-4898.patch This throws an IllegalArRgumentException today, but it's easy to fix with a small change to DirectoryReader. This is useful to do, if you have an NRT reader and want to open a reader against a previous commit point while sharing the SegmentReaders they have in common. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Assigned] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
[ https://issues.apache.org/jira/browse/LUCENE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-4898: -- Assignee: Michael McCandless Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT Key: LUCENE-4898 URL: https://issues.apache.org/jira/browse/LUCENE-4898 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-4898.patch This throws an IllegalArRgumentException today, but it's easy to fix with a small change to DirectoryReader. This is useful to do, if you have an NRT reader and want to open a reader against a previous commit point while sharing the SegmentReaders they have in common. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620192#comment-13620192 ] Yonik Seeley commented on SOLR-3755: Nice that this is on a git branch - no stale patches, and you can see the full history! Does anyone know an easy way to generate a diff? I did the following: {code} git clone https://github.com/shalinmangar/lucene-solr.git lusolr_shardsplitting cd lusolr_shardsplitting git remote add upstream git://git.apache.org/lucene-solr.git git diff remotes/upstream/trunk remotes/origin/trunk {code} But this does a diff with the current state of the trunk vs the branch. Any tips from the git wizards out there? shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755-combined.patch, SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620195#comment-13620195 ] Mark Miller commented on SOLR-4661: --- It seems possible: {code} // If in fact no changes took place, return null: if (reader.getVersion() == segmentInfos.getVersion()) { reader.decRef(); return null; } {code} version described as: {code} /** * Version number when this IndexReader was opened. * * pThis method * returns the version recorded in the commit that the * reader opened. This version is advanced every time * a change is made with {@link IndexWriter}./p */ {code} version is incremented when: {code} /** Call this before committing if changes have been made to the * segments. */ public void changed() { version++; } {code} Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620207#comment-13620207 ] Mark Miller commented on SOLR-3755: --- AFAIK it's somewhat annoying - usually it involves doing a squash commit on a tmp branch and diffing with that if you want it nicely in one file/chunk. Otherwise git format-patch can go back n commits and make a diff for each one and you'd have to stitch them together. shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755-combined.patch, SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620208#comment-13620208 ] Mark Miller commented on SOLR-3755: --- bq. Was trying to look into it but strangely, I haven't run into it over 15 consecutive runs. It's very common for these types of tests to be sensitive to the exact env (hardware, OS, etc). A lot of times it's some timing issue. shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755-combined.patch, SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620215#comment-13620215 ] Anshum Gupta commented on SOLR-3755: You'd need to do a git merge and then compare it with the current branch. git fetch upstream git merge upstream/trunk git diff --no-prefix upstream/trunk This should show the diff. For now, I've just merged the current state of the trunk with this branch. Getting the diff now should be straight forward. shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755-combined.patch, SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-3755) shard splitting
[ https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620224#comment-13620224 ] Anshum Gupta commented on SOLR-3755: Mark, you're right, it seems like a timing issue. I don't think even Shalin has been able to to recreate it too often under the same environment. Not even with the same seed. shard splitting --- Key: SOLR-3755 URL: https://issues.apache.org/jira/browse/SOLR-3755 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Attachments: SOLR-3755-combined.patch, SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch We can currently easily add replicas to handle increases in query volume, but we should also add a way to add additional shards dynamically by splitting existing shards. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620237#comment-13620237 ] Mark Miller commented on SOLR-4662: --- As far as xml format...I'm thinking along the lines of: note: persistent should be removed as an option. note: adminPath should no longer be configurable - solrcloud counts on it being that. note: defaultCoreName should probably also go away if using the new format - it's really a back compat thing that we don't want to support long term. {noformat} solr solrcloud str name=host127.0.0.1/str str name=hostPort${hostPort:8983}/str /solrcloud shardHandlerFactory ... /solr {noformat} Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620241#comment-13620241 ] Shawn Heisey commented on SOLR-4662: bq. There's no assumption when walking the tree that any instancedirs appear as immediate children That's good, and is awesome for detection of existing cores on startup, but what about features that automatically create new core directories? This already happens with the SolrCloud collection API, and if we implement the configs directory for config sets that aren't stored in zookeeper, it is likely to happen for non-Cloud deployments too. I am aware that my statements may seem somewhat disconnected, because in some ways they are. I'm dealing with two different Solr deployments that each have their own needs. 1) I have a pretty small SolrCloud deployment with two servers plus a third zk node, numShards=1. I don't implement separation here, but it's not really needed. It currently places core directories right into solr.home, but I would like to change that. 2) My main large Solr deployment doesn't use SolrCloud, and is not likely to use SolrCloud in the foreseeable future. That is where I have things heavily separated into cores, data, and config. In a cloud/zk deployment, you get dataDir separation for free, because the core config is elsewhere. This would also be the case with filesystem-based config sets. We therefore might not need to worry too much about the separation idea that I initially had, but I do think that it's important to have the cores go into a subdirectory by default. bq. would rather not start putting a bunch of stuff back into solr.xml if we can help it +1 from me on that. Anything that we can move out of that file we should - basically make it so that only what's required at a global level to locate the rest of the resources Solr needs, plus any server-level config options that don't have an excellent all-purpose default. I think a 'coreDirectory' option falls into both of those categories. In a ZK-controlled world, a lot of global config options can be stored in ZK, but there are very good reasons to have a different coreDirectory option on each server. bq. I might like to rm -rf solr_home and put in a new release without touching my data What I do for this is completely separate solr.home and CWD (jetty.home). CWD is /opt/solr4, solr.home is /index/solr4, and /index is a different filesystem. There are jars for jetty and log4j in /opt/solr4/lib, and extra jars for solr, lucene, and mysql in /index/solr4/lib. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.
[ https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620245#comment-13620245 ] crocket commented on LUCENE-4894: - However, without facet user guide, I wouldn't have known that it ever existed. You may still need to advertise the facet module in http://lucene.apache.org/core/4_x_x/index.html Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations. Key: LUCENE-4894 URL: https://issues.apache.org/jira/browse/LUCENE-4894 Project: Lucene - Core Issue Type: Bug Components: general/website, modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Minor * Concurrent Indexing and Search There is no clear explanation regarding those points below. 1. TaxonomyReader should be reopened after IndexReader. 2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter should be closed before IndexWriter. The rationale is that it's ok to see categories to which no document belongs but not ok the other way around. Beginners may not be able to see this until after they think through it for a long time, which most of them including me wouldn't do. However, facet user guide doesn't explain the rationale clearly. * DocumentBuilder FacetSearchParams.addFacetRequest They no longer exist in lucene 4.2, but they are used in code examples. * FacetResultNode.getLabel(TaxonomyReader) It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests * ETC I don't know if there are other points to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.
[ https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620245#comment-13620245 ] crocket edited comment on LUCENE-4894 at 4/2/13 8:29 PM: - However, without facet user guide, I wouldn't have known that it ever existed. You may still need to advertise the facet module in http://lucene.apache.org/core/4_x_x/index.html It's good to leave an advertisement in the core index(?) page. was (Author: crocket): However, without facet user guide, I wouldn't have known that it ever existed. You may still need to advertise the facet module in http://lucene.apache.org/core/4_x_x/index.html Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations. Key: LUCENE-4894 URL: https://issues.apache.org/jira/browse/LUCENE-4894 Project: Lucene - Core Issue Type: Bug Components: general/website, modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Minor * Concurrent Indexing and Search There is no clear explanation regarding those points below. 1. TaxonomyReader should be reopened after IndexReader. 2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter should be closed before IndexWriter. The rationale is that it's ok to see categories to which no document belongs but not ok the other way around. Beginners may not be able to see this until after they think through it for a long time, which most of them including me wouldn't do. However, facet user guide doesn't explain the rationale clearly. * DocumentBuilder FacetSearchParams.addFacetRequest They no longer exist in lucene 4.2, but they are used in code examples. * FacetResultNode.getLabel(TaxonomyReader) It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests * ETC I don't know if there are other points to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
Re: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing
Hi Uwe, Thanks for the update. That is good to know. The bulk of the credit goes to Bengt who did the initial diagnosis and the prototype fix. Thanks also for walking me through how to reproduce the issue. Once the magic formula for the proxy was found - your instructions were spot on. The tests were awesome as marking stress tests and uncovered several issues associated with concurrent marking overflows. I've added them to the set of tests I run for marking changes. :) Cheers, JohnC On 4/2/2013 12:16 PM, Uwe Schindler wrote: Hi John, today I installed JDK8 b83 on one of the Jenkins build servers used by Apache Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So I was able to re-enable 32 bit builds without the extra workaround stacksize option again. Thanks for fixing this issue. Uwe - Uwe Schindler uschind...@apache.org Apache Lucene PMC Member / Committer Bremen, Germany http://lucene.apache.org/ -Original Message- From: hotspot-gc-dev-boun...@openjdk.java.net [mailto:hotspot-gc-dev- boun...@openjdk.java.net] On Behalf Of john.cuthbert...@oracle.com Sent: Tuesday, March 19, 2013 2:21 AM To: hotspot-gc-...@openjdk.java.net Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing Changeset: fa08949fe0cb Author:johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot- gc/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
SOLR - 1093
Hello Committers, I had submitted a patch to the SOLR - 1093 long back and I havent gotten any feedback on the same. [ https://issues.apache.org/jira/browse/SOLR-1093 ] We have been using it in our company and the feature has been very useful. I see other people using it too. If someone can look at it and provide a feedback, it would be really helpful! Thank you, Karthick
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620263#comment-13620263 ] Mark Miller commented on SOLR-4662: --- the solrcloud host is trouble spot - it will generally be different for each node - if this goes in zk, that type of config is still a problem - you have to use sys prop substitution and require system properties for setting these particular settings. I'm fine with that - I think you can still easily setup a prop file that gets auto sucked in for sys prop substitution as well. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-1093) A RequestHandler to run multiple queries in a batch
[ https://issues.apache.org/jira/browse/SOLR-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620283#comment-13620283 ] David Smiley commented on SOLR-1093: -1 If this issue is strictly about a feature in which a batch of queries are fully known at the time of submission, then I don't think this should be accepted for inclusion in Solr; sorry. Simply submit them in parallel. Instead, I am highly in favor of a scripting request handler in which a script runs that submits the searches to Solr (in-VM) and can react to the results of one request before making another that is formulated dynamically, and can assemble the response data, potentially reducing both the latency and data that would move over the wire if this feature didn't exist. And if you *really* were bent on submitting a batch of queries that are returned in a batch, then you could implement that with the script. A RequestHandler to run multiple queries in a batch --- Key: SOLR-1093 URL: https://issues.apache.org/jira/browse/SOLR-1093 Project: Solr Issue Type: New Feature Components: search Reporter: Noble Paul Assignee: Simon Willnauer Attachments: SOLR-1093.patch It is a common requirement that a single page requires to fire multiple queries .In cases where these queries are independent of each other. If there is a handler which can take in multiple queries , run them in paralll and send the response as one big chunk it would be useful Let us say the handler is MultiRequestHandler {code} requestHandler name=/multi class=solr.MultiRequestHandler/ {code} h2.Query Syntax The request must specify the no:of queries as count=n Each request parameter must be prefixed with a number which denotes the query index.optionally ,it may can also specify the handler name. example {code} /multi?count=21.handler=/select1.q=a:b2.handler=/select2.q=a:c {code} default handler can be '/select' so the equivalent can be {code} /multi?count=21.q=a:b2.q=a:c {code} h2.The response The response will be a ListNamedList where each NamedList will be a response to a query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620302#comment-13620302 ] Yago Riveiro commented on SOLR-4584: Only with Tomcat 7.0.35 Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620312#comment-13620312 ] Uwe Schindler commented on SOLR-4584: - Did you check with latest Tomcat 7.0? The used one 7.0..35 is no longer the actual one and there were some fixes regard chunked request encoding since 7.0.35, see: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html It would be good if you could try to reproduce this with the Jetty webserver shipped together with Solr. Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620321#comment-13620321 ] Yago Riveiro commented on SOLR-4584: Tomorrow I will try to upgrade to the last version of tomcat. I will pull some data from production and set up a SolrCluster with Jetty on my local environment to try replicate it. Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620327#comment-13620327 ] Uwe Schindler commented on SOLR-4584: - As said before, if you can reporduce with latest Tomcat, please also use the included Jetty webserver (java -jar start.jar inside example folder) to run Solr. If this fixes the bug, there is a chunked encoding issue in Tomcat that may need further investigation. Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620360#comment-13620360 ] Hoss Man commented on SOLR-4661: Some more (manual) experimentation (doing empty commits, or commits with openSearcher=false on the master, triggering slave replication to get the slave ahead and then doing subsequent changes on master replicating again) seems to confirm that this situation doesn't cause any actual problem in replication -- just confusion when looking at the replication details. we can add automated tests for this type of situation to future proof ourselves against the risk that something like this causes problems w/replication in the future, but let's do that in SOLR-4629 ... i think the crux of this issue is really one of mitigating user confusion. I suggest we update the admin UI to de-emphasize the comparison of the slave(version+generation) to master(version+generation), and instead emphasize a comparison of the slave(version+generation) with the master(replicateableVersion+replicatableGeneration). replicatableGeneration is already available in the details, we should be able to add replicatableVersion easy enough. Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser
[ https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620375#comment-13620375 ] Jan Høydahl commented on SOLR-4646: --- Wait a minute - I'd argue that the default here should be false and we should change the code? An example is that in Norwegian language, the word and means duck, the word or means alder and not means seine. The same may be true for many other languages, and requiring uppercase operators by default makes perfect sense. lowercaseOperators is enabled by default for edismax query parser - Key: SOLR-4646 URL: https://issues.apache.org/jira/browse/SOLR-4646 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 4.1, 4.2 Reporter: Alexander Koval [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators] says: *lowercaseOperators* This param controls whether to try to interpret lowercase words as boolean operators such as and, not and or. Set {{lowercaseOperators=true}} to allow this. Default is {{*false*}}. But in fact {{lowercaseOperators=true}} by default. And if one of boolean operators in lowercase is present in query it turns off {{mm}} parameter: * {{q=Young+6+or+AristondefType=edismaxqf=namemm=100%25debugQuery=true}} {{parsedquery_toString: +((name:young) (name:6) (name:ariston))}} * {{q=Young+6+or+AristondefType=edismaxqf=namemm=100%25lowercaseOperators=truedebugQuery=true}} {{parsedquery_toString: +(((name:young) (name:6) (name:ariston))~3)}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
[ https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-4652: Attachment: SOLR-4652.patch Hi Ryan, I reviewed your patch, which unfortunately did no longer apply to trunk, because there were changes in CoreContainer. As your patch was no SVN patch, my client was not able to download the correct SVN revision number for your patch, so I had to try out. I was then able to upgrade to latest Solr trunk. It would be better to supply Subversion patches in the future, because they contain the metadata required to correctly apply the patches. At least mention the revision number in SVN it was created against. I reverted the changes in import statements and in your test I used assertSame() instead of assertEquals(), because the classloader must be the same (==) not equal ones. I will commit this soon, once all tests passed. Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory) Key: SOLR-4652 URL: https://issues.apache.org/jira/browse/SOLR-4652 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Ryan Ernst Assignee: Uwe Schindler Fix For: 4.3, 5.0 Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch I have the following scenario: MyShardHandlerFactory is plugged in via solr.xml. The jar containing MyShardHandlerFactory is in the shared lib dir. There are a couple issues: 1. From within a per core handler (that is loaded within the core's lib dir), you grab the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results in a ClassCastException with a message like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory. 2. Adding a custom dir for shared lib (for example mylib) does not work. The ShardHandlerFactory is initialized before sharedLib is loaded. I've been pouring through the code on this and I don't see an easy fix. I'll keep looking at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix. IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml, a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config, and a great grandchild for per core lib dir based plugins). Right now there are some siblings, because any place a SolrResourceLoader is created with a null parent classloader, it gets the jetty thread's classloader as the parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620415#comment-13620415 ] Jan Høydahl commented on SOLR-4653: --- [~dweiss] logging proposal is ok. However, a better way would be to fail hard (can be made back-compat by checking luceneMatchVersion and log only for 4.3). In that case how we include contrib libs should change somehow. Perhaps something like this: {code} lib${solr.contrib.root}/extraction/lib/lib {code} If user supplies -Dsolr.contrib.root=/path/to/contrib then stuff will work. If nothing is passed by opts we could default to something that would work for the shipped example config. Also see my proposal in SOLR-4495. For most of my multi-core deploys I don't bother adding lib entries to all cores, but use a single sharedLib=$\{solr.solr.home\}/lib in solr.xml. Allowing multiple sharedLib dirs in solr.xml would allow for more flexible config. Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Resolved] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
[ https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-4652. - Resolution: Fixed Committed to trunk and 4.x Will be released with Lucene/Solr 4.3. Thanks Ryan, I hope we can fix the remaining issues with chaining of classloaders (disallowing null/context class loader as default classloader, using webapp classloader instead of context one)! Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory) Key: SOLR-4652 URL: https://issues.apache.org/jira/browse/SOLR-4652 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Ryan Ernst Assignee: Uwe Schindler Fix For: 4.3, 5.0 Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch I have the following scenario: MyShardHandlerFactory is plugged in via solr.xml. The jar containing MyShardHandlerFactory is in the shared lib dir. There are a couple issues: 1. From within a per core handler (that is loaded within the core's lib dir), you grab the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results in a ClassCastException with a message like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory. 2. Adding a custom dir for shared lib (for example mylib) does not work. The ShardHandlerFactory is initialized before sharedLib is loaded. I've been pouring through the code on this and I don't see an easy fix. I'll keep looking at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix. IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml, a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config, and a great grandchild for per core lib dir based plugins). Right now there are some siblings, because any place a SolrResourceLoader is created with a null parent classloader, it gets the jetty thread's classloader as the parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4495) solr.xml sharedLib attribtue should take a list of paths
[ https://issues.apache.org/jira/browse/SOLR-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620418#comment-13620418 ] Uwe Schindler commented on SOLR-4495: - Another idea (brought up in SOLR-4653) is the use of a better glob pattern syntax. My idea was to use similar approach like ANT's fileset/classpath definitions. We can use plexus-utils-1.1.jar, which provides DirectoryScanner that understands patterns like {{\*\*/\*.jar}}. Also your patch is now outdated after SOLR-4652: You should not create a ClassLoader at all, but instead add the components of classpath to the shared ResourceLoader using addToClassPath(). See the changes in SOLR-4652. solr.xml sharedLib attribtue should take a list of paths Key: SOLR-4495 URL: https://issues.apache.org/jira/browse/SOLR-4495 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Jan Høydahl Labels: classpath, solr.xml Fix For: 4.3 Attachments: SOLR-4495.patch solr.xml's sharedLib is a great way to add plugins that should be shared across all cores/collections. For increased flexibility I would like for it to take a list of paths. Then I'd put Solr's own contrib libs in one shared folder solrJars and custom plugins with deps in another customerJars. That eases Solr upgrades, then we can simply wipe and replace all jars in solrJars during upgrade. I realize that solr.xml is going away, and so the same request will be valid for whatever replaces solr.xml, whether it be system prop or properties file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4408) Server hanging on startup
[ https://issues.apache.org/jira/browse/SOLR-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620438#comment-13620438 ] Erick Erickson commented on SOLR-4408: -- I'm a little confused as to the status of this. Francios-Xavier says the he just tested the fix, but I'm not clear whether it's SOLR-4400 or the patch that Raintung put up. If it was SOLR-4400 then I'll close this JIRA. Thanks, Erick Server hanging on startup - Key: SOLR-4408 URL: https://issues.apache.org/jira/browse/SOLR-4408 Project: Solr Issue Type: Bug Affects Versions: 4.1 Environment: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode) Tomcat 7.0 Eclipse Juno + WTP Reporter: Francois-Xavier Bonnet Assignee: Erick Erickson Fix For: 4.3 Attachments: patch-4408.txt While starting, the server hangs indefinitely. Everything works fine when I first start the server with no index created yet but if I fill the index then stop and start the server, it hangs. Could it be a lock that is never released? Here is what I get in a full thread dump: 2013-02-06 16:28:52 Full thread dump OpenJDK 64-Bit Server VM (23.2-b09 mixed mode): searcherExecutor-4-thread-1 prio=10 tid=0x7fbdfc16a800 nid=0x42c6 in Object.wait() [0x7fbe0ab1] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc34c1c48 (a java.lang.Object) at java.lang.Object.wait(Object.java:503) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492) - locked 0xc34c1c48 (a java.lang.Object) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247) at org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:94) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:213) at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:112) at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816) at org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64) at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1594) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) coreLoadExecutor-3-thread-1 prio=10 tid=0x7fbe04194000 nid=0x42c5 in Object.wait() [0x7fbe0ac11000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc34c1c48 (a java.lang.Object) at java.lang.Object.wait(Object.java:503) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492) - locked 0xc34c1c48 (a java.lang.Object) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247) at org.apache.solr.handler.ReplicationHandler.getIndexVersion(ReplicationHandler.java:495) at org.apache.solr.handler.ReplicationHandler.getStatistics(ReplicationHandler.java:518) at org.apache.solr.core.JmxMonitoredMap$SolrDynamicMBean.getMBeanInfo(JmxMonitoredMap.java:232) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512) at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:140) at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:51) at org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:636) at org.apache.solr.core.SolrCore.init(SolrCore.java:809) at org.apache.solr.core.SolrCore.init(SolrCore.java:607) at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1003) at
[jira] [Assigned] (SOLR-3900) LogWatcher Config Not Persisted
[ https://issues.apache.org/jira/browse/SOLR-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-3900: Assignee: (was: Erick Erickson) I'm not going to be able to work on this, plus I only took it because I was in the code, plus logging is currently changing so I'll leave it to more ambitious souls. FWIW, solr.xml is making a resurgence so if Michael wants to pick it back up that'd be great! LogWatcher Config Not Persisted Key: SOLR-3900 URL: https://issues.apache.org/jira/browse/SOLR-3900 Project: Solr Issue Type: Bug Components: multicore Reporter: Michael Garski Priority: Minor Fix For: 4.3 When the solr.xml file is set to persistent=true, the logging element that contains the LogWatcher configuration is not persisted to the new solr.xml file that is written when managing the cores via core admin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
4.2.1 - Maven?
Hi Mark, I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, but is not yet on Maven Central. Do you plan on handling publishing to Maven? If not, or if you'd rather somebody else did it, I can do it. Steve On Apr 2, 2013, at 10:36 AM, markrmil...@apache.org wrote: Author: markrmiller Date: Tue Apr 2 14:35:39 2013 New Revision: 1717 Log: Publish Lucene and Solr 4.2.1 release artifacts Added: release/lucene/java/4.2.1/ release/lucene/java/4.2.1/KEYS.txt (with props) release/lucene/java/4.2.1/changes/ release/lucene/java/4.2.1/changes/Changes.html (with props) release/lucene/java/4.2.1/changes/ChangesFancyStyle.css release/lucene/java/4.2.1/changes/ChangesFixedWidthStyle.css release/lucene/java/4.2.1/changes/ChangesSimpleStyle.css release/lucene/java/4.2.1/lucene-4.2.1-src.tgz (with props) release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.asc release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.md5 release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.sha1 release/lucene/java/4.2.1/lucene-4.2.1.tgz (with props) release/lucene/java/4.2.1/lucene-4.2.1.tgz.asc release/lucene/java/4.2.1/lucene-4.2.1.tgz.md5 release/lucene/java/4.2.1/lucene-4.2.1.tgz.sha1 release/lucene/java/4.2.1/lucene-4.2.1.zip (with props) release/lucene/java/4.2.1/lucene-4.2.1.zip.asc release/lucene/java/4.2.1/lucene-4.2.1.zip.md5 release/lucene/java/4.2.1/lucene-4.2.1.zip.sha1 release/lucene/solr/4.2.1/ release/lucene/solr/4.2.1/KEYS.txt (with props) release/lucene/solr/4.2.1/changes/ release/lucene/solr/4.2.1/changes/Changes.html (with props) release/lucene/solr/4.2.1/changes/ChangesFancyStyle.css release/lucene/solr/4.2.1/changes/ChangesFixedWidthStyle.css release/lucene/solr/4.2.1/changes/ChangesSimpleStyle.css release/lucene/solr/4.2.1/solr-4.2.1-src.tgz (with props) release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.asc release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.md5 release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.sha1 release/lucene/solr/4.2.1/solr-4.2.1.tgz (with props) release/lucene/solr/4.2.1/solr-4.2.1.tgz.asc release/lucene/solr/4.2.1/solr-4.2.1.tgz.md5 release/lucene/solr/4.2.1/solr-4.2.1.tgz.sha1 release/lucene/solr/4.2.1/solr-4.2.1.zip (with props) release/lucene/solr/4.2.1/solr-4.2.1.zip.asc release/lucene/solr/4.2.1/solr-4.2.1.zip.md5 release/lucene/solr/4.2.1/solr-4.2.1.zip.sha1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 4.2.1 - Maven?
I ran a couple of the initial things this morning (the script that pulls everything down), but I've been busy since then. I do intend to do it, but would appreciate the help anyhow if you are up for it. Robert once told me if I ever publish anything wrong to maven central, I don't really get a redo :) There are still a handful of things I need to get to - was hoping to start on that tonight if I don't pass out first and finish tomorrow. A lack of sleep mixed with an exercise restart has been catching up to me. - Mark On Apr 2, 2013, at 8:48 PM, Steve Rowe sar...@gmail.com wrote: Hi Mark, I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, but is not yet on Maven Central. Do you plan on handling publishing to Maven? If not, or if you'd rather somebody else did it, I can do it. Steve On Apr 2, 2013, at 10:36 AM, markrmil...@apache.org wrote: Author: markrmiller Date: Tue Apr 2 14:35:39 2013 New Revision: 1717 Log: Publish Lucene and Solr 4.2.1 release artifacts Added: release/lucene/java/4.2.1/ release/lucene/java/4.2.1/KEYS.txt (with props) release/lucene/java/4.2.1/changes/ release/lucene/java/4.2.1/changes/Changes.html (with props) release/lucene/java/4.2.1/changes/ChangesFancyStyle.css release/lucene/java/4.2.1/changes/ChangesFixedWidthStyle.css release/lucene/java/4.2.1/changes/ChangesSimpleStyle.css release/lucene/java/4.2.1/lucene-4.2.1-src.tgz (with props) release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.asc release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.md5 release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.sha1 release/lucene/java/4.2.1/lucene-4.2.1.tgz (with props) release/lucene/java/4.2.1/lucene-4.2.1.tgz.asc release/lucene/java/4.2.1/lucene-4.2.1.tgz.md5 release/lucene/java/4.2.1/lucene-4.2.1.tgz.sha1 release/lucene/java/4.2.1/lucene-4.2.1.zip (with props) release/lucene/java/4.2.1/lucene-4.2.1.zip.asc release/lucene/java/4.2.1/lucene-4.2.1.zip.md5 release/lucene/java/4.2.1/lucene-4.2.1.zip.sha1 release/lucene/solr/4.2.1/ release/lucene/solr/4.2.1/KEYS.txt (with props) release/lucene/solr/4.2.1/changes/ release/lucene/solr/4.2.1/changes/Changes.html (with props) release/lucene/solr/4.2.1/changes/ChangesFancyStyle.css release/lucene/solr/4.2.1/changes/ChangesFixedWidthStyle.css release/lucene/solr/4.2.1/changes/ChangesSimpleStyle.css release/lucene/solr/4.2.1/solr-4.2.1-src.tgz (with props) release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.asc release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.md5 release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.sha1 release/lucene/solr/4.2.1/solr-4.2.1.tgz (with props) release/lucene/solr/4.2.1/solr-4.2.1.tgz.asc release/lucene/solr/4.2.1/solr-4.2.1.tgz.md5 release/lucene/solr/4.2.1/solr-4.2.1.tgz.sha1 release/lucene/solr/4.2.1/solr-4.2.1.zip (with props) release/lucene/solr/4.2.1/solr-4.2.1.zip.asc release/lucene/solr/4.2.1/solr-4.2.1.zip.md5 release/lucene/solr/4.2.1/solr-4.2.1.zip.sha1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
[ https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620470#comment-13620470 ] Ryan Ernst commented on SOLR-4652: -- Thanks Uwe! I've disabled the auto reorder imports feature from IntelliJ, so that should be better in future patches. I will also make sure to figure out the svn revision or use an svn checkout. Sorry about the hassle! I'm hoping to tackle refactoring of the shard handler factory stuff next, but then coming back to classloader chaining is a possibility. As I said before, I did start down that road...it is just a doozy. It is pretty straightforward until you get to ZkSolrResourceLoader, then it seemed to get complicated (I stopped there, so I am not sure if there is an easy path there). Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory) Key: SOLR-4652 URL: https://issues.apache.org/jira/browse/SOLR-4652 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Ryan Ernst Assignee: Uwe Schindler Fix For: 4.3, 5.0 Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch I have the following scenario: MyShardHandlerFactory is plugged in via solr.xml. The jar containing MyShardHandlerFactory is in the shared lib dir. There are a couple issues: 1. From within a per core handler (that is loaded within the core's lib dir), you grab the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results in a ClassCastException with a message like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory. 2. Adding a custom dir for shared lib (for example mylib) does not work. The ShardHandlerFactory is initialized before sharedLib is loaded. I've been pouring through the code on this and I don't see an easy fix. I'll keep looking at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix. IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml, a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config, and a great grandchild for per core lib dir based plugins). Right now there are some siblings, because any place a SolrResourceLoader is created with a null parent classloader, it gets the jetty thread's classloader as the parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
[ https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620471#comment-13620471 ] Mark Miller commented on SOLR-4652: --- bq. ZkSolrResourceLoader If you fill me in, I can probably help. ZkSolrResourceLoader should be pretty simple - it's intent is simply to load from zk if possible before following back to how SolrResourceLoader would load - essentially. Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory) Key: SOLR-4652 URL: https://issues.apache.org/jira/browse/SOLR-4652 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Ryan Ernst Assignee: Uwe Schindler Fix For: 4.3, 5.0 Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch I have the following scenario: MyShardHandlerFactory is plugged in via solr.xml. The jar containing MyShardHandlerFactory is in the shared lib dir. There are a couple issues: 1. From within a per core handler (that is loaded within the core's lib dir), you grab the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results in a ClassCastException with a message like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory. 2. Adding a custom dir for shared lib (for example mylib) does not work. The ShardHandlerFactory is initialized before sharedLib is loaded. I've been pouring through the code on this and I don't see an easy fix. I'll keep looking at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix. IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml, a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config, and a great grandchild for per core lib dir based plugins). Right now there are some siblings, because any place a SolrResourceLoader is created with a null parent classloader, it gets the jetty thread's classloader as the parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
[ https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620471#comment-13620471 ] Mark Miller edited comment on SOLR-4652 at 4/3/13 1:06 AM: --- bq. ZkSolrResourceLoader If you fill me in, I can probably help. ZkSolrResourceLoader should be pretty simple - it's intent is simply to load from zk if possible before falling back to how SolrResourceLoader would load - essentially. was (Author: markrmil...@gmail.com): bq. ZkSolrResourceLoader If you fill me in, I can probably help. ZkSolrResourceLoader should be pretty simple - it's intent is simply to load from zk if possible before following back to how SolrResourceLoader would load - essentially. Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory) Key: SOLR-4652 URL: https://issues.apache.org/jira/browse/SOLR-4652 Project: Solr Issue Type: Bug Affects Versions: 4.2 Reporter: Ryan Ernst Assignee: Uwe Schindler Fix For: 4.3, 5.0 Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch I have the following scenario: MyShardHandlerFactory is plugged in via solr.xml. The jar containing MyShardHandlerFactory is in the shared lib dir. There are a couple issues: 1. From within a per core handler (that is loaded within the core's lib dir), you grab the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results in a ClassCastException with a message like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory. 2. Adding a custom dir for shared lib (for example mylib) does not work. The ShardHandlerFactory is initialized before sharedLib is loaded. I've been pouring through the code on this and I don't see an easy fix. I'll keep looking at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix. IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml, a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config, and a great grandchild for per core lib dir based plugins). Right now there are some siblings, because any place a SolrResourceLoader is created with a null parent classloader, it gets the jetty thread's classloader as the parent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4629) Stronger standard replication testing.
[ https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4629: --- Attachment: SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch [~markrmil...@gmail.com]: can you please sanity check this patch for me? The initial motivation was adding testEmptyCommits to help verify that the situation observed in SOLR-4661 didn't actually cause any problems. Since a key point of the new test was to ensure that replication happened even if no new docs were added by a commit, i couldn't rely on the existing hack of rQuery, so i added a wait option to command=fetchindex that causes the command request to block until the Thread running doFetch finishes (here's where my first concern is: is having this option a bad idea? should we document it or keep it hidden for tests?) since i was looking at rQuery, i noticed it was sleeping at least 100ms on every call, even if the results were already available, so i reworked that a bit, and in the process refactored a numFound helper utility. Assuming this patch -- in particular the wait option on fetch index -- seems ok to folks, i think we could probably speed up TestReplicationhandler considerably by changing all of the individual tests to explicitly call pullFromMasterToSlave() instead of using rQuery to wait for polling ... it seems like we should really only need a single test of the polling feature, everything else being tested can be verified with blocking calls to command=fetchindex ... right? Stronger standard replication testing. -- Key: SOLR-4629 URL: https://issues.apache.org/jira/browse/SOLR-4629 Project: Solr Issue Type: Test Components: replication (java) Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0, 4.2.1 Attachments: SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch I added to these tests recently, but there is a report on the list indicating we may still be missing something. Most reports have been positive so far after the 4.2 fixes, but I'd feel better after adding some more testing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
Re: 4.2.1 - Maven?
Hi Mark, On Apr 2, 2013, at 9:00 PM, Mark Miller markrmil...@gmail.com wrote: I ran a couple of the initial things this morning (the script that pulls everything down), but I've been busy since then. I do intend to do it, but would appreciate the help anyhow if you are up for it. Robert once told me if I ever publish anything wrong to maven central, I don't really get a redo :) Sure, I'll get started on Maven publishing. There are still a handful of things I need to get to - was hoping to start on that tonight if I don't pass out first and finish tomorrow. A lack of sleep mixed with an exercise restart has been catching up to me. Take care of yourself :). Thanks for making the release! On Apr 2, 2013, at 8:48 PM, Steve Rowe sar...@gmail.com wrote: I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, but is not yet on Maven Central. Do you plan on handling publishing to Maven? If not, or if you'd rather somebody else did it, I can do it. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.
[ https://issues.apache.org/jira/browse/SOLR-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620485#comment-13620485 ] Ryan Ernst commented on SOLR-4663: -- +1 to failing to startup in this serious misconfiguration. Log an error if more than one core points to the same data dir. --- Key: SOLR-4663 URL: https://issues.apache.org/jira/browse/SOLR-4663 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor In large multi-core setups, having mistakes whereby two or more cores point to the same data dir seems quite possible. We should at least complain very loudly in the logs if this is detected. Should be a very straightforward check at core discovery time. Is this serious enough to keep Solr from coming up at all? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4629) Stronger standard replication testing.
[ https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620493#comment-13620493 ] Mark Miller commented on SOLR-4629: --- Looks good to me. bq. is having this option a bad idea? should we document it or keep it hidden for tests? It seems fine to me, but it seems safer to not advertise initially. No demand yet anyway. I'd doc it as subject to change and unsupported myself. bq. i think we could probably speed up TestReplicationhandler +1 Stronger standard replication testing. -- Key: SOLR-4629 URL: https://issues.apache.org/jira/browse/SOLR-4629 Project: Solr Issue Type: Test Components: replication (java) Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.3, 5.0, 4.2.1 Attachments: SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch I added to these tests recently, but there is a report on the list indicating we may still be missing something. Most reports have been positive so far after the 4.2 fixes, but I'd feel better after adding some more testing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
Re: 4.2.1 - Maven?
On Apr 2, 2013, at 9:19 PM, Steve Rowe sar...@gmail.com wrote: Sure, I'll get started on Maven publishing. This is done. Should be on Maven Central in a couple of hours or so. Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4473) Reloading a core will not close (leak) associated DIH JDBC connection
[ https://issues.apache.org/jira/browse/SOLR-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620602#comment-13620602 ] Alexandre Rafalovitch commented on SOLR-4473: - You are right. And, of course, there is no standard way to call that shutdown method. Which means it is not safe to use embedded Derby. Unfortunately, there seem to be no way to use networked Derby either (unless I missed something in my test). After I change the URL and start network server, I get: {noformat} Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: select * from ALERTS Processing Document # 4 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:253) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38) at org.apache.solr.handler.dataimport.DebugLogger$2.getData(DebugLogger.java:188) at org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:404) ... 35 more Caused by: java.lang.NullPointerException at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:241) ... 43 more {noformat} Using the same URL from the command line works however. It seems that jdbc driver just cannot get the connection for whatever reason. I added client libraries and all, but it does not seem to help. And I haven't figured out how to connect to DIH in debug mode yet. Reloading a core will not close (leak) associated DIH JDBC connection - Key: SOLR-4473 URL: https://issues.apache.org/jira/browse/SOLR-4473 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.1 Reporter: Alexandre Rafalovitch Fix For: 4.3 I have DIH configured with Derby database. After I start Solr, I can run DIH import fine. After I reload the core, DIH can no longer run with the following message (excerpts): ... EVERE: Exception while processing: vac document : SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: select * from ALERTS Processing Document # 1 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:253) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38) at org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465) Caused by: java.sql.SQLException: Another instance of Derby may have already booted the database PATH. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619582#comment-13619582 ] Shai Erera commented on LUCENE-4897: I think that we should use a primitive iterator, e.g. facet collections have IntIterator interface. And so the method should be something like {{IntIterator getChildren(int ordinal)}}? Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.
[ https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619583#comment-13619583 ] Shai Erera commented on LUCENE-4894: The userguide is seriously outdated after all the recent refactoring. I was wondering if we should keep it at all, or rather include a high-level documentation under o.a.l.facet.package.html which covers the basic points, and then focus on maintaining good javadocs at the classes / packages level. It gets harder to maintain these documents ... Nevertheless, if you want to take a crack at improving / fixing it, I will help you get it in. Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations. Key: LUCENE-4894 URL: https://issues.apache.org/jira/browse/LUCENE-4894 Project: Lucene - Core Issue Type: Bug Components: general/website, modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Minor * Concurrent Indexing and Search There is no clear explanation regarding those points below. 1. TaxonomyReader should be reopened after IndexReader. 2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter should be closed before IndexWriter. The rationale is that it's ok to see categories to which no document belongs but not ok the other way around. Beginners may not be able to see this until after they think through it for a long time, which most of them including me wouldn't do. However, facet user guide doesn't explain the rationale clearly. * DocumentBuilder FacetSearchParams.addFacetRequest They no longer exist in lucene 4.2, but they are used in code examples. * FacetResultNode.getLabel(TaxonomyReader) It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests * ETC I don't know if there are other points to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619585#comment-13619585 ] Shai Erera commented on LUCENE-4858: Adrien, let's keep this issue focused on the Collector working in conjunction with SortingMP. I think the added info to diagnostics is important, to prevent users tripping themselves. Let's also add the Sorter ID/Key, as another way to make the collector robust. We can deal w/ addIndexes later. If it will be modified to use MP, we'll get that support for free; if not, we'll think about what we need to do. Early termination with SortingMergePolicy - Key: LUCENE-4858 URL: https://issues.apache.org/jira/browse/LUCENE-4858 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.3 Attachments: LUCENE-4858.patch, LUCENE-4858.patch Spin-off of LUCENE-4752, see https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565 and https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282 When an index is sorted per-segment, queries that sort according to the index sort order could be early terminated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.
[ https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619601#comment-13619601 ] crocket commented on LUCENE-4894: - Including documentations in javadocs might do the job. Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations. Key: LUCENE-4894 URL: https://issues.apache.org/jira/browse/LUCENE-4894 Project: Lucene - Core Issue Type: Bug Components: general/website, modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Minor * Concurrent Indexing and Search There is no clear explanation regarding those points below. 1. TaxonomyReader should be reopened after IndexReader. 2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter should be closed before IndexWriter. The rationale is that it's ok to see categories to which no document belongs but not ok the other way around. Beginners may not be able to see this until after they think through it for a long time, which most of them including me wouldn't do. However, facet user guide doesn't explain the rationale clearly. * DocumentBuilder FacetSearchParams.addFacetRequest They no longer exist in lucene 4.2, but they are used in code examples. * FacetResultNode.getLabel(TaxonomyReader) It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests * ETC I don't know if there are other points to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602 ] crocket commented on LUCENE-4897: - I don't know much about IntIterator, but I surmise it'd do the job. Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602 ] crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM: - I don't know much about IntIterator, but I surmise it'll do. was (Author: crocket): I don't know much about IntIterator, but I surmise it'd do. Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602 ] crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM: - I don't know much about IntIterator, but I surmise it'd do. was (Author: crocket): I don't know much about IntIterator, but I surmise it'd do the job. Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602 ] crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM: - I don't know much about IntIterator, but I surmise it'll do good enough. was (Author: crocket): I don't know much about IntIterator, but I surmise it'll suffice. Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602 ] crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM: - I don't know much about IntIterator, but I surmise it'll suffice. was (Author: crocket): I don't know much about IntIterator, but I surmise it'll do. Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
How to consume DocTermOrds for MultiValuedFields
final DocTermOrds docTermOrds = FieldCache.DEFAULT.getDocTermOrds(atomicReader, multiValuedField); final TermsEnum termsEnum = docTermOrds.getOrdTermsEnum(atomicReader); DocTermOrds.TermOrdsIterator reuse = docTermOrds.lookup(doc, reuse); int[] buffer = new int[5]; StringBuilder indexedFieldValue = new StringBuilder(); do { int chunk = reuse.read(buffer); for (int idx = 0; idx chunk; idx++) { int key = buffer[idx]; termsEnum.seekExact((long) key); String fieldValue = termsEnum.term().utf8ToString(); indexedFieldValue.append(fieldValue); } //Match indexedFieldValue here } while((chunk = buffer.length)); This is how I am am consuming DocTermOrds. Doing this gives me all the unique tokens across all the values in the multiValuedField for that document. How can I get each of the values in the field individually? Is there any other cache impl. where I can -- Regards, Varun Thacker http://www.vthacker.in/
[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619728#comment-13619728 ] Erick Erickson commented on SOLR-4662: -- I may actually have some time on some long flights to work on this, I'd really like to nail this and get it _over_. So I'd like to get the design agreed so I don't have to re-do the re-done. It seems like the root issue here is that we have this configuration file that is trying to serve too many purposes. It started as a way to get basic configuration information back in the single-core days. Then it morphed into a place to get all the core information. Then it morphed into a place where we could specify a bunch of SolrCloud parameters. Then it morphed into a place to not really get core information but specify that that info get discovered. Now, with SolrCloud one question is whether we should even have it or should all this info be stored in Zookeeper. Having local files around that you have to have on each node before starting solr seems counter to having configurations managed by ZK. Straw-man proposal: So, what if we allow a SolrConfigurationProvider? Specifying none or the default we'll provide does just what happens now. It seems like the other stock one we could supply is one that reads the info from ZK. Don't know what else is out there, but that's just the point. People could plug in something that read their DB, something that read a properties file G. Whatever. There's a start on what the interface would look like here in ConfigSolr, which I pulled out when trying to make a properties file. I doubt it's entirely complete, but should be a pretty good start. Maybe this becomes an option on the command line? e.g. -Dsolr.configProvider=org.solr.core.XmlConfigProvider as the default? And if -DzkHost=url to zk is provided, default to -Dsolr.configProvider=org.solr.core.ZkConfigProvider? It seems like default behavior is then mostly a matter of which provider we use if none is specified. It'd be a pretty simple matter to switch between whether we use ZK or a solr.xml file based on whether we had a zkHost specified, and prefer the one that reads solr.xml in 4.x and the one that reads ZK in 5.x or whatever... Let me be the first to say that I have NOT thought this through very carefully, and note how I'm glossing over getting the appropriate info up into ZK in the first place. My purpose here is to get the discussion going, I don't particularly care if this approach is adopted or not. I _do_ care that whatever we decide on doesn't do another 180 turn... Let the discussion begin! Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4897) Add a sugar API for traversing categories.
[ https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4897: --- Labels: newdev (was: ) Add a sugar API for traversing categories. -- Key: LUCENE-4897 URL: https://issues.apache.org/jira/browse/LUCENE-4897 Project: Lucene - Core Issue Type: Improvement Components: modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Trivial Labels: newdev Mike McCandless said in lucene-java-user mailing list. Maybe we could add some simple sugar APIs? Eg something like CollectionCategoryPath getChildren(int parentOrd)? (Or maybe it returns IteratorCategoryPath?) What about CollectionInteger getChildren(int parentOrd)? Integer would be more versatile and can easily be converted to CategoryPath with TaxonomyReader.getPath. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.
[ https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619729#comment-13619729 ] Michael McCandless commented on LUCENE-4894: +1 to remove the userGuide and absorb it into javadocs. Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations. Key: LUCENE-4894 URL: https://issues.apache.org/jira/browse/LUCENE-4894 Project: Lucene - Core Issue Type: Bug Components: general/website, modules/facet Affects Versions: 4.2 Reporter: crocket Priority: Minor * Concurrent Indexing and Search There is no clear explanation regarding those points below. 1. TaxonomyReader should be reopened after IndexReader. 2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter should be closed before IndexWriter. The rationale is that it's ok to see categories to which no document belongs but not ok the other way around. Beginners may not be able to see this until after they think through it for a long time, which most of them including me wouldn't do. However, facet user guide doesn't explain the rationale clearly. * DocumentBuilder FacetSearchParams.addFacetRequest They no longer exist in lucene 4.2, but they are used in code examples. * FacetResultNode.getLabel(TaxonomyReader) It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests * ETC I don't know if there are other points to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-2412) Multipath hierarchical faceting
[ https://issues.apache.org/jira/browse/SOLR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated SOLR-2412: - Attachment: SOLR-2412.patch Improved base startup speed and added experimental optional high-speed high-mem structure builder. Patch only tested with Solr 4.0. Multipath hierarchical faceting --- Key: SOLR-2412 URL: https://issues.apache.org/jira/browse/SOLR-2412 Project: Solr Issue Type: New Feature Components: SearchComponents - other Affects Versions: 4.0 Environment: Fast IO when huge hierarchies are used Reporter: Toke Eskildsen Labels: contrib, patch Attachments: SOLR-2412.patch, SOLR-2412.patch, SOLR-2412.patch, SOLR-2412.patch, SOLR-2412.patch Hierarchical faceting with slow startup, low memory overhead and fast response. Distinguishing features as compared to SOLR-64 and SOLR-792 are * Multiple paths per document * Query-time analysis of the facet-field; no special requirements for indexing besides retaining separator characters in the terms used for faceting * Optional custom sorting of tag values * Recursive counting of references to tags at all levels of the output This is a shell around LUCENE-2369, making it work with the Solr API. The underlying principle is to reference terms by their ordinals and create an index wide documents to tags map, augmented with a compressed representation of hierarchical levels. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619777#comment-13619777 ] Dawid Weiss commented on SOLR-4653: --- Thanks for clarification, Hoss. What you say makes sense but the common practice seems to be that: * people modify the example's configuration files and overwrite them just because all the paths are relative from those directories and pointing at contribs, * when you want to create an isolate configuration and pass it to somebody to, say, run with -Dsolr.solr.home it's hard because you need to know absolute installation paths or make the user install that configuration in an exact folder under solr's unpacked structure. If they change anything -- boom, things don't work and nobody knows what's going on. I think the middle ground here is to at least log a warning when a fileset is empty (and provide the basedir against which it was resolved). This looks suspicious and provides enough information to recover from the problem. Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619784#comment-13619784 ] Mark Miller commented on SOLR-4662: --- Quick notes: I don't think it has really morphed. solr.xml has always been our only config file for the system or corecontainer level. Everything that has joined the corecontainer was added because it's not core level, and that's always been the role of solr.xml - home of the above SolrCore level. Let's talk about the overall strategy before we nail down the impl. IMO, solr.xml has a few issues: 1. It should not define cores. Solr should not have to write to this config file, and cores should be define by directory locations. 2. The SolrCloud params are all cores attributes, but they should be in a better structure, similar to the shard handler definition that can now live in solr.xml, and what we do in solrconfig.xml. 3. We should consider how most of the solr.xml config can live in ZooKeeper when in SolrCloud mode. Much of this is not something you want to have to tweak on every node - it's going to be the same - you generally want to set a zkClientTimeout for your collection, not for each node. Same for shard handler. I think it's worth forcing some consistency for all nodes, such as the same host context. It will also be possible to override those things per node with sys prop notation. zkHost could no longer be specified in solr.xml. So, I think we need to be able to detect and read the old solr.xml format some way (lot's of choices I think), as well as detect and read the new format (which will be very similar to the old). In 5 we stop supporting the old format. Example ships with the new format. In terms of impl, I think you are on the right track. I don't think we should expose any user plugins at this point though. That should be internal work. Let's decide if we should support arbitrary impls for users later. It has an ongoing cost, in this area in particular I think. I think we want to reserve all API rights here. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4656) Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting
[ https://issues.apache.org/jira/browse/SOLR-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619802#comment-13619802 ] Erick Erickson commented on SOLR-4656: -- Committed trunk: r - 1463543 Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting - Key: SOLR-4656 URL: https://issues.apache.org/jira/browse/SOLR-4656 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, SOLR-4656.patch, SOLR-4656-trunk.patch I'm looking at an admittedly pathological case of many, many entries in a multiValued field, and trying to implement a way to limit the number examined, analogous to maxAnalyzedChars, see the patch. Along the way, I noticed that we do what looks like unnecessary copying of the fields to be examined. We call Document.getFields, which copies all of the fields and values to the returned array. Then we copy all of those to another array, converting them to Strings. Then we actually examine them. a this doesn't seem very efficient and b reduces the benefit from limiting the number of mv values examined. So the attached does two things: 1 attempts to fix this 2 implements hl.maxMultiValuedToExamine I'd _really_ love it if someone who knows the highlighting code takes a peek at the fix to see if I've messed things up, the changes are actually pretty minimal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4881) Add a set iterator to SentinelIntSet
[ https://issues.apache.org/jira/browse/LUCENE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4881: - Summary: Add a set iterator to SentinelIntSet (was: Add a set iterator to SentinalIntSet) Add a set iterator to SentinelIntSet Key: LUCENE-4881 URL: https://issues.apache.org/jira/browse/LUCENE-4881 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.3 Attachments: LUCENE-4881_SentinalIntSet_int_iterator.patch, SentinelIntSet_docs.patch I'm working on code that needs a hash based int Set. It will need to iterate over the values, but SentinalIntSet doesn't have this utility feature. It should be pretty easy to add. FYI this is an out-growth of a question I posed to the dev list, examining 3 different int hash sets out there: SentinalIntSet, IntHashSet (in Lucene facet module) and the 3rd party IntOpenHashSet (HPPC) -- see http://lucene.472066.n3.nabble.com/IntHashSet-SentinelIntSet-SortedIntDocSet-td4037516.html I decided to go for SentinalIntSet because it's already in Lucene-core, adding the method I need should be easy, and it has a nice lean implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619866#comment-13619866 ] Mark Miller commented on SOLR-4662: --- So from my point of view: 1. is essentially done 2. is what we should tie up here, keeping in mind 3 3. we should make another jira issue and follow on with Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619867#comment-13619867 ] Shawn Heisey commented on SOLR-4662: I too think that solr.xml should not store cores. Auto-discovery is a nice thing, but it makes it more difficult to have a nice clean layout where the core configs and data are contained within separate subdirectories. I suppose that each autodiscovered core properties file could have a relative dataDir that goes up one or two directories, just like my current setup, and that might be good enough. I would also want to have something like a coreDirectory parameter, which I would set to cores so that the main solr.solr.home directory would be very clean. One option is to have a cores.xml file for more complex layouts where the user wants to specify everything. At first I thought about a cloud.xml file for SolrCloud properties, but once you start down the path of multiple config files, the explosion might never stop. Here's what things look like inside solr.xml on my setup that's not well suited for SolrCloud, and a snippet of the full directory structure. The full picture is more complex than this, with relative symlinks in conf directories and relative xinclude paths in solrconfig.xml, but this gives you the basic idea: {noformat} core loadOnStartup=true instanceDir=cores/inc_0/ transient=false name=inclive dataDir=../../data/inc_0/ core loadOnStartup=true instanceDir=cores/inc_1/ transient=false name=incbuild dataDir=../../data/inc_1/ ├── cores │ ├── inc_0 │ │ └── conf │ ├── inc_1 │ │ └── conf ├── data │ ├── inc_0 │ │ ├── index │ │ └── tlog │ ├── inc_1 │ │ ├── index │ │ └── tlog └── lib {noformat} I'm not sure there is a better location than solr.xml for zkHost, but I definitely think it should be in a config file. **Requiring** -DzkHost on startup is a bad idea - generic startup scripts become very difficult. Keeping all of the config after that in zookeeper is an idea that is growing on me, as long as the initial contact to zookeeper won't suffer from a low default client timeout before zkClientTimeout can be read. If you give Solr (or CloudSolrServer) only one of the hosts in your zookeeper ensemble (perhaps localhost:port/chroot) will it automatically configure itself with the entire ensemble? If not, is there a way to build this functionality in? The fact that Solr does not come equipped with instructions for a standalone zookeeper process or a functioning standalone zookeeper is problematic in my opinion. If I find some time, I can whip up a wiki page. I do wish zkcli.sh was more self-contained. I can eventually come up with a wiki page for that too. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619872#comment-13619872 ] Erick Erickson commented on SOLR-4662: -- H. Point taken about not exposing a pluggable version yet, now that you mention it that seems premature. Hardening all that before exposing something we then have to support makes sense. We can still program to the interface I mentioned as much as possible to make that easier in future but no big deal either way. 1 is done. 2 OK, what does that look like? Is this just a simple transformation like solr solrConfigFactory name=solrConfigFactory clase=SolrConfigFactory str name=persistent${solr.xml.persist:false}/str str name=adminPath/admin/cores/str str name=defaultCoreNamecollection1/str str name=host127.0.0.1/str str name=hostPort${hostPort:8983}/str str name=hostContext${hostContext:solr}/str str name=shareSchema${shareSchema:false}/str shardHandlerFactory name=shardHandlerFactory class=HttpShardHandlerFactory int name=socketTimeout${socketTimeout:12}/int int name=connTimeout${connTimeout:15000}/int /shardHandlerFactory str name=zkClientTimeout${solr.zkclienttimeout:3}/str str name=numShards${numShards:3}/str str name=distribUpdateConnTimeout${distribUpdateConnTimeout:15000}/str str name=distribUpdateSoTimeout${distribUpdateSoTimeout:12}/str /solrConfigFactory /solr This form doesn't allow cores to be here at all. Is there any necessity to have a factory here or are you thinking these should just be child nodes of solr? Would shardHandlerFactory be inside or outside the new factory? As you can tell, how all this fits together is something of a mystery to me. But having a solrConfigFactory node as the immediate child of solr and encompassing all the rest would allow easy detection of old -vs- new style XML. Adding a version attribute to the solr tag seems possible too, but I don't really like that, I think there's less user-level maintenance if we use solrConfigFactory, implementing up different handlers for different versions if/when we change again, which should be very rare. 3 On that note, it's not clear to me we need solr.xml at all in true cloud mode. In the absence of solr.xml but presence of zkHost, just get everything from ZK. Look, you know how ZK-ignorant I am, be gentle G. The rest of the time, anything you could possibly want from solr.xml that wasn't present, ask ZK for it and use defaults if neither source had it. By not present, that means neither in the solr.xml file nor as a sysprop. Along the way removing DEF_SOLR_XML from ConfigSolrXml would be a Good Thing maybe. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-4653: -- Attachment: SOLR-4653.patch This is my take at this having considered a few other alternatives. It logs this at startup currently: {code} Can't find (or read) directory to add to classloader: /total/crap/dir/ignored (resolved as: C:\Work\lucene-solr-svn\trunk\solr\example\solr\collection1\total\crap\dir\ignored). {code} And indeed the example config contains: {code} !-- If a 'dir' option (with or without a regex) is used and nothing is found that matches, it will be ignored -- lib dir=/total/crap/dir/ignored / {code} Perhaps the comment should be changed/ made more polite too. Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619876#comment-13619876 ] Dawid Weiss commented on SOLR-4653: --- If no objections I'll commit this in a few hours. Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-2412) Architecture Diagrams needed for Lucene, Solr and Nutch
[ https://issues.apache.org/jira/browse/LUCENE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619890#comment-13619890 ] Furkan KAMACI commented on LUCENE-2412: --- It would be nice if we had updated it and explained in more detail. Just for an example: Update Request Handling - optional language detection - Analysing(stamming, lemmitazing etc.) - Search Request Handling - Scoring - Soundex - etc. etc.? Architecture Diagrams needed for Lucene, Solr and Nutch --- Key: LUCENE-2412 URL: https://issues.apache.org/jira/browse/LUCENE-2412 Project: Lucene - Core Issue Type: Task Components: core/other Reporter: Grant Ingersoll Assignee: Grant Ingersoll Attachments: arch.pdf, LIA2_01_04.pdf, NutchArch.pdf, solr-arch.pdf -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619895#comment-13619895 ] Erick Erickson commented on SOLR-4662: -- Shawn: Couple of things: 1 there's no reason you can't have your individual data dirs specified in core.properties point wherever you want. Not sure that handles your case but thought I'd mention it. I'm not keen on maintaining a separate specify everything xml file, does the ability to specify your data dir for each core do what you need? 2 SOLR-4478 (another thing I hope to have done Real Soon now) will allow configsets. Basically in solr_home/configs (TBD) there will be directories like conf1, conf2 etc, which will be full Solr configuration directories. Then you can specify a configSet property in your individual core.properties file and that core will make use of the named config set, incidentally sharing all the setup between cores that use the same config set (i.e. won't parse/load the solrconfig.xml and schema.xml separately for each core that names the same config set). Keep the comments coming! Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898 ] Uwe Schindler commented on SOLR-4653: - Just one additional idea: There are comments about the regex in the current code and complexity for users. How about using ANT-style filesets for specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar from Maven, which contains DirectoryScanner that is able to parse things like **/*.jar. I use that in the fobidden APIs CLI and Mojo classes: https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261 Otherwise +1 to commit! Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898 ] Uwe Schindler edited comment on SOLR-4653 at 4/2/13 3:00 PM: - Just one additional idea: There are comments about the regex in the current code and complexity for users. How about using ANT-style filesets for specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar from Maven, which contains DirectoryScanner that is able to parse things like {{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261 Otherwise +1 to commit! was (Author: thetaphi): Just one additional idea: There are comments about the regex in the current code and complexity for users. How about using ANT-style filesets for specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar from Maven, which contains DirectoryScanner that is able to parse things like **/*.jar. I use that in the fobidden APIs CLI and Mojo classes: https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261 Otherwise +1 to commit! Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898 ] Uwe Schindler edited comment on SOLR-4653 at 4/2/13 3:01 PM: - Just one additional idea: There are comments about the regex in the current code and complexity for users. How about using ANT-style filesets for specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar from Maven, which contains DirectoryScanner that is able to parse things like {{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#257 Otherwise +1 to commit! was (Author: thetaphi): Just one additional idea: There are comments about the regex in the current code and complexity for users. How about using ANT-style filesets for specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar from Maven, which contains DirectoryScanner that is able to parse things like {{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261 Otherwise +1 to commit! Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Resolved] (LUCENE-4881) Add a set iterator to SentinelIntSet
[ https://issues.apache.org/jira/browse/LUCENE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-4881. -- Resolution: Won't Fix I committed better javadocs, including sample code to iterate the values. Closing issue as won't fix (for now). If at some point we want an iterator, the patch is here and it can be re-considered. Add a set iterator to SentinelIntSet Key: LUCENE-4881 URL: https://issues.apache.org/jira/browse/LUCENE-4881 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley Assignee: David Smiley Priority: Minor Fix For: 4.3 Attachments: LUCENE-4881_SentinalIntSet_int_iterator.patch, SentinelIntSet_docs.patch I'm working on code that needs a hash based int Set. It will need to iterate over the values, but SentinalIntSet doesn't have this utility feature. It should be pretty easy to add. FYI this is an out-growth of a question I posed to the dev list, examining 3 different int hash sets out there: SentinalIntSet, IntHashSet (in Lucene facet module) and the 3rd party IntOpenHashSet (HPPC) -- see http://lucene.472066.n3.nabble.com/IntHashSet-SentinelIntSet-SortedIntDocSet-td4037516.html I decided to go for SentinalIntSet because it's already in Lucene-core, adding the method I need should be easy, and it has a nice lean implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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
[JENKINS] Lucene-Solr-trunk-MacOSX ([[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}) - Build # 372 - Failure! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_90_1788693553.1364915769483 X-Jenkins-Job: Lucene-Solr-trunk-MacOSX X-Jenkins-Result: FAILURE Precedence: bulk --=_Part_90_1788693553.1364915769483 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/372/ Java: [[ Exception while replacing ENV. Please report this as a bug. ]] {{ java.lang.NullPointerException }} No tests ran. Build Log: [...truncated 10103 lines...] [junit4:junit4] Suite: org.apache.solr.client.solrj.TestBatchUpdate [junit4:junit4] 1 60572 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] WARN org.apache.solr.SolrTestCaseJ4 ? startTrackingSearchers: numOpens=37 numCloses=37 [junit4:junit4] 1 60634 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.SolrJettyTestBase ? Randomized ssl (true) and clientAuth (false) [junit4:junit4] 1 60635 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.SolrTestCaseJ4 ? initCore [junit4:junit4] 1 60636 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.SolrTestCaseJ4 ? initCore end [junit4:junit4] 1 60651 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.eclipse.jetty.server.Server ? jetty-8.1.8.v20121106 [junit4:junit4] 1 61049 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.eclipse.jetty.util.ssl.SslContextFactory ? Enabled Protocols [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] [junit4:junit4] 1 61058 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.eclipse.jetty.server.AbstractConnector ? Started SslSelectChannelConnector@127.0.0.1:51160 [junit4:junit4] 1 61060 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.servlet.SolrDispatchFilter ? SolrDispatchFilter.init() [junit4:junit4] 1 61062 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.SolrResourceLoader ? JNDI not configured for solr (NoInitialContextEx) [junit4:junit4] 1 61063 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.SolrResourceLoader ? using system property solr.solr.home: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr [junit4:junit4] 1 61063 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.CoreContainer ? looking for solr config file: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/solr.xml [junit4:junit4] 1 61065 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.CoreContainer ? New CoreContainer 984960070 [junit4:junit4] 1 61067 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.CoreContainer ? Loading CoreContainer using Solr Home: '/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/' [junit4:junit4] 1 61068 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.core.SolrResourceLoader ? new SolrResourceLoader for directory: '/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/' [junit4:junit4] 1 61184 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting socketTimeout to: 0 [junit4:junit4] 1 61185 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting urlScheme to: http:// [junit4:junit4] 1 61185 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting connTimeout to: 0 [junit4:junit4] 1 61186 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting maxConnectionsPerHost to: 20 [junit4:junit4] 1 61187 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting corePoolSize to: 0 [junit4:junit4] 1 61187 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting maximumPoolSize to: 2147483647 [junit4:junit4] 1 61188 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting maxThreadIdleTime to: 5 [junit4:junit4] 1 61189 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting sizeOfQueue to: -1 [junit4:junit4] 1 61190 [SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO org.apache.solr.handler.component.HttpShardHandlerFactory ? Setting
[jira] [Created] (SOLR-4663) Log an error if more than one core points to the same data dir.
Erick Erickson created SOLR-4663: Summary: Log an error if more than one core points to the same data dir. Key: SOLR-4663 URL: https://issues.apache.org/jira/browse/SOLR-4663 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor In large multi-core setups, having mistakes whereby two or more cores point to the same data dir seems quite possible. We should at least complain very loudly in the logs if this is detected. Should be a very straightforward check at core discovery time. Is this serious enough to keep Solr from coming up at all? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619933#comment-13619933 ] Erick Erickson commented on SOLR-4653: -- +1 to making the message more polite. The rest of the patch too! Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4883) Hide FieldCache behind an UninvertingFilterReader
[ https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-4883: -- Attachment: LUCENE-4883.patch New patch, with a NumericDocValues uninverter. Also a basic test. NumericDocValues doesn't work with 32-bit values yet (the test for IntField fails); I need to somehow detect at uninversion-time how wide the indexed values are. Hide FieldCache behind an UninvertingFilterReader - Key: LUCENE-4883 URL: https://issues.apache.org/jira/browse/LUCENE-4883 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch From a discussion on the mailing list: {{ rmuir: I think instead FieldCache should actually be completely package private and hidden behind a UninvertingFilterReader and accessible via the existing AtomicReader docValues methods. }} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4883) Hide FieldCache behind an UninvertingFilterReader
[ https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619944#comment-13619944 ] David Smiley commented on LUCENE-4883: -- What does NumericDocValues uninverter mean? DocValues are inherently un-inverted. Hide FieldCache behind an UninvertingFilterReader - Key: LUCENE-4883 URL: https://issues.apache.org/jira/browse/LUCENE-4883 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch From a discussion on the mailing list: {{ rmuir: I think instead FieldCache should actually be completely package private and hidden behind a UninvertingFilterReader and accessible via the existing AtomicReader docValues methods. }} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4883) Hide FieldCache behind an UninvertingFilterReader
[ https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619945#comment-13619945 ] Alan Woodward commented on LUCENE-4883: --- Something that will uninvert a LongField or DoubleField into a NumericDocValues representation. Hide FieldCache behind an UninvertingFilterReader - Key: LUCENE-4883 URL: https://issues.apache.org/jira/browse/LUCENE-4883 Project: Lucene - Core Issue Type: Improvement Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch From a discussion on the mailing list: {{ rmuir: I think instead FieldCache should actually be completely package private and hidden behind a UninvertingFilterReader and accessible via the existing AtomicReader docValues methods. }} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.
[ https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619964#comment-13619964 ] Shawn Heisey commented on SOLR-4662: bq. does the ability to specify your data dir for each core do what you need? As long the dataDir specified in a core properties file retains all its current capabilities relative to instanceDir, then yes, that will work nicely. As I mentioned, I would like to see a config option (probably in solr.xml, name suggestion coreDirectory) to specify a relative or absolute path where it will look for auto-detected instanceDirs. For the thousands of cores users, this will be very important, so that solr.solr.home isn't cluttered - it might have solr.xml (or its replacement) and a handful of directories like cores, lib, and maybe data. I'd like to see that parameter default to cores but I am not opposed to it being . or having no default value at all. bq. Basically in solr_home/configs (TBD) there will be directories like conf1, conf2 etc. I like this idea. I would want to make sure that relative xincludes are possible, just as they currently are with config sets in zookeeper. If the xml goes away and gets replaced by a properties file, including subconfigs won't be as important, but it would be nice if it were still possible. Finalize what we're going to do with solr.xml, auto-discovery, config sets. --- Key: SOLR-4662 URL: https://issues.apache.org/jira/browse/SOLR-4662 Project: Solr Issue Type: Improvement Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4888) SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1
[ https://issues.apache.org/jira/browse/LUCENE-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619969#comment-13619969 ] Adrien Grand commented on LUCENE-4888: -- I plan to commit soon unless someone objects. I think the changes are correct but please let me know if you would like to review it as this patch modifies some touchy code (such as SloppyPhraseScorer.advance). SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1 -- Key: LUCENE-4888 URL: https://issues.apache.org/jira/browse/LUCENE-4888 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.2 Reporter: Adrien Grand Assignee: Adrien Grand Attachments: LUCENE-4888.patch, LUCENE-4888.patch SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1 although the behavior of this method is undefined in such cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy
[ https://issues.apache.org/jira/browse/LUCENE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619971#comment-13619971 ] Adrien Grand commented on LUCENE-4858: -- bq. We can deal w/ addIndexes later. If it will be modified to use MP, we'll get that support for free; if not, we'll think about what we need to do. Sounds good to me. Early termination with SortingMergePolicy - Key: LUCENE-4858 URL: https://issues.apache.org/jira/browse/LUCENE-4858 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.3 Attachments: LUCENE-4858.patch, LUCENE-4858.patch Spin-off of LUCENE-4752, see https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565 and https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282 When an index is sorted per-segment, queries that sort according to the index sort order could be early terminated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619994#comment-13619994 ] Mark Miller commented on SOLR-4584: --- That's what I did when I tried to recreate this (though I used rows=0 as you originally reported) - it proxied the requests fine for me. Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Resolved] (SOLR-4656) Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting
[ https://issues.apache.org/jira/browse/SOLR-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4656. -- Resolution: Fixed Fix Version/s: 5.0 4.3 4x: r - 1463627 Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting - Key: SOLR-4656 URL: https://issues.apache.org/jira/browse/SOLR-4656 Project: Solr Issue Type: Improvement Components: highlighter Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor Fix For: 4.3, 5.0 Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, SOLR-4656.patch, SOLR-4656-trunk.patch I'm looking at an admittedly pathological case of many, many entries in a multiValued field, and trying to implement a way to limit the number examined, analogous to maxAnalyzedChars, see the patch. Along the way, I noticed that we do what looks like unnecessary copying of the fields to be examined. We call Document.getFields, which copies all of the fields and values to the returned array. Then we copy all of those to another array, converting them to Strings. Then we actually examine them. a this doesn't seem very efficient and b reduces the benefit from limiting the number of mv values examined. So the attached does two things: 1 attempts to fix this 2 implements hl.maxMultiValuedToExamine I'd _really_ love it if someone who knows the highlighting code takes a peek at the fix to see if I've messed things up, the changes are actually pretty minimal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yago Riveiro updated SOLR-4584: --- Attachment: select Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620012#comment-13620012 ] Yago Riveiro commented on SOLR-4584: :S, I tried again and doesn't work. I changed the wt to javabin for the browse doesn't interpret the response and the response is truncated, you can see it in file select that I'm attach. Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Reopened] (LUCENE-949) AnalyzingQueryParser can't work with leading wildcards.
[ https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened LUCENE-949: - Reopening at the request of [~talli...@mitre.org] who intends to attach a patch. Regular users can't re-open JIRA issues, apparently. AnalyzingQueryParser can't work with leading wildcards. --- Key: LUCENE-949 URL: https://issues.apache.org/jira/browse/LUCENE-949 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 2.2 Reporter: Stefan Klein The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following changes to accept leading wildcards: protected Query getWildcardQuery(String field, String termStr) throws ParseException { String useTermStr = termStr; String leadingWildcard = null; if (*.equals(field)) { if (*.equals(useTermStr)) return new MatchAllDocsQuery(); } boolean hasLeadingWildcard = (useTermStr.startsWith(*) || useTermStr.startsWith(?)) ? true : false; if (!getAllowLeadingWildcard() hasLeadingWildcard) throw new ParseException('*' or '?' not allowed as first character in WildcardQuery); if (getLowercaseExpandedTerms()) { useTermStr = useTermStr.toLowerCase(); } if (hasLeadingWildcard) { leadingWildcard = useTermStr.substring(0, 1); useTermStr = useTermStr.substring(1); } List tlist = new ArrayList(); List wlist = new ArrayList(); /* * somewhat a hack: find/store wildcard chars in order to put them back * after analyzing */ boolean isWithinToken = (!useTermStr.startsWith(?) !useTermStr.startsWith(*)); isWithinToken = true; StringBuffer tmpBuffer = new StringBuffer(); char[] chars = useTermStr.toCharArray(); for (int i = 0; i useTermStr.length(); i++) { if (chars[i] == '?' || chars[i] == '*') { if (isWithinToken) { tlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = false; } else { if (!isWithinToken) { wlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = true; } tmpBuffer.append(chars[i]); } if (isWithinToken) { tlist.add(tmpBuffer.toString()); } else { wlist.add(tmpBuffer.toString()); } // get Analyzer from superclass and tokenize the term TokenStream source = getAnalyzer().tokenStream(field, new StringReader(useTermStr)); org.apache.lucene.analysis.Token t; int countTokens = 0; while (true) { try { t = source.next(); } catch (IOException e) { t = null; } if (t == null) { break; } if (!.equals(t.termText())) { try { tlist.set(countTokens++, t.termText()); } catch (IndexOutOfBoundsException ioobe) { countTokens = -1; } } } try { source.close(); } catch (IOException e) { // ignore } if (countTokens != tlist.size()) {
[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero
[ https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620033#comment-13620033 ] Mark Miller commented on SOLR-4584: --- Have you tried it with the jetty we ship, or just tomcat? Request proxy mechanism not work if rows param is equal to zero --- Key: SOLR-4584 URL: https://issues.apache.org/jira/browse/SOLR-4584 Project: Solr Issue Type: Bug Affects Versions: 4.2 Environment: Linux Centos 6, Tomcat 7 Reporter: Yago Riveiro Assignee: Mark Miller Fix For: 4.3, 5.0 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 02.png, Screen Shot 03.png, select If I try to do a request like: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0 The request fail. The solr UI logging has this error: {code:java} null:org.apache.solr.common.SolrException: Error trying to proxy request for url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select {code} Chrome says: This webpage is not available The webpage at http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might be temporarily down or it may have moved permanently to a new web address. Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error. If the param rows is set to rows=4 or superior the query return data as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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-949) AnalyzingQueryParser can't work with leading wildcards.
[ https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Allison updated LUCENE-949: --- Attachment: AnalyzingQueryParser.java This allows for leading wildcards in the AnalyzingQueryParser if setAllowLeadingWildcard is set to true. AnalyzingQueryParser can't work with leading wildcards. --- Key: LUCENE-949 URL: https://issues.apache.org/jira/browse/LUCENE-949 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 2.2 Reporter: Stefan Klein Attachments: AnalyzingQueryParser.java The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following changes to accept leading wildcards: protected Query getWildcardQuery(String field, String termStr) throws ParseException { String useTermStr = termStr; String leadingWildcard = null; if (*.equals(field)) { if (*.equals(useTermStr)) return new MatchAllDocsQuery(); } boolean hasLeadingWildcard = (useTermStr.startsWith(*) || useTermStr.startsWith(?)) ? true : false; if (!getAllowLeadingWildcard() hasLeadingWildcard) throw new ParseException('*' or '?' not allowed as first character in WildcardQuery); if (getLowercaseExpandedTerms()) { useTermStr = useTermStr.toLowerCase(); } if (hasLeadingWildcard) { leadingWildcard = useTermStr.substring(0, 1); useTermStr = useTermStr.substring(1); } List tlist = new ArrayList(); List wlist = new ArrayList(); /* * somewhat a hack: find/store wildcard chars in order to put them back * after analyzing */ boolean isWithinToken = (!useTermStr.startsWith(?) !useTermStr.startsWith(*)); isWithinToken = true; StringBuffer tmpBuffer = new StringBuffer(); char[] chars = useTermStr.toCharArray(); for (int i = 0; i useTermStr.length(); i++) { if (chars[i] == '?' || chars[i] == '*') { if (isWithinToken) { tlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = false; } else { if (!isWithinToken) { wlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = true; } tmpBuffer.append(chars[i]); } if (isWithinToken) { tlist.add(tmpBuffer.toString()); } else { wlist.add(tmpBuffer.toString()); } // get Analyzer from superclass and tokenize the term TokenStream source = getAnalyzer().tokenStream(field, new StringReader(useTermStr)); org.apache.lucene.analysis.Token t; int countTokens = 0; while (true) { try { t = source.next(); } catch (IOException e) { t = null; } if (t == null) { break; } if (!.equals(t.termText())) { try { tlist.set(countTokens++, t.termText()); } catch (IndexOutOfBoundsException ioobe) { countTokens = -1; } } } try { source.close(); } catch (IOException e) { // ignore }
[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620037#comment-13620037 ] Aditya commented on SOLR-4661: -- Double checked .. and everything looks good. Step to reproduce this issue is simple. Just apply commit on master without posting any documents. The next replication you will see the difference of Version and gen on Slave. I remember in Solr3.5 applying commit with no pending document will not increment the version and gen on master. JVM Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 23.5-b02) Processors : 4 Args: -Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties -Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxPermSize=256m -Xmx3g -Xms3g -Djboss.server.default.config=standalone.xml -Djava.awt.headless=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dsolr.data.dir=/storage/solrdata/ -Denable.slave=true -Denable.master=false -Dsolr.solr.home=/opt/solr -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -XX:+TieredCompilation -XX:+UseCompressedOops -D[Standalone] Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620037#comment-13620037 ] Aditya edited comment on SOLR-4661 at 4/2/13 5:41 PM: -- Double checked .. and everything looks good. Step to reproduce this issue is simple. Just apply commit on master without posting any documents. The next replication you will see the difference of Version and gen on Slave. I remember in Solr3.5 applying commit with no pending document will not increment the version and gen on master. From the Slave --- JVM Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 23.5-b02) Processors : 4 Args: -Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties -Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxPermSize=256m -Xmx3g -Xms3g -Djboss.server.default.config=standalone.xml -Djava.awt.headless=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dsolr.data.dir=/storage/solrdata/ -Denable.slave=true -Denable.master=false -Dsolr.solr.home=/opt/solr -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -XX:+TieredCompilation -XX:+UseCompressedOops -D[Standalone] was (Author: abakle): Double checked .. and everything looks good. Step to reproduce this issue is simple. Just apply commit on master without posting any documents. The next replication you will see the difference of Version and gen on Slave. I remember in Solr3.5 applying commit with no pending document will not increment the version and gen on master. JVM Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 23.5-b02) Processors : 4 Args: -Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties -Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxPermSize=256m -Xmx3g -Xms3g -Djboss.server.default.config=standalone.xml -Djava.awt.headless=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dsolr.data.dir=/storage/solrdata/ -Denable.slave=true -Denable.master=false -Dsolr.solr.home=/opt/solr -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -XX:+TieredCompilation -XX:+UseCompressedOops -D[Standalone] Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Comment Edited] (LUCENE-949) AnalyzingQueryParser can't work with leading wildcards.
[ https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620036#comment-13620036 ] Timothy Allison edited comment on LUCENE-949 at 4/2/13 5:42 PM: This allows for leading wildcards in the AnalyzingQueryParser if setAllowLeadingWildcard is set to true. was (Author: talli...@mitre.org): This allows for leading wildcards in the AnalyzingQueryParser if setAllowLeadingWildcard is set to true. AnalyzingQueryParser can't work with leading wildcards. --- Key: LUCENE-949 URL: https://issues.apache.org/jira/browse/LUCENE-949 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 2.2 Reporter: Stefan Klein Attachments: AnalyzingQueryParser.java The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following changes to accept leading wildcards: protected Query getWildcardQuery(String field, String termStr) throws ParseException { String useTermStr = termStr; String leadingWildcard = null; if (*.equals(field)) { if (*.equals(useTermStr)) return new MatchAllDocsQuery(); } boolean hasLeadingWildcard = (useTermStr.startsWith(*) || useTermStr.startsWith(?)) ? true : false; if (!getAllowLeadingWildcard() hasLeadingWildcard) throw new ParseException('*' or '?' not allowed as first character in WildcardQuery); if (getLowercaseExpandedTerms()) { useTermStr = useTermStr.toLowerCase(); } if (hasLeadingWildcard) { leadingWildcard = useTermStr.substring(0, 1); useTermStr = useTermStr.substring(1); } List tlist = new ArrayList(); List wlist = new ArrayList(); /* * somewhat a hack: find/store wildcard chars in order to put them back * after analyzing */ boolean isWithinToken = (!useTermStr.startsWith(?) !useTermStr.startsWith(*)); isWithinToken = true; StringBuffer tmpBuffer = new StringBuffer(); char[] chars = useTermStr.toCharArray(); for (int i = 0; i useTermStr.length(); i++) { if (chars[i] == '?' || chars[i] == '*') { if (isWithinToken) { tlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = false; } else { if (!isWithinToken) { wlist.add(tmpBuffer.toString()); tmpBuffer.setLength(0); } isWithinToken = true; } tmpBuffer.append(chars[i]); } if (isWithinToken) { tlist.add(tmpBuffer.toString()); } else { wlist.add(tmpBuffer.toString()); } // get Analyzer from superclass and tokenize the term TokenStream source = getAnalyzer().tokenStream(field, new StringReader(useTermStr)); org.apache.lucene.analysis.Token t; int countTokens = 0; while (true) { try { t = source.next(); } catch (IOException e) { t = null; } if (t == null) { break; } if (!.equals(t.termText())) { try { tlist.set(countTokens++, t.termText()); } catch (IndexOutOfBoundsException ioobe) { countTokens = -1; }
[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set
[ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620064#comment-13620064 ] Yonik Seeley commented on SOLR-4478: bq. 2 property in core.properties is configName? Yes, we need to align this with solr cloud config as much as possible. Having configSet in some places and configName in other places isn't so hot ;-) Allow cores to specify a named config set - Key: SOLR-4478 URL: https://issues.apache.org/jira/browse/SOLR-4478 Project: Solr Issue Type: Improvement Affects Versions: 4.2, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Part of moving forward to the new way, after SOLR-4196 etc... I propose an additional parameter specified on the core node in solr.xml or as a parameter in the discovery mode core.properties file, call it configSet, where the value provided is a path to a directory, either absolute or relative. Really, this is as though you copied the conf directory somewhere to be used by more than one core. Straw-man: There will be a directory solr_home/configsets which will be the default. If the configSet parameter is, say, myconf, then I'd expect a directory named myconf to exist in solr_home/configsets, which would look something like solr_home/configsets/myconf/schema.xml solrconfig.xml stopwords.txt velocity velocity/query.vm etc. If multiple cores used the same configSet, schema, solrconfig etc. would all be shared (i.e. shareSchema=true would be assumed). I don't see a good use-case for _not_ sharing schemas, so I don't propose to allow this to be turned off. Hmmm, what if shareSchema is explicitly set to false in the solr.xml or properties file? I'd guess it should be honored but maybe log a warning? Mostly I'm putting this up for comments. I know that there are already thoughts about how this all should work floating around, so before I start any work on this I thought I'd at least get an idea of whether this is the way people are thinking about going. Configset can be either a relative or absolute path, if relative it's assumed to be relative to solr_home. Thoughts? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620073#comment-13620073 ] Hoss Man commented on SOLR-4661: Aditya: in your thread on the solr-user@lucene list, you posted some other examples of the generation being higher on the slave then on the master, and you also posted some short log files from both your master slave, but the log files you posted don't seem to directly correspond to the snippets you posted from requesting /replication?command=details in any of your mails or in this issue (the generation numbers logged by SnapPuller on the slave don't match up) Can you please attach a zip file containing a single cohesive example of: * a master solrconfig.xml * a slave solrconfig.xml (if different) * the log files for both the master and slave from JVM startup to jvm shutdown * any number of files containing the full response of getting the replication details form the master slave _with_ the timestamp of when these files were generated. The timestamps being crucial to helping us stitch together where in the flow of log messages you are seeing this inconsistency. If you are using bash, running two commands like this (one for master and one for slave) while solr is running should be suitable... {noformat} while true; do date --utc curl -sS http://localhost:8983/solr/collection1/replication?command=detailsindent=truewt=json; echo echo sleep 2; done 21 slave_rep_details.txt {noformat} Index Version Gen Number out of sync on Admin UI -- Key: SOLR-4661 URL: https://issues.apache.org/jira/browse/SOLR-4661 Project: Solr Issue Type: Bug Components: replication (java), web gui Affects Versions: 4.2 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7 Reporter: Aditya Labels: gui, replication, web Attachments: IndexVersionSyncIssue.jpg Index and Gen number on Slave is higher than master. If you apply commit on master with no pending docs then the commit time stamp and gen is incremented. When Slaves polls master for replication it see the index version difference and starts replicating but all files are skipped. On Admin UI (on Slaves) the version number displayed for master is old where as for slave is the latest which is higher than master. Below is the response from master (/replication?command=details) where i see two different Version an Gen numbers. This creates confusion of having version out of sync, though its not. response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=details str name=indexSize1.52 GB/str str name=indexPath/storage/solrdata/index//str arr name=commits lst long name=indexVersion{color:red}1364835609803{color}/long long name=generation{color:red}34{color}/long arr name=filelist.../arr /lst /arr str name=isMastertrue/str str name=isSlavefalse/str long name=indexVersion{color:red}1364778010902{color}/long long name=generation{color:red}31{color}/long lst name=master str name=confFilesschema.xml/str arr name=replicateAfter strcommit/str strstartup/str /arr str name=replicationEnabledtrue/str long name=replicatableGeneration34/long /lst /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...
[ https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620093#comment-13620093 ] Dawid Weiss commented on SOLR-4653: --- I saw the comment about glob patterns, Uwe. I just won't have the time to do it thoroughly (with proper testing etc.) so I'd rather file another issue for it. If somebody can get there sooner, fine. If not, I'll fix it in my spare cycles at some point. Solr configuration should log inaccessible/ non-existent relative paths lib dir=... --- Key: SOLR-4653 URL: https://issues.apache.org/jira/browse/SOLR-4653 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: SOLR-4653.patch Currently the dir path is resolved relative to core's instanceDir but if you don't know it nothing happens (no warning, no nothing). This is very frustrating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Created] (SOLR-4664) ZkStateReader should update aliases on construction.
Mark Miller created SOLR-4664: - Summary: ZkStateReader should update aliases on construction. Key: SOLR-4664 URL: https://issues.apache.org/jira/browse/SOLR-4664 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.3, 5.0 Currently they just use a watcher, so if you create the zkstatereader after updating aliases, it won't see them, unless another update happens. This might be done most often with CloudSolrServer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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] [Commented] (SOLR-4664) ZkStateReader should update aliases on construction.
[ https://issues.apache.org/jira/browse/SOLR-4664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620106#comment-13620106 ] Mark Miller commented on SOLR-4664: --- see http://markmail.org/thread/vtp2b7dz57ueqziu ZkStateReader should update aliases on construction. Key: SOLR-4664 URL: https://issues.apache.org/jira/browse/SOLR-4664 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.3, 5.0 Currently they just use a watcher, so if you create the zkstatereader after updating aliases, it won't see them, unless another update happens. This might be done most often with CloudSolrServer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: 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