[jira] [Updated] (SOLR-4230) Enhance geofilt and bbox parsers to support Solr 4 spatial field types

2012-12-29 Thread David Smiley (JIRA)

 [ 
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

2012-12-29 Thread Tommaso Teofili (JIRA)

 [ 
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/**

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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

2012-12-29 Thread Erik Hatcher (JIRA)

[ 
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

2012-12-29 Thread Erik Hatcher (JIRA)

 [ 
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

2012-12-29 Thread Erik Hatcher (JIRA)

 [ 
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!

2012-12-29 Thread Policeman Jenkins Server
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!

2012-12-29 Thread Policeman Jenkins Server
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

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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!

2012-12-29 Thread Policeman Jenkins Server
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!

2012-12-29 Thread Policeman Jenkins Server
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?

2012-12-29 Thread Mikhail Khludnev
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

[ 
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.

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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.

2012-12-29 Thread Mark Miller (JIRA)

[ 
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

2012-12-29 Thread Mark Miller
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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)

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Shawn Heisey (JIRA)

[ 
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

2012-12-29 Thread David Smiley (JIRA)

 [ 
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

2012-12-29 Thread Shawn Heisey (JIRA)

 [ 
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

2012-12-29 Thread Yonik Seeley (JIRA)

 [ 
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

2012-12-29 Thread Apache Jenkins Server
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

2012-12-29 Thread David Smiley (JIRA)
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

2012-12-29 Thread Shawn Heisey (JIRA)

[ 
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

2012-12-29 Thread Shawn Heisey (JIRA)

 [ 
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

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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

2012-12-29 Thread Shawn Heisey (JIRA)

 [ 
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

2012-12-29 Thread Jack Krupansky (JIRA)

[ 
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

2012-12-29 Thread David Smiley (JIRA)

[ 
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

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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

2012-12-29 Thread Erick Erickson (JIRA)

 [ 
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

2012-12-29 Thread Jack Krupansky
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

2012-12-29 Thread Jack Krupansky (JIRA)

[ 
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/**

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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

2012-12-29 Thread Mark Miller (JIRA)

[ 
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

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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

2012-12-29 Thread Uwe Schindler (JIRA)

[ 
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

2012-12-29 Thread Steve Rowe
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

2012-12-29 Thread Shawn Heisey (JIRA)
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

2012-12-29 Thread Shawn Heisey (JIRA)

[ 
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

2012-12-29 Thread Ingo Renner (JIRA)

[ 
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

2012-12-29 Thread Jack Krupansky (JIRA)

[ 
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

2012-12-29 Thread Yonik Seeley (JIRA)

[ 
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

2012-12-29 Thread Yonik Seeley (JIRA)

 [ 
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

2012-12-29 Thread Ahmet Arslan (JIRA)

[ 
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

2012-12-29 Thread Jack Krupansky (JIRA)

[ 
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

2012-12-29 Thread Ahmet Arslan (JIRA)

[ 
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?

2012-12-29 Thread Michael McCandless
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

2012-12-29 Thread Ahmet Arslan (JIRA)

[ 
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.

2012-12-29 Thread Mark Miller (JIRA)
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

2012-12-29 Thread Yonik Seeley (JIRA)

[ 
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.

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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.

2012-12-29 Thread Mark Miller (JIRA)
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.

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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.

2012-12-29 Thread Mark Miller (JIRA)

[ 
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.

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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.

2012-12-29 Thread Mark Miller (JIRA)

 [ 
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.

2012-12-29 Thread Commit Tag Bot (JIRA)

[ 
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

2012-12-29 Thread Shreejay (JIRA)

[ 
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