[jira] [Updated] (SOLR-4230) Enhance geofilt and bbox parsers to support Solr 4 spatial field types
[ https://issues.apache.org/jira/browse/SOLR-4230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-4230: --- Attachment: SOLR-4230_geofilt_and_bbox_support_for_Solr_4_spatial.patch The attached file implements this support. Note that the score=distance local-param feature in the Solr 4 spatial field should also work too -- pretty cool. I took a look at adding support for the geodist function, which is implemented in HaversineConstFunction. Ugh, the logic therein is convoluted and it makes heavy assumptions about a MultiValueSource based field which the Solr 4 spatial fields don't use and never will. Adding support here for Solr 4 spatial fields would definitely be a hack and on top of confusing code that I don't want to make any more confusing. So I'll pass on that. I plan to commit in a few days. Enhance geofilt and bbox parsers to support Solr 4 spatial field types -- Key: SOLR-4230 URL: https://issues.apache.org/jira/browse/SOLR-4230 Project: Solr Issue Type: Improvement Components: search Reporter: David Smiley Assignee: David Smiley Attachments: SOLR-4230_geofilt_and_bbox_support_for_Solr_4_spatial.patch -- 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-4345) Create a Classification module
[ https://issues.apache.org/jira/browse/LUCENE-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved LUCENE-4345. - Resolution: Fixed Create a Classification module -- Key: LUCENE-4345 URL: https://issues.apache.org/jira/browse/LUCENE-4345 Project: Lucene - Core Issue Type: New Feature Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Minor Fix For: 5.0 Attachments: LUCENE-4345_2.patch, LUCENE-4345.patch, SOLR-3700_2.patch, SOLR-3700.patch Lucene/Solr can host huge sets of documents containing lots of information in fields so that these can be used as training examples (w/ features) in order to very quickly create classifiers algorithms to use on new documents and / or to provide an additional service. So the idea is to create a contrib module (called 'classification') to host a ClassificationComponent that will use already seen data (the indexed documents / fields) to classify new documents / text fragments. The first version will contain a (simplistic) Lucene based Naive Bayes classifier but more implementations should be added in the future. -- 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-3725) package-local-src-tgz target is pulling in non-source jars, dist/** and package/**
[ https://issues.apache.org/jira/browse/SOLR-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540811#comment-13540811 ] Commit Tag Bot commented on SOLR-3725: -- [trunk commit] Erik Hatcher http://svn.apache.org/viewvc?view=revisionrevision=1426716 SOLR-3725: Relocate the example mime-to-extension mapping, and upgrade Velocity Engine to 1.7 package-local-src-tgz target is pulling in non-source jars, dist/** and package/** -- Key: SOLR-3725 URL: https://issues.apache.org/jira/browse/SOLR-3725 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 4.0-ALPHA Reporter: Michael Dodsworth Priority: Minor Fix For: 4.0, 5.0 Attachments: SOLR-3725.patch package-local-src-tgz generates a 141M archive which contains a bunch of non-source jars: {code} tar tfz apache-solr-4.0-SNAPSHOT-src.tgz | grep -E '(war|jar)$' | wc -l 134 {code} It looks like we're expecting dist/** and package/** to be excluded: {code:xml} tarfileset dir=. prefix=${fullnamever}/solr excludes=build ${package.dir}/** ${dist}/** example/webapps/*.war example/exampledocs/post.jar lib/README.committers.txt **/data/ **/logs/* **/*.sh **/bin/ scripts/ .idea/ **/*.iml **/pom.xml / {code} The issue is that package.dir and dist refer to absolute paths; excludes assumes relative paths. It's also pulling in all the contrib/**/lib/ and example/lib/ jars. -- 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-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540817#comment-13540817 ] Erik Hatcher commented on SOLR-3735: I committed to trunk this change. I also upgraded Velocity from 1.6.4 to 1.7. I'm leaving this issue open for 4.1, with likely some more related changes coming soon. Maybe best to backport to 4.x when more substantial and visible changes are made in this area on trunk. Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.1 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- 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-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3735: --- Fix Version/s: 5.0 Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- 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-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3735: --- Affects Version/s: 4.0 Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA, 4.0 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- 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-Linux (32bit/jdk1.7.0_09) - Build # 3484 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3484/ Java: 32bit/jdk1.7.0_09 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 30656 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:312: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/licenses/velocity-1.7.jar.sha1 Total time: 33 minutes 48 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -server -XX:+UseConcMarkSweepGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_09) - Build # 3485 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/3485/ Java: 32bit/jdk1.7.0_09 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 30645 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:312: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/licenses/velocity-1.7.jar.sha1 Total time: 35 minutes 32 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_09 -client -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540867#comment-13540867 ] Commit Tag Bot commented on SOLR-3735: -- [trunk commit] Erik Hatcher http://svn.apache.org/viewvc?view=revisionrevision=1426746 SOLR-3735: fix svn:eol-style setting on new Velocity SHA1 file Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA, 4.0 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- 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-4.x-MacOSX (64bit/jdk1.7.0) - Build # 6 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-MacOSX/6/ Java: 64bit/jdk1.7.0 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 9052 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=159BA5B37607FE44 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/testlogging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=US-ASCII -classpath
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.6.0_37) - Build # 2334 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/2334/ Java: 64bit/jdk1.6.0_37 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 13 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E204900: Unable to delete C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar at hudson.scm.subversion.UpdateWithCleanUpdater$TaskImpl$1.handleStatus(UpdateWithCleanUpdater.java:78) at org.tmatesoft.svn.core.wc.SVNStatusClient$1.receive(SVNStatusClient.java:356) at org.tmatesoft.svn.core.wc.SVNStatusClient$1.receive(SVNStatusClient.java:353) at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldGetStatus.handleStatus(SvnOldGetStatus.java:37) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.sendUnversionedStatus(SVNStatusEditor.java:361) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.getDirStatus(SVNStatusEditor.java:209) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.handleDirEntry(SVNStatusEditor.java:321) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.getDirStatus(SVNStatusEditor.java:256) at org.tmatesoft.svn.core.internal.wc.SVNStatusEditor.closeEdit(SVNStatusEditor.java:114) at org.tmatesoft.svn.core.internal.wc16.SVNStatusClient16.doStatus(SVNStatusClient16.java:430) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldGetStatus.run(SvnOldGetStatus.java:22) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldGetStatus.run(SvnOldGetStatus.java:13) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292) at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:360) at hudson.scm.subversion.UpdateWithCleanUpdater$TaskImpl.preUpdate(UpdateWithCleanUpdater.java:66) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:141) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:824) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:805) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:788) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source) Caused by: svn: E204900: Unable to delete C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:109) ... 34 more Caused by: java.io.IOException: Unable to delete C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar at hudson.Util.deleteFile(Util.java:243) at hudson.Util.deleteRecursive(Util.java:293) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.Util.deleteRecursive(Util.java:284) at hudson.scm.subversion.UpdateWithCleanUpdater$TaskImpl$1.handleStatus(UpdateWithCleanUpdater.java:74) ... 33 more ERROR: Subversion update failed hudson.util.IOException2: remote file operation failed: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows at hudson.remoting.Channel@1ac91010:Windows VBOX at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:771) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:713) at hudson.model.AbstractProject.checkout(AbstractProject.java:1325) at
DirectSpellChecker.suggestSimilar() scans TermEnum. but why?
Happy New Year, Devs! Excuse me for the noob's question. I'm not able to get deep into FST internals. I run trivial benchmark and not really enjoyed by the results. I'm looking for the ultra-fast spelling correction. Right now I use 3.x SpellChecker which is backed on separate Lucene Ngram index.FWIW, it's persistent, not in RAMDirectory. Now the bottleneck is I/O. Reading that Lucene Ngram index takes too much time. I guess it might be solved by loading Lucene Ngram index into RAMDirectory, but I want to exploit FST spell check from 4.0. What I see, and what makes me wonder. Every DirectSpellChecker.suggestSimilar() creates new FuzzyTermsEnum and every time it scans the termsEnum by FilteredTermsEnum.next(). And here I hit the same slow IO bummer. It might be necessary detail: I read 3.x index by 4.0 code. I don't think it changes something. I don't know anything about FST, but I've thought that it's a compact graph of syllables, which is visited for finding string similar to the given i.e. I expect it won't scan termsEnum for every lookup. Please tell me what's wrong in my expectations. Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics http://www.griddynamics.com mkhlud...@griddynamics.com
[jira] [Updated] (SOLR-3428) SolrCmdDistributor flushAdds/flushDeletes problems
[ https://issues.apache.org/jira/browse/SOLR-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3428: -- Fix Version/s: (was: 4.1) SolrCmdDistributor flushAdds/flushDeletes problems -- Key: SOLR-3428 URL: https://issues.apache.org/jira/browse/SOLR-3428 Project: Solr Issue Type: Bug Components: replication (java), SolrCloud, update Affects Versions: 4.0-ALPHA Reporter: Per Steffensen Assignee: Per Steffensen Labels: add, delete, replica, solrcloud, update Original Estimate: 24h Remaining Estimate: 24h A few problems with SolrCmdDistributor.flushAdds/flushDeletes * If number of AddRequests/DeleteRequests in alist/dlist is below limit for a specific node the method returns immediately and doesnt flush for subsequent nodes * When returning immediately because there is below limit requests for a given node, then previous nodes that have already been flushed/submitted are not removed from adds/deletes maps (causing them to be flushed/submitted again the next time flushAdds/flushDeletes is executed) * The idea about just combining params does not work for SEEN_LEADER params (and probably others as well). Since SEEN_LEADER cannot be expressed (unlike commitWithin and overwrite) for individual operations in the request, you need to sent two separate submits. One containing requests with SEEN_LEADER=true and one with SEEN_LEADER=false. -- 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-2700) transaction logging
[ https://issues.apache.org/jira/browse/SOLR-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2700: -- Fix Version/s: (was: 4.1) 4.0 Assignee: Yonik Seeley transaction logging --- Key: SOLR-2700 URL: https://issues.apache.org/jira/browse/SOLR-2700 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 4.0 Attachments: SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch A transaction log is needed for durability of updates, for a more performant realtime-get, and for replaying updates to recovering peers. -- 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-2700) transaction logging
[ https://issues.apache.org/jira/browse/SOLR-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-2700. --- Resolution: Fixed Fix Version/s: 5.0 transaction logging --- Key: SOLR-2700 URL: https://issues.apache.org/jira/browse/SOLR-2700 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 5.0, 4.0 Attachments: SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch, SOLR-2700.patch A transaction log is needed for durability of updates, for a more performant realtime-get, and for replaying updates to recovering peers. -- 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-3141) Deprecate OPTIMIZE command in Solr
[ https://issues.apache.org/jira/browse/SOLR-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3141: -- Fix Version/s: (was: 4.1) 5.0 4.2 Deprecate OPTIMIZE command in Solr -- Key: SOLR-3141 URL: https://issues.apache.org/jira/browse/SOLR-3141 Project: Solr Issue Type: Improvement Components: update Affects Versions: 3.5 Reporter: Jan Høydahl Labels: force, optimize Fix For: 4.2, 5.0 Attachments: SOLR-3141.patch, SOLR-3141.patch Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that issue first. Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, what should be done with Solr's ancient optimize command? -- 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-3141) Deprecate OPTIMIZE command in Solr
[ https://issues.apache.org/jira/browse/SOLR-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540927#comment-13540927 ] Mark Miller commented on SOLR-3141: --- No assignee or action in some time - pushing to 4.2 - if it's a mistake, please bring it back into 4.1. Deprecate OPTIMIZE command in Solr -- Key: SOLR-3141 URL: https://issues.apache.org/jira/browse/SOLR-3141 Project: Solr Issue Type: Improvement Components: update Affects Versions: 3.5 Reporter: Jan Høydahl Labels: force, optimize Fix For: 4.2, 5.0 Attachments: SOLR-3141.patch, SOLR-3141.patch Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that issue first. Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, what should be done with Solr's ancient optimize command? -- 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-3474) It would be great if the SolrCloud cluster viz views would auto refresh.
[ https://issues.apache.org/jira/browse/SOLR-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3474: -- Fix Version/s: (was: 4.1) 5.0 4.2 It would be great if the SolrCloud cluster viz views would auto refresh. Key: SOLR-3474 URL: https://issues.apache.org/jira/browse/SOLR-3474 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Affects Versions: 4.0-ALPHA Reporter: Mark Miller Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.2, 5.0 If you are sitting on that screen and knock down a server, would be nice for that to show up without requiring a refresh. -- 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-3474) It would be great if the SolrCloud cluster viz views would auto refresh.
[ https://issues.apache.org/jira/browse/SOLR-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540928#comment-13540928 ] Mark Miller commented on SOLR-3474: --- An option to change the refresh rate sounds good - on a large cluster, it could take a fair bit of time to keep pulling down cluster info for example.. It would be great if the SolrCloud cluster viz views would auto refresh. Key: SOLR-3474 URL: https://issues.apache.org/jira/browse/SOLR-3474 Project: Solr Issue Type: Improvement Components: SolrCloud, web gui Affects Versions: 4.0-ALPHA Reporter: Mark Miller Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.2, 5.0 If you are sitting on that screen and knock down a server, would be nice for that to show up without requiring a refresh. -- 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
Moving unassigned jira issues out of 4.1
FYI, I'm going to be moving any unassigned jira issues out of 4.1. If you intend to get an issue in for 4.1, please assign yourself and move it back in. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4232) Make request handler metrics optional
[ https://issues.apache.org/jira/browse/SOLR-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4232: -- Priority: Major (was: Blocker) Make request handler metrics optional - Key: SOLR-4232 URL: https://issues.apache.org/jira/browse/SOLR-4232 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 5.0 Reporter: Shawn Heisey Fix For: 4.2, 5.0 Uwe Schindler noticed what looked like a memory leak caused by the addition of SOLR-1972. I don't believe it's actually a leak, but the additional memory required does appear to be causing problems for Solr test JVMs. I think this is likely because there are a LOT of request handlers defined for even a very minimal test config, each of which ends up with the new objects. This is an attempt to provide an option for turning on the new statistics only when required. For most people, this will only be required for search handlers. If this is not successful at fixing the test problems, we can remove metrics with this issue. -- 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-4112) Dataimporting with SolrCloud Fails
[ https://issues.apache.org/jira/browse/SOLR-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4112: -- Priority: Major (was: Blocker) Dataimporting with SolrCloud Fails -- Key: SOLR-4112 URL: https://issues.apache.org/jira/browse/SOLR-4112 Project: Solr Issue Type: Bug Affects Versions: 5.0 Reporter: Deniz Durmus Assignee: James Dyer Fix For: 4.1, 5.0 Attachments: SOLR-4112.patch While trying to import data from db on cloud, it shows this in logs: SEVERE: Full Import failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to PropertyWriter implementation:ZKPropertiesWriter at org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:336) at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:418) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) Caused by: org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() - likely, what you are trying to do is not supported in ZooKeeper mode at org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:100) at org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:91) at org.apache.solr.handler.dataimport.ZKPropertiesWriter.init(ZKPropertiesWriter.java:45) at org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:334) ... 3 more Exception in thread Thread-306 java.lang.NullPointerException at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:427) at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:487) at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:468) -- 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-1752) SolrJ fails with exception when passing document ADD and DELETEs in the same request using XML request writer (but not binary request writer)
[ https://issues.apache.org/jira/browse/SOLR-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1752: -- Priority: Major (was: Blocker) SolrJ fails with exception when passing document ADD and DELETEs in the same request using XML request writer (but not binary request writer) - Key: SOLR-1752 URL: https://issues.apache.org/jira/browse/SOLR-1752 Project: Solr Issue Type: Bug Components: clients - java, update Affects Versions: 1.4 Reporter: Jayson Minard Assignee: Shalin Shekhar Mangar Attachments: SOLR-1752_2.patch, SOLR-1752.patch, SOLR-1752.patch Add this test to SolrExampleTests.java and it will fail when using the XML Request Writer (now default), but not if you change the SolrExampleJettyTest to use the BinaryRequestWriter. {code} public void testAddDeleteInSameRequest() throws Exception { SolrServer server = getSolrServer(); SolrInputDocument doc3 = new SolrInputDocument(); doc3.addField( id, id3, 1.0f ); doc3.addField( name, doc3, 1.0f ); doc3.addField( price, 10 ); UpdateRequest up = new UpdateRequest(); up.add( doc3 ); up.deleteById(id001); up.setWaitFlush(false); up.setWaitSearcher(false); up.process( server ); } {code} terminates with exception: {code} Feb 3, 2010 8:55:34 AM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException: Illegal to have multiple roots (start tag in epilog?). at [row,col {unknown-source}]: [1,125] at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:72) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:723) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) Caused by: com.ctc.wstx.exc.WstxParsingException: Illegal to have multiple roots (start tag in epilog?). at [row,col {unknown-source}]: [1,125] at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:630) at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:461) at com.ctc.wstx.sr.BasicStreamReader.handleExtraRoot(BasicStreamReader.java:2155) at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2070) at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2647) at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:90) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69) ... 18 more {code} -- 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-3471) Tests not working on Windows
[ https://issues.apache.org/jira/browse/SOLR-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3471: -- Priority: Critical (was: Blocker) Tests not working on Windows Key: SOLR-3471 URL: https://issues.apache.org/jira/browse/SOLR-3471 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA Reporter: Uwe Schindler Priority: Critical The following tests are failing on Windows quite often: - SoftAutoCommitTest (all tests): There seem to be wrong assumes - I dont like the test testing how fast something is (there are slow machines or machines with = 2 cores) - TestSolrDeletionPolicy1.testCommitAge() - also maybe timing issue. Otherwise I think the custom Solr DeletionPolicy is not respecting the fact that Windows cannot delete open files - TestRealTimeGet.testStressRecovery(): See also SOLR-3461 for more discussion I annotate the tests with an assume disabling Windows until this is fixed. -- 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-3157) custom logging
[ https://issues.apache.org/jira/browse/SOLR-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3157: -- Priority: Major (was: Blocker) custom logging -- Key: SOLR-3157 URL: https://issues.apache.org/jira/browse/SOLR-3157 Project: Solr Issue Type: Test Reporter: Yonik Seeley Attachments: jetty_threadgroup.patch, SOLR-3157.patch We need custom logging to decipher tests with multiple core containers, cores, in a single JVM. -- 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-4121) balanced single quotes cause parse error in (new) standard QParser
[ https://issues.apache.org/jira/browse/SOLR-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4121: -- Fix Version/s: 5.0 balanced single quotes cause parse error in (new) standard QParser -- Key: SOLR-4121 URL: https://issues.apache.org/jira/browse/SOLR-4121 Project: Solr Issue Type: Bug Components: query parsers Reporter: Hoss Man Assignee: Yonik Seeley Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-4121-test.patch The parser changes introduced in SOLR-4093 cause the standard parser to freak out anytime there are blanaced single quotes in a query string. the expected behavior is that single quotes should not be considered special to the parser, and should be ignored and passed down to the appropriate field analyzers Example of error... http://localhost:8983/solr/select?q=%27zz+xx%27debugQuery=true {noformat} Caused by: org.apache.solr.parser.ParseException: Encountered SQUOTED \'zz xx\' at line 1, column 0. Was expecting one of: NOT ... + ... - ... BAREOPER ... ( ... * ... QUOTED ... TERM ... PREFIXTERM ... WILDTERM ... REGEXPTERM ... [ ... { ... LPARAMS ... NUMBER ... TERM ... * ... at org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:649) at org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:531) at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:216) at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107) at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96) at org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:159) {noformat} -- 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-656) better error message when data/index is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540931#comment-13540931 ] Shawn Heisey commented on SOLR-656: --- As part of the 4.1 release triage (focus on Solr), I am attempting to make a patch for this. My first attempt was at a very low level - lucene's FSDirectory. This caused a LOT of test failures. D:\workspace\branch_4x\lucene\common-build.xml:841: There were test failures: 330 suites, 1862 tests, 5 suite-level errors, 156 errors, 21 ignored (9 assumptions) I'm trying again with SolrCore.java. I'm not sure how to write a test for this. Perhaps I need to init a new core, find the indexDir, delete everything in it, then reload the core. better error message when data/index is completely empty -- Key: SOLR-656 URL: https://issues.apache.org/jira/browse/SOLR-656 Project: Solr Issue Type: Wish Reporter: Hoss Man Fix For: 4.2, 5.0 Solr's normal behavior is to create an index dire in the dataDir if one does not already exist, but if index does exist it is used as is, warts and all ... if the index is corrupt in some way, and Solr can't create an IndexWriter or IndexReader that error is propagated up to the user. I don't think this should change: Solr shouldn't attempt to do anything special if there is a low level problem with the index, but something that i've seen happen more then a few times is that people unwittingly rm index/* when they should run -r index and as a result Solr+Lucene gives them an error instead of just giving them an empty index when checking if an existing index dir exists, it would probably be worth while to add a little one line sanity test that it contains some files, and log a warning. -- 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-4230) Enhance geofilt and bbox parsers to support Solr 4 spatial field types
[ https://issues.apache.org/jira/browse/SOLR-4230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-4230: --- Fix Version/s: 5.0 4.1 Description: CHANGES.txt entry: {noformat} * SOLR-4230: The new Solr 4 spatial fields now work with the {!geofilt} and {!bbox} query parsers. The score local-param works too. (David Smiley) {noformat} Enhance geofilt and bbox parsers to support Solr 4 spatial field types -- Key: SOLR-4230 URL: https://issues.apache.org/jira/browse/SOLR-4230 Project: Solr Issue Type: Improvement Components: search Reporter: David Smiley Assignee: David Smiley Fix For: 4.1, 5.0 Attachments: SOLR-4230_geofilt_and_bbox_support_for_Solr_4_spatial.patch CHANGES.txt entry: {noformat} * SOLR-4230: The new Solr 4 spatial fields now work with the {!geofilt} and {!bbox} query parsers. The score local-param works too. (David Smiley) {noformat} -- 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-656) better error message when data/index is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-656: -- Attachment: SOLR-656.patch A patch for this issue, including a unit test. The unit test is pretty quick when it passes, but slow when it fails. Patch is against 4x, but applies to trunk with one complaint about fuzz (gnu patch on CentOS 6). Now running all tests for both branch_4x and trunk. better error message when data/index is completely empty -- Key: SOLR-656 URL: https://issues.apache.org/jira/browse/SOLR-656 Project: Solr Issue Type: Wish Reporter: Hoss Man Fix For: 4.2, 5.0 Attachments: SOLR-656.patch Solr's normal behavior is to create an index dire in the dataDir if one does not already exist, but if index does exist it is used as is, warts and all ... if the index is corrupt in some way, and Solr can't create an IndexWriter or IndexReader that error is propagated up to the user. I don't think this should change: Solr shouldn't attempt to do anything special if there is a low level problem with the index, but something that i've seen happen more then a few times is that people unwittingly rm index/* when they should run -r index and as a result Solr+Lucene gives them an error instead of just giving them an empty index when checking if an existing index dir exists, it would probably be worth while to add a little one line sanity test that it contains some files, and log a warning. -- 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-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-3180: --- Attachment: CMSL_hang_2.txt Here's another hang. Diff between 2 snapshots at different times is: {code} java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.apache.solr.cloud.DistributedQueue$LatchChildWatcher.await(DistributedQueue.java:182) - - locked 0xf5821d30 (a java.lang.Object) + - locked 0xf5f2c7c0 (a java.lang.Object) at org.apache.solr.cloud.DistributedQueue.peek(DistributedQueue.java:281) at org.apache.solr.cloud.OverseerCollectionProcessor.run(OverseerCollectionProcessor.java:100) at java.lang.Thread.run(Thread.java:662) {code} ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Attachments: CMSL_hang_2.txt, CMSL_hang.txt, fail.inconsistent.txt, test_report_1.txt Handle intermittent failures in the ChaosMonkey tests. -- 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-MAVEN] Lucene-Solr-Maven-trunk #720: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/720/ No tests ran. Build Log: [...truncated 11169 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4242) A better spatial query parser
David Smiley created SOLR-4242: -- Summary: A better spatial query parser Key: SOLR-4242 URL: https://issues.apache.org/jira/browse/SOLR-4242 Project: Solr Issue Type: New Feature Components: query parsers Reporter: David Smiley Fix For: 4.2 I've been thinking about how spatial support is exposed to Solr users. Presently there's the older Solr 3 stuff, most prominently seen via \{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks like mygeofield:Intersects(Circle(1 2 d=3)) What's inside the outer parenthesis is parsed by Spatial4j as a shape, and it has a special (non-standard) syntax for points, rects, and circles, and then there's WKT. I believe this scheme was devised by [~ryantxu]. I'd like to devise something that is both comprehensive and is aligned with standards to the extent that it's prudent. The old Solr 3 stuff is not comprehensive and not standardized. The newer stuff is comprehensive but only a little based on standards. And I think it'd be nicer to implement it as a Solr query parser. I'll say more in the comments. -- 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-656) better error message when data/index is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540987#comment-13540987 ] Shawn Heisey commented on SOLR-656: --- Patch is not working. Running all tests on trunk (linux) results in a number of failures that probably *are* caused by this patch. Running all tests on branch_4x (windows) results in failures, one of which is actually my new test - which passed earlier. When my new test failed, it was complaining about thread leaks. My test approach probably needs some work, but I'm not familiar enough with the test frameworks. I suspect that what needs to happen is that I need to lock the index directory to a known location, then make that directory and do initCore. Optionally, I could instead initCore in a the specific directory, destroy the core completely, delete all the index files, and attempt to initCore again in the same directory. I do not know how to go about doing this. better error message when data/index is completely empty -- Key: SOLR-656 URL: https://issues.apache.org/jira/browse/SOLR-656 Project: Solr Issue Type: Wish Reporter: Hoss Man Fix For: 4.2, 5.0 Attachments: SOLR-656.patch Solr's normal behavior is to create an index dire in the dataDir if one does not already exist, but if index does exist it is used as is, warts and all ... if the index is corrupt in some way, and Solr can't create an IndexWriter or IndexReader that error is propagated up to the user. I don't think this should change: Solr shouldn't attempt to do anything special if there is a low level problem with the index, but something that i've seen happen more then a few times is that people unwittingly rm index/* when they should run -r index and as a result Solr+Lucene gives them an error instead of just giving them an empty index when checking if an existing index dir exists, it would probably be worth while to add a little one line sanity test that it contains some files, and log a warning. -- 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-656) better error message when data/index is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-656: -- Attachment: SOLR-656-rmdir.patch New patch with completely different approach: This time there are no unit tests. After doing everything it can to make sure that a filesystem directory should exist, does exist, and contains nothing, proceeds to remove that index directory and log a warning saying that it did so. better error message when data/index is completely empty -- Key: SOLR-656 URL: https://issues.apache.org/jira/browse/SOLR-656 Project: Solr Issue Type: Wish Reporter: Hoss Man Fix For: 4.2, 5.0 Attachments: SOLR-656.patch, SOLR-656-rmdir.patch Solr's normal behavior is to create an index dire in the dataDir if one does not already exist, but if index does exist it is used as is, warts and all ... if the index is corrupt in some way, and Solr can't create an IndexWriter or IndexReader that error is propagated up to the user. I don't think this should change: Solr shouldn't attempt to do anything special if there is a low level problem with the index, but something that i've seen happen more then a few times is that people unwittingly rm index/* when they should run -r index and as a result Solr+Lucene gives them an error instead of just giving them an empty index when checking if an existing index dir exists, it would probably be worth while to add a little one line sanity test that it contains some files, and log a warning. -- 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-4229) Swappable (introduced in 1028) is confusing. Change the name
[ https://issues.apache.org/jira/browse/SOLR-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540991#comment-13540991 ] Commit Tag Bot commented on SOLR-4229: -- [trunk commit] Erick Erickson http://svn.apache.org/viewvc?view=revisionrevision=1426826 Fix for SOLR-4229, changing swappable to transient Swappable (introduced in 1028) is confusing. Change the name -- Key: SOLR-4229 URL: https://issues.apache.org/jira/browse/SOLR-4229 Project: Solr Issue Type: Improvement Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-4229.patch the new tag swappable, introduced in SOLR-1028 is too easily confused with swapping cores. Rename to dynamic? transient? I think transient captures the notion best. Marking blocker just because I want to insure it's changed before the whole notion is released the first time, patch real soon now. I think we can justify changing the names of things like this more easily before it's in official circulation. -- 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-656) better error message when data/index is completely empty
[ https://issues.apache.org/jira/browse/SOLR-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-656: -- Attachment: SOLR-656-rmdir.patch Update to alternate patch. Added abstract isFSBased method to DirectoryFactory and some classes that extend it. Used this to further guarantee that an empty directory should be removed. If custom DF implementations extend DF directly rather than one of the better base classes, this will break them. better error message when data/index is completely empty -- Key: SOLR-656 URL: https://issues.apache.org/jira/browse/SOLR-656 Project: Solr Issue Type: Wish Reporter: Hoss Man Fix For: 4.2, 5.0 Attachments: SOLR-656.patch, SOLR-656-rmdir.patch, SOLR-656-rmdir.patch Solr's normal behavior is to create an index dire in the dataDir if one does not already exist, but if index does exist it is used as is, warts and all ... if the index is corrupt in some way, and Solr can't create an IndexWriter or IndexReader that error is propagated up to the user. I don't think this should change: Solr shouldn't attempt to do anything special if there is a low level problem with the index, but something that i've seen happen more then a few times is that people unwittingly rm index/* when they should run -r index and as a result Solr+Lucene gives them an error instead of just giving them an empty index when checking if an existing index dir exists, it would probably be worth while to add a little one line sanity test that it contains some files, and log a warning. -- 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-4182) MoreLikeThisHandler ignores mlt.count
[ https://issues.apache.org/jira/browse/SOLR-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540995#comment-13540995 ] Jack Krupansky commented on SOLR-4182: -- I found this comment in MoreLikeThisParams.java: {code} // the /mlt request handler uses 'rows' public final static String DOC_COUNT = mlt.count; {code} In other words, you're SUPPOSED to use rows=n with the /mlt handler rather than mlt.count=n. So, it's not really a bug per se, more of an inconsistency that could be improved. For example, maybe the default for rows in the mlt handler should be mlt.count. And maybe the doc could be improved a little. I would note that mlt.count is ONLY listed under the MLT search component and NOT mentioned in the handler. The doc for the handler shoulder probably explicitly say that it uses rows rather than mlt.count. MoreLikeThisHandler ignores mlt.count - Key: SOLR-4182 URL: https://issues.apache.org/jira/browse/SOLR-4182 Project: Solr Issue Type: Bug Components: MoreLikeThis Affects Versions: 4.1 Environment: solr-impl 4.1-SNAPSHOT 1421381 - ncindex - 2012-12-13 10:16:41 Reporter: Shawn Heisey Fix For: 4.2, 5.0 MoreLikeThisHandler ignores the mlt.count parameter. This seems to be the case whether it's on the URL path or in the handler definition. When using MoreLikeThisComponent in a search handler, mlt.count works. -- 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-4242) A better spatial query parser
[ https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540996#comment-13540996 ] David Smiley commented on SOLR-4242: FYI I've been making progress on introducing a WKT parser native to Spatial4j without it having to rely on JTS's WKT parser. WKT, being an important spatial standard, should be had without yet another dependency. Another reason to not use JTS is that JTS's WKT parser isn't extensible. I've looked at a few specs and APIs out there for commonality: # The SQL realm has an Open Geospatial Consortium (OGC) standard called [Simple Feature Access - Part 2: SQL Option|http://www.opengeospatial.org/standards/sfs]. [Wikipedia says|http://en.wikipedia.org/wiki/Simple_Features] the latest version is governed by ISO as the SQL/MM spec (not available freely). This is well adopted by relational databases and is recognizable by all the ST_ prefixes to the SQL extensions. Quick example (I may not have this quite right): {noformat}ST_WITHIN(myGeomField,ST_POINT(50, 50)){noformat} # The [OGC Filter Encoding spec|http://www.opengeospatial.org/standards/filter] has additional operators DWithin (within distance, e.g. intersects a circle), Beyond (the opposite of DWithin), and BBOX (intersects a rect). All 3 address shortcomings in WKT concerning lack of circles and no native rectangle shape. The spec as a whole isn't applicable as its XML oriented however these operators are welcome; I've seen them in other contexts; and these could be transferrable. # The spatial predicate portion of Common Query Language created (CQL) by OGC (or [ECQL|http://docs.geoserver.org/latest/en/user/filter/ecql_reference.html#spatial-predicate] (Extended CQL) as defined by Geoserver)). Notably has DWITHIN, BBOX, and BEYOND, as well as the usual suspects. A better spatial query parser - Key: SOLR-4242 URL: https://issues.apache.org/jira/browse/SOLR-4242 Project: Solr Issue Type: New Feature Components: query parsers Reporter: David Smiley Fix For: 4.2 I've been thinking about how spatial support is exposed to Solr users. Presently there's the older Solr 3 stuff, most prominently seen via \{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks like mygeofield:Intersects(Circle(1 2 d=3)) What's inside the outer parenthesis is parsed by Spatial4j as a shape, and it has a special (non-standard) syntax for points, rects, and circles, and then there's WKT. I believe this scheme was devised by [~ryantxu]. I'd like to devise something that is both comprehensive and is aligned with standards to the extent that it's prudent. The old Solr 3 stuff is not comprehensive and not standardized. The newer stuff is comprehensive but only a little based on standards. And I think it'd be nicer to implement it as a Solr query parser. I'll say more in the comments. -- 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-4229) Swappable (introduced in 1028) is confusing. Change the name
[ https://issues.apache.org/jira/browse/SOLR-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540997#comment-13540997 ] Commit Tag Bot commented on SOLR-4229: -- [branch_4x commit] Erick Erickson http://svn.apache.org/viewvc?view=revisionrevision=1426832 merge to 4x of SOLR-4229 (rename swappable to transient for cores that can come and go) Swappable (introduced in 1028) is confusing. Change the name -- Key: SOLR-4229 URL: https://issues.apache.org/jira/browse/SOLR-4229 Project: Solr Issue Type: Improvement Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-4229.patch the new tag swappable, introduced in SOLR-1028 is too easily confused with swapping cores. Rename to dynamic? transient? I think transient captures the notion best. Marking blocker just because I want to insure it's changed before the whole notion is released the first time, patch real soon now. I think we can justify changing the names of things like this more easily before it's in official circulation. -- 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-4229) Swappable (introduced in 1028) is confusing. Change the name
[ https://issues.apache.org/jira/browse/SOLR-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-4229. -- Resolution: Fixed The commit tag bot is neat! Swappable (introduced in 1028) is confusing. Change the name -- Key: SOLR-4229 URL: https://issues.apache.org/jira/browse/SOLR-4229 Project: Solr Issue Type: Improvement Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-4229.patch the new tag swappable, introduced in SOLR-1028 is too easily confused with swapping cores. Rename to dynamic? transient? I think transient captures the notion best. Marking blocker just because I want to insure it's changed before the whole notion is released the first time, patch real soon now. I think we can justify changing the names of things like this more easily before it's in official circulation. -- 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
Bug or improvement - default for mlt.count changed from 5 in 4.0 to 20 in 4.x
I’m curious whether the change in the default value for the mlt.count parameter from 5 in 4.0 to 20 in 4.x is an intentional change or simply a bug that needs to be fixed. I mean, there is no mention in CHANGES.txt or Jira to note the impact on what a user will see. The change occurred for SOLR-788: https://issues.apache.org/jira/browse/SOLR-788 http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/core/src/java/org/apache/solr/handler/component/MoreLikeThisComponent.java?r1=1421333r2=1421332pathrev=1421333 -- Jack Krupansky
[jira] [Commented] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540999#comment-13540999 ] Jack Krupansky commented on SOLR-788: - I’m curious whether the change in the default value for the mlt.count parameter from 5 in 4.0 to 20 in 4.x is an intentional change or simply a bug that needs to be fixed. I mean, there is no mention in CHANGES.txt or Jira to note the impact on what a user will see. MoreLikeThis should support distributed search -- Key: SOLR-788 URL: https://issues.apache.org/jira/browse/SOLR-788 Project: Solr Issue Type: Improvement Components: MoreLikeThis Reporter: Grant Ingersoll Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, SolrMoreLikeThisPatch.txt The MoreLikeThis component should support distributed processing. See SOLR-303. -- 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-3725) package-local-src-tgz target is pulling in non-source jars, dist/** and package/**
[ https://issues.apache.org/jira/browse/SOLR-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541001#comment-13541001 ] Commit Tag Bot commented on SOLR-3725: -- [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1426839 SOLR-3725: Update velocity also in Maven package-local-src-tgz target is pulling in non-source jars, dist/** and package/** -- Key: SOLR-3725 URL: https://issues.apache.org/jira/browse/SOLR-3725 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 4.0-ALPHA Reporter: Michael Dodsworth Priority: Minor Fix For: 4.0, 5.0 Attachments: SOLR-3725.patch package-local-src-tgz generates a 141M archive which contains a bunch of non-source jars: {code} tar tfz apache-solr-4.0-SNAPSHOT-src.tgz | grep -E '(war|jar)$' | wc -l 134 {code} It looks like we're expecting dist/** and package/** to be excluded: {code:xml} tarfileset dir=. prefix=${fullnamever}/solr excludes=build ${package.dir}/** ${dist}/** example/webapps/*.war example/exampledocs/post.jar lib/README.committers.txt **/data/ **/logs/* **/*.sh **/bin/ scripts/ .idea/ **/*.iml **/pom.xml / {code} The issue is that package.dir and dist refer to absolute paths; excludes assumes relative paths. It's also pulling in all the contrib/**/lib/ and example/lib/ jars. -- 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-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541002#comment-13541002 ] Mark Miller commented on SOLR-788: -- Unintentional change. MoreLikeThis should support distributed search -- Key: SOLR-788 URL: https://issues.apache.org/jira/browse/SOLR-788 Project: Solr Issue Type: Improvement Components: MoreLikeThis Reporter: Grant Ingersoll Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, SolrMoreLikeThisPatch.txt The MoreLikeThis component should support distributed processing. See SOLR-303. -- 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] (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-788: -- MoreLikeThis should support distributed search -- Key: SOLR-788 URL: https://issues.apache.org/jira/browse/SOLR-788 Project: Solr Issue Type: Improvement Components: MoreLikeThis Reporter: Grant Ingersoll Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, MoreLikeThisComponentTest.patch, SOLR-788.patch, SOLR-788.patch, SolrMoreLikeThisPatch.txt The MoreLikeThis component should support distributed processing. See SOLR-303. -- 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-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541003#comment-13541003 ] Uwe Schindler commented on SOLR-3735: - Erik, I alsErik, I also added the new velocity version to the Maven poms. Will you backport this toSOLR-3725o added the new velocity version to the Maven poms. Will you backport this to 4.x? Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA, 4.0 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.1, 5.0 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- 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: svn commit: r1426839 - /lucene/dev/trunk/dev-tools/maven/pom.xml.template
Thanks Uwe On Dec 29, 2012 4:29 PM, uschind...@apache.org wrote: Author: uschindler Date: Sat Dec 29 21:29:05 2012 New Revision: 1426839 URL: http://svn.apache.org/viewvc?rev=1426839view=rev Log: SOLR-3725: Update velocity also in Maven Modified: lucene/dev/trunk/dev-tools/maven/pom.xml.template Modified: lucene/dev/trunk/dev-tools/maven/pom.xml.template URL: http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/pom.xml.template?rev=1426839r1=1426838r2=1426839view=diff == --- lucene/dev/trunk/dev-tools/maven/pom.xml.template (original) +++ lucene/dev/trunk/dev-tools/maven/pom.xml.template Sat Dec 29 21:29:05 2012 @@ -333,7 +333,7 @@ dependency groupIdorg.apache.velocity/groupId artifactIdvelocity/artifactId -version1.6.4/version +version1.7/version /dependency dependency groupIdorg.apache.velocity/groupId
[jira] [Created] (SOLR-4243) dataimporter -- option to clear/reset status screen
Shawn Heisey created SOLR-4243: -- Summary: dataimporter -- option to clear/reset status screen Key: SOLR-4243 URL: https://issues.apache.org/jira/browse/SOLR-4243 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Shawn Heisey Priority: Minor Fix For: 4.2, 5.0 I would like to see an option to clear/reset the DIH status screen to its never been run state. If the current status of the handler is 'busy' this should probably do nothing, and perhaps should even throw an exception that could be seen by SolrJ and visible in a browser window, in the same manner as the PingRequestHandler when the health-check file is missing. -- 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-982) Log based real-time replication with single master
[ https://issues.apache.org/jira/browse/SOLR-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541007#comment-13541007 ] Shawn Heisey commented on SOLR-982: --- SolrCloud implements much or all of this. This issue needs either closing or refining. Log based real-time replication with single master -- Key: SOLR-982 URL: https://issues.apache.org/jira/browse/SOLR-982 Project: Solr Issue Type: New Feature Components: replication (java) Reporter: Shalin Shekhar Mangar Fix For: 4.2, 5.0 This issue aims to add a real-time log based replication. The goal is to have the slave lag as less as possible after updates to the master by capturing the update commands in master and re-playing them on slaves. This will also pave the way for real-time search when Lucene adds those capabilities. -- 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-3343) Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541011#comment-13541011 ] Ingo Renner commented on LUCENE-3343: - if it's in 4.1 as stated, that seems fine. Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser Key: LUCENE-3343 URL: https://issues.apache.org/jira/browse/LUCENE-3343 Project: Lucene - Core Issue Type: New Feature Components: modules/queryparser Reporter: Olivier Favre Assignee: Adriano Crestani Priority: Minor Labels: parser, query Fix For: 4.1 Attachments: NumCompQueryParser-3x.patch, NumCompQueryParser.patch Original Estimate: 96h Remaining Estimate: 96h To offer better interoperability with other search engines and to provide an easier and more straight forward syntax, the operators , =, , = and = should be available to express an open range query. They should at least work for numeric queries. '=' can be made a synonym for ':'. -- 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-3343) Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541015#comment-13541015 ] Jack Krupansky commented on LUCENE-3343: To avoid confusion, it should be explicitly noted that this change applies only to the Lucene flexible query parser, and NOT to the classic Lucene query parser and hence not to any of the Solr plugin query parsers that are derived from the classic Lucene query parser. Maybe the title should say Flexible QueryParser. Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser Key: LUCENE-3343 URL: https://issues.apache.org/jira/browse/LUCENE-3343 Project: Lucene - Core Issue Type: New Feature Components: modules/queryparser Reporter: Olivier Favre Assignee: Adriano Crestani Priority: Minor Labels: parser, query Fix For: 4.1 Attachments: NumCompQueryParser-3x.patch, NumCompQueryParser.patch Original Estimate: 96h Remaining Estimate: 96h To offer better interoperability with other search engines and to provide an easier and more straight forward syntax, the operators , =, , = and = should be available to express an open range query. They should at least work for numeric queries. '=' can be made a synonym for ':'. -- 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-3343) Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541019#comment-13541019 ] Yonik Seeley commented on LUCENE-3343: -- There was always a lot of talk in the past of deprecating / removing the old/classic lucene query parser. I always objected to that in the past due to Solr's use of the parser, but now that solr has it's own, it may make sense to revisit that. Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser Key: LUCENE-3343 URL: https://issues.apache.org/jira/browse/LUCENE-3343 Project: Lucene - Core Issue Type: New Feature Components: modules/queryparser Reporter: Olivier Favre Assignee: Adriano Crestani Priority: Minor Labels: parser, query Fix For: 4.1 Attachments: NumCompQueryParser-3x.patch, NumCompQueryParser.patch Original Estimate: 96h Remaining Estimate: 96h To offer better interoperability with other search engines and to provide an easier and more straight forward syntax, the operators , =, , = and = should be available to express an open range query. They should at least work for numeric queries. '=' can be made a synonym for ':'. -- 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-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-3180: --- Attachment: CMSL_fail1.log Progress! Here's my analysis of one of the failures where the control doesn't match the cloud: {code} 2 115826 T24 C12 P44177 /update {wt=javabinversion=2} {add=[50247 (1422479033427296256)]} 0 11 2 145877 T61 C4 P38042 /update {wt=javabinversion=2} {add=[50247 (1422479064932810752)]} 0 17 2 146263 T26 C12 P44177 /update {wt=javabinversion=2} {delete=[50247 (-1422479065354338304)]} 0 0 2 146268 T63 C4 P38042 /update {wt=javabinversion=2} {delete=[50247 (-1422479065356435456)]} 0 3 2 146867 T46 C1 P60593 /update {wt=javabinversion=2} {add=[50247]} 0 31033 2 ## Only in cloudDocList: [{id=50247}] 2 190158 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE controlClient :{numFound=0,start=0,docs=[]} 2cloudClient :{numFound=1,start=0,docs=[SolrDocument{id=50247, _version_=1422479065981386752}]} NOTE: The version we found does not match any version previously added, and it does come logically after the last delete! {code} ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt, fail.inconsistent.txt, test_report_1.txt Handle intermittent failures in the ChaosMonkey tests. -- 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-2357) Thread Local memory leaks on restart
[ https://issues.apache.org/jira/browse/SOLR-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541023#comment-13541023 ] Ahmet Arslan commented on SOLR-2357: I am also started to get the following error after a tomcat restart. (I increased ram buffer size and enabled jmx) {code} SEVERE: The web application [/solr] created a ThreadLocal with key of type [org.apache.solr.schema.DateField.ThreadLocalDateFormat] (value [org.apache.solr.schema.DateField$ThreadLocalDateFormat@6aec873d]) and a value of type [org.apache.solr.schema.DateField.ISO8601CanonicalDateFormat] (value [org.apache.solr.schema.DateField$ISO8601CanonicalDateFormat@6b2ed43a]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Dec 30, 2012 1:15:44 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks {code} Not sure this is related with this but I see these too: {code} Dec 30, 2012 1:16:08 AM org.apache.catalina.session.StandardManager doLoad SEVERE: IOException while loading persisted sessions: java.io.EOFException java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779) at java.io.ObjectInputStream.init(ObjectInputStream.java:279) at org.apache.catalina.util.CustomObjectInputStream.init(CustomObjectInputStream.java:58) at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:246) at org.apache.catalina.session.StandardManager.load(StandardManager.java:204) at org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:491) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5294) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1100) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1618) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) {code} {code} Dec 30, 2012 1:16:08 AM org.apache.catalina.session.StandardManager startInternal SEVERE: Exception loading sessions from persistent storage java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779) at java.io.ObjectInputStream.init(ObjectInputStream.java:279) at org.apache.catalina.util.CustomObjectInputStream.init(CustomObjectInputStream.java:58) at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:246) at org.apache.catalina.session.StandardManager.load(StandardManager.java:204) at org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:491) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5294) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:618) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1100) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1618) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at
[jira] [Commented] (LUCENE-3343) Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541024#comment-13541024 ] Jack Krupansky commented on LUCENE-3343: And that begs the question of whether Solr itself should consider moving over to the flexible query parser. Is there a Jira for that (since that's where this discussion should go)? Comparison operators ,=,,= and = support as RangeQuery syntax in QueryParser Key: LUCENE-3343 URL: https://issues.apache.org/jira/browse/LUCENE-3343 Project: Lucene - Core Issue Type: New Feature Components: modules/queryparser Reporter: Olivier Favre Assignee: Adriano Crestani Priority: Minor Labels: parser, query Fix For: 4.1 Attachments: NumCompQueryParser-3x.patch, NumCompQueryParser.patch Original Estimate: 96h Remaining Estimate: 96h To offer better interoperability with other search engines and to provide an easier and more straight forward syntax, the operators , =, , = and = should be available to express an open range query. They should at least work for numeric queries. '=' can be made a synonym for ':'. -- 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-3450) CoreAdminHandler.handleStatusAction
[ https://issues.apache.org/jira/browse/SOLR-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541027#comment-13541027 ] Ahmet Arslan commented on SOLR-3450: I get this after an improper shutdown of tomcat. I have this auto*Commit settings. {code:xml} autoCommit maxTime10/maxTime /autoCommit autoSoftCommit maxTime1000/maxTime /autoSoftCommit {code} {code} Dec 28, 2012 10:58:27 PM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException: Error handling 'status' action at org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:483) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:139) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:306) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:180) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.IllegalArgumentException: /mnt/solr_tomcat/example/Cores/Prod/xxxprod/data/index/_2ksbf.tvx does not exist at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2053) at org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089) at org.apache.solr.handler.admin.CoreAdminHandler.getIndexSize(CoreAdminHandler.java:586) at org.apache.solr.handler.admin.CoreAdminHandler.getCoreStatus(CoreAdminHandler.java:571) at org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:474) ... 20 more {code} CoreAdminHandler.handleStatusAction --- Key: SOLR-3450 URL: https://issues.apache.org/jira/browse/SOLR-3450 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA Environment: Linux version 2.6.32-29-server (buildd@allspice) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #58-Ubuntu SMP Fri Feb 11 21:06:51 UTC 2011 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Reporter: Trym Møller Priority: Minor May 8, 2012 12:49:49 PM org.apache.solr.common.SolrException log SEVERE: org.apache.solr.common.SolrException: Error handling 'status' action at org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:551) at org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:161) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:360) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:173) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at
Re: DirectSpellChecker.suggestSimilar() scans TermEnum. but why?
On Sat, Dec 29, 2012 at 9:58 AM, Mikhail Khludnev mkhlud...@griddynamics.com wrote: Happy New Year, Devs! Excuse me for the noob's question. I'm not able to get deep into FST internals. I run trivial benchmark and not really enjoyed by the results. I'm looking for the ultra-fast spelling correction. Right now I use 3.x SpellChecker which is backed on separate Lucene Ngram index.FWIW, it's persistent, not in RAMDirectory. Now the bottleneck is I/O. Reading that Lucene Ngram index takes too much time. I guess it might be solved by loading Lucene Ngram index into RAMDirectory, but I want to exploit FST spell check from 4.0. What I see, and what makes me wonder. Every DirectSpellChecker.suggestSimilar() creates new FuzzyTermsEnum and every time it scans the termsEnum by FilteredTermsEnum.next(). And here I hit the same slow IO bummer. It might be necessary detail: I read 3.x index by 4.0 code. I don't think it changes something. Actually, it does: when 4.x reads a 3.x index it has some non-trivial code to handle the reordering of terms from UTF16 to Unicode sort order. So before concluding anything about the results you should test on a new 4.0 index ... I don't know anything about FST, but I've thought that it's a compact graph of syllables, which is visited for finding string similar to the given i.e. I expect it won't scan termsEnum for every lookup. It would be possible to create an FST and do fuzzy lookup directly from that ... to approximate that you could try using MemoryPostingsFormat (stores all tersm + docs in an FST). That should avoid all IO (assuming your OS never swaps out your process RAM ;) ), but it will be a (maybe sizable) lower bound on the perf you'd get with a dedicated Fuzzy search on an FST ... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2357) Thread Local memory leaks on restart
[ https://issues.apache.org/jira/browse/SOLR-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541030#comment-13541030 ] Ahmet Arslan commented on SOLR-2357: My restart was an improper shutdown of tomcat. By the way I don't use solr cell. Thread Local memory leaks on restart Key: SOLR-2357 URL: https://issues.apache.org/jira/browse/SOLR-2357 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction), search Affects Versions: 1.4.1 Environment: Windows Server 2008, Apache Tomcat 7.0.8, Java 1.6.23 Reporter: Gus Heck Labels: memory_leak, threadlocal Restarting solr (via a changed to a watched resource or via manager app for example) after submitting documents with Solr-Cell, gives the following message (many many times), and causes Tomcat to shutdown completely. SEVERE: The web application [/solr] created a ThreadLocal with key of type [org. apache.solr.common.util.DateUtil.ThreadLocalDateFormat] (value [org.apache.solr. common.util.DateUtil$ThreadLocalDateFormat@dc30dfa]) and a value of type [java.t ext.SimpleDateFormat] (value [java.text.SimpleDateFormat@5af7aed5]) but failed t o remove it when the web application was stopped. Threads are going to be renewe d over time to try and avoid a probable memory leak. Feb 10, 2011 7:17:53 AM org.apache.catalina.loader.WebappClassLoader checkThread LocalMapForLeaks -- 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-4244) When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader.
Mark Miller created SOLR-4244: - Summary: When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader. Key: SOLR-4244 URL: https://issues.apache.org/jira/browse/SOLR-4244 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0, 4.0-BETA, 4.0-ALPHA Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 -- 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-3180) ChaosMonkey test failures
[ https://issues.apache.org/jira/browse/SOLR-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541020#comment-13541020 ] Yonik Seeley edited comment on SOLR-3180 at 12/30/12 2:27 AM: -- Progress! Here's my analysis of one of the failures where the control doesn't match the cloud: {code} 2 115826 T24 C12 P44177 /update {wt=javabinversion=2} {add=[50247 (1422479033427296256)]} 0 11 2 145877 T61 C4 P38042 /update {wt=javabinversion=2} {add=[50247 (1422479064932810752)]} 0 17 2 146263 T26 C12 P44177 /update {wt=javabinversion=2} {delete=[50247 (-1422479065354338304)]} 0 0 2 146268 T63 C4 P38042 /update {wt=javabinversion=2} {delete=[50247 (-1422479065356435456)]} 0 3 2 146867 T46 C1 P60593 /update {wt=javabinversion=2} {add=[50247]} 0 31033 2 ## Only in cloudDocList: [{id=50247}] 2 190158 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE controlClient :{numFound=0,start=0,docs=[]} 2cloudClient :{numFound=1,start=0,docs=[SolrDocument{id=50247, _version_=1422479065981386752}]} NOTE: The version we found does not match any version previously added, and it does come logically after the last delete! {code} edit: the upshot is that it looks like there's a real bug here somewhere - this is not just a test issue. was (Author: ysee...@gmail.com): Progress! Here's my analysis of one of the failures where the control doesn't match the cloud: {code} 2 115826 T24 C12 P44177 /update {wt=javabinversion=2} {add=[50247 (1422479033427296256)]} 0 11 2 145877 T61 C4 P38042 /update {wt=javabinversion=2} {add=[50247 (1422479064932810752)]} 0 17 2 146263 T26 C12 P44177 /update {wt=javabinversion=2} {delete=[50247 (-1422479065354338304)]} 0 0 2 146268 T63 C4 P38042 /update {wt=javabinversion=2} {delete=[50247 (-1422479065356435456)]} 0 3 2 146867 T46 C1 P60593 /update {wt=javabinversion=2} {add=[50247]} 0 31033 2 ## Only in cloudDocList: [{id=50247}] 2 190158 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE controlClient :{numFound=0,start=0,docs=[]} 2cloudClient :{numFound=1,start=0,docs=[SolrDocument{id=50247, _version_=1422479065981386752}]} NOTE: The version we found does not match any version previously added, and it does come logically after the last delete! {code} ChaosMonkey test failures - Key: SOLR-3180 URL: https://issues.apache.org/jira/browse/SOLR-3180 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Yonik Seeley Attachments: CMSL_fail1.log, CMSL_hang_2.txt, CMSL_hang.txt, fail.inconsistent.txt, test_report_1.txt Handle intermittent failures in the ChaosMonkey tests. -- 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-4244) When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader.
[ https://issues.apache.org/jira/browse/SOLR-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541042#comment-13541042 ] Commit Tag Bot commented on SOLR-4244: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1426892 SOLR-4244: When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader. When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader. -- Key: SOLR-4244 URL: https://issues.apache.org/jira/browse/SOLR-4244 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 -- 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-4245) When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time.
Mark Miller created SOLR-4245: - Summary: When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. Key: SOLR-4245 URL: https://issues.apache.org/jira/browse/SOLR-4245 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 The sub calls to get the leader had a 30 second wait which effectively short circuits the top level timeout with regards to waiting for an initial leader. Not a big deal in smaller clusters, but can end up as problem with larger clusters where a node might timeout and need to be restarted. -- 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-4244) When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader.
[ https://issues.apache.org/jira/browse/SOLR-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541043#comment-13541043 ] Commit Tag Bot commented on SOLR-4244: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1426893 SOLR-4244: When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader. When coming back from session expiration we should not wait for the leader to see us in the down state if we are the node that must become the leader. -- Key: SOLR-4244 URL: https://issues.apache.org/jira/browse/SOLR-4244 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-ALPHA, 4.0-BETA, 4.0 Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.1, 5.0 -- 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-4245) When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time.
[ https://issues.apache.org/jira/browse/SOLR-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541044#comment-13541044 ] Mark Miller commented on SOLR-4245: --- Committed as 1426795 on trunk and 1426796 on 4x. Changes entries coming. When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. - Key: SOLR-4245 URL: https://issues.apache.org/jira/browse/SOLR-4245 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 The sub calls to get the leader had a 30 second wait which effectively short circuits the top level timeout with regards to waiting for an initial leader. Not a big deal in smaller clusters, but can end up as problem with larger clusters where a node might timeout and need to be restarted. -- 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-4245) When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time.
[ https://issues.apache.org/jira/browse/SOLR-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541045#comment-13541045 ] Commit Tag Bot commented on SOLR-4245: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1426898 SOLR-4245: When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. - Key: SOLR-4245 URL: https://issues.apache.org/jira/browse/SOLR-4245 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 The sub calls to get the leader had a 30 second wait which effectively short circuits the top level timeout with regards to waiting for an initial leader. Not a big deal in smaller clusters, but can end up as problem with larger clusters where a node might timeout and need to be restarted. -- 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-4245) When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time.
[ https://issues.apache.org/jira/browse/SOLR-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4245. --- Resolution: Fixed When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. - Key: SOLR-4245 URL: https://issues.apache.org/jira/browse/SOLR-4245 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 The sub calls to get the leader had a 30 second wait which effectively short circuits the top level timeout with regards to waiting for an initial leader. Not a big deal in smaller clusters, but can end up as problem with larger clusters where a node might timeout and need to be restarted. -- 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-4245) When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time.
[ https://issues.apache.org/jira/browse/SOLR-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541046#comment-13541046 ] Commit Tag Bot commented on SOLR-4245: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revisionrevision=1426899 SOLR-4245: When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. When a core is registering with ZooKeeper, the timeout to find the leader in the cluster state is 30 seconds rather than leaderVoteWait + extra time. - Key: SOLR-4245 URL: https://issues.apache.org/jira/browse/SOLR-4245 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.1, 5.0 The sub calls to get the leader had a 30 second wait which effectively short circuits the top level timeout with regards to waiting for an initial leader. Not a big deal in smaller clusters, but can end up as problem with larger clusters where a node might timeout and need to be restarted. -- 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-2592) Custom Hashing
[ https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541048#comment-13541048 ] Shreejay commented on SOLR-2592: {quote}Right - I've made good progress on that front in trunk, and we'll figure out how to get it ported back to 4x. I'm in the process of adding more tests right now. The separator: I went with ! by default since it doesn't require URL encoding, but is less common than underscore. It also reminded me of the bang paths of old-style UUCP email addresses (like bigco!user).{quote} Can the separator be provided as an option instead of being hard coded? I have been using Michaels patch and now I am trying to move to 4.1. But I will have to re-index all my data by changing the unique key, which right now contains a underscore. If not, will changing the separator to a underscore in CompositeIdRouter.java be enough? --Shreejay Custom Hashing -- Key: SOLR-2592 URL: https://issues.apache.org/jira/browse/SOLR-2592 Project: Solr Issue Type: New Feature Components: SolrCloud Affects Versions: 4.0-ALPHA Reporter: Noble Paul Assignee: Yonik Seeley Fix For: 4.1 Attachments: dbq_fix.patch, pluggable_sharding.patch, pluggable_sharding_V2.patch, SOLR-2592_collectionProperties.patch, SOLR-2592_collectionProperties.patch, SOLR-2592.patch, SOLR-2592_progress.patch, SOLR-2592_query_try1.patch, SOLR-2592_r1373086.patch, SOLR-2592_r1384367.patch, SOLR-2592_rev_2.patch, SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch If the data in a cloud can be partitioned on some criteria (say range, hash, attribute value etc) It will be easy to narrow down the search to a smaller subset of shards and in effect can achieve more efficient search. -- 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