date:20130402


 [ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-4661:
---

Attachment: hoss_test.zip

bq. Step to reproduce this issue is simple. Just apply commit on master without 
posting any documents

Ah... ok, wait a minute - this looks promising.  in reviewing the logs you sent 
to solr-user@lucene i didn't notice that this empty commit was happening, but 
in attempting to reproduce i think i see what you're talking about.

Steps i followed...


{panel}
1) took the Solr 4.2 example/solr dir and cloned it as master-home

2) edited the /replication handler to match what you posted in this issue (but 
adjusted the replicaiton time to 30 seconds for a faster test)

3) cloned master-home as slave-home

4) ran two instances of Solr 4.2 using hte following commands...

{noformat}
java -Denable.master=true -Dmaster.port=8999 -Djetty.port=8999 
-Dsolr.solr.home=/home/hossman/tmp/ave_version_higher/master-home -jar 
start.jar  /home/hossman/tmp/slave_version_higher/master.log
java -Denable.slave=true -Dmaster.port=899-Djetty.port= 
-Dsolr.solr.home=/home/hossman/tmp/slave_version_higher/slave-home -jar 
start.jar  /home/hossman/tmp/slave_version_higher/slave.log
{noformat}

5) ran two scripts to monitor replication details using the following 
commands...

{noformat}
while true; do date --utc  curl -sS 
http://localhost:/solr/collection1/replication?command=detailsindent=truewt=json;
  echo  echo  sleep 2; done  slave_rep_details.txt
while true; do date --utc  curl -sS 
http://localhost:8999/solr/collection1/replication?command=detailsindent=truewt=json;
  echo  echo  sleep 2; done  master_rep_details.txt
{noformat}

6) triggered an indexing of all the example docs on master, and waited for 
replication.

{noformat}
java -Durl=http://localhost:8999/solr/collection1/update -jar post.jar *.xml
{noformat}

7) triggered an explicit commit on master...

{noformat}
java -Durl=http://localhost:8999/solr/collection1/update -jar post.jar -
{noformat}

8) shutdown both servers and the scripts (Ctrl-C)
{panel}

I've attached the full logs and home dirs at the completion of this test, but 
as a summmary of the results...

{panel}
a) slave  master index files are identical except for segments.gen

b) the master's replication details indicate that the current commit being used 
is indexVersion#1364927050819, generation#2 but it's list of commits does not 
include this, it contains a single commit of indexVersion#1364927114002, 
generation#3

c) the slave's replication details indicate that the current commit being used 
is indexVersion#1364927050819, generation#2 and that this is the only commit 
it has locally.  The slave's information about hte master is consistent with 
what the master itself reports.
{panel}

I'm not certain, but I believe this is just an optimization where the searcher 
is not re-opened when the currently opened commit is identical to the new 
commit -- this optimization is working on the master, but aparently not on the 
slave (maybe the slave can't tell that the commits are identical?)  

FWIW: after running this test, i restarted the master and it's replication 
details were consistent with the list of commit points -- it was using 
generation #3.   
You can also observe the exact same behavior from master's replication details 
(current generation lower then the generation of any commit point) if you do a 
hard commit with openSearcher=false.  



I think most of the behavior here makes sense -- the slave is replicating the 
commits from the master, even if the master isn't using them yet because it 
hasn't opened a new searcher.  The key questions i wonder about:

1) why was segments.get different when i ran my experiment? is that normal?
2) Assuming i'm correct about their being an optimization to not open a new 
searcher if the commits are identical, can we make this same optimization work 
on slaves in the case of replication?





 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620143#comment-13620143
]

Erick Erickson commented on SOLR-4662:
--

bq: so that solr.solr.home isn't cluttered

I'm not sure about this either. There's no assumption when walking the tree
that any instancedirs appear as immediate children of solr_home, you can have
as many levels to the tree as you want. What _is_ enforced is that when a
core.properties file is found, Solr doesn't look any deeper. In other words
there is no nesting of cores allowed. You can mix-and-match the level down the
tree where the core is defined, subject to the above rule.

So you could have a tree with only one directory in solr_home that was the root
of a tree with all your cores like:

solr_home cores
level1a
level1.1
core1.1.1
core1.1.2
core1.1.3
level1.2
core2.1.1
core2.1.2
level2a
core2a.1.1

I'm not totally anti the idea, but would rather not start putting a bunch of
stuff back into solr.xml if we can help it. Can this be made to work in your
use-case or is there another reason besides clutter you'd want to root the
cores someplace other than solr_home? Being able to cleanly separate the
running solr from the data does come to mind, i.e. I might like to rm -rf
solr_home and put in a new release without touching my data.

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Key: SOLR-4662
URL: https://issues.apache.org/jira/browse/SOLR-4662
Project: Solr
Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]]

2013-04-02 Thread Uwe Schindler

Hi,

I restarted Jenkins master with slightly more permgen. I am not sure if this is 
the slave or the master having the problems. If it does not help I will raise 
permgen on slaves. 

Currently Jenkins has a problem with too many tests, too. We currently need 
-Xmx2048M on the master, because whenever you display the test results of a 
build, the garbage collector drives crazy and takes 200% CPU. There seems to be 
a memory leak in the Jenkins XML parser (DOM tree not streaming!!! -- horrible, 
maybe we have now too many tests for Jenkins, at least it does not scale well). 
If this stays broken, I will disable test result analysis, which disables all 
nice graphs, and also no longer displays failed tests in mails :(

In addition: I installed JDK 8 b83, which has the G1 garbage collector bug 
making the full GC hang fixed (thanks to Dawid Weiss and John Cuthbertson). I 
removed the extra stack size JVM option used as workaround for 32 bit builds. 
The changelog, explicitly mentioning Apache Lucene, is here: 
http://download.java.net/jdk8/changes/jdk8-b83.html

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
 Sent: Tuesday, April 02, 2013 8:46 PM
 To: dev@lucene.apache.org; dsmi...@apache.org; er...@apache.org
 Subject: [JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing
 ENV. Please report this as a bug. ]]
 
 {{ java.lang.NullPointerException }})
  - Build # 2709 - Failure!
 MIME-Version: 1.0
 Content-Type: multipart/mixed;
   boundary==_Part_96_1462925234.1364928350913
 X-Jenkins-Job: Lucene-Solr-trunk-Windows
 X-Jenkins-Result: FAILURE
 Precedence: bulk
 
 --=_Part_96_1462925234.1364928350913
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2709/
 Java: [[ Exception while replacing ENV. Please report this as a bug. ]] {{
 java.lang.NullPointerException }}
 
 No tests ran.
 
 Build Log:
 [...truncated 145 lines...]
 FATAL: null
 java.io.IOException
   at
 hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:17
 5)
   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
   at java.io.InputStreamReader.read(InputStreamReader.java:184)
   at java.io.Reader.read(Reader.java:140)
   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1128)
   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1104)
   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1050)
   at org.apache.commons.io.IOUtils.toString(IOUtils.java:359)
   at hudson.FilePath.readToString(FilePath.java:1557)
   at
 hudson.tools.DownloadFromUrlInstaller.isUpToDate(DownloadFromUrlInstal
 ler.java:45)
   at
 hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFrom
 UrlInstaller.java:69)
   at
 hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61)
   at
 hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodePr
 operty.java:107)
   at
 hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:203)
   at hudson.tasks.Ant$AntInstallation.forNode(Ant.java:375)
   at hudson.tasks.Ant.perform(Ant.java:151)
   at
 hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at
 hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.
 java:798)
   at hudson.model.Build$BuildExecution.build(Build.java:199)
   at hudson.model.Build$BuildExecution.doRun(Build.java:160)
   at
 hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:
 580)
   at hudson.model.Run.execute(Run.java:1575)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at
 hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:237)
 
 
 --=_Part_96_1462925234.1364928350913--
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620148#comment-13620148
 ] 

Mark Miller commented on SOLR-4661:
---

The slave will actually do a reload if conf files are being replicated - so 
it's sure to open a new searcher currently. They generally shouldn't change 
every time though. It's a surprise that the master wouldn't open a new searcher 
- not sure where that would get short circuited - would have to dig a little.

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing

2013-04-02 Thread Uwe Schindler

Hi John,

today I installed JDK8 b83 on one of the Jenkins build servers used by Apache 
Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the 
trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So 
I was able to re-enable 32 bit builds without the extra workaround stacksize 
option again.

Thanks for fixing this issue.

Uwe

-
Uwe Schindler
uschind...@apache.org 
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/

 -Original Message-
 From: hotspot-gc-dev-boun...@openjdk.java.net [mailto:hotspot-gc-dev-
 boun...@openjdk.java.net] On Behalf Of john.cuthbert...@oracle.com
 Sent: Tuesday, March 19, 2013 2:21 AM
 To: hotspot-gc-...@openjdk.java.net
 Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
 during reference processing
 
 Changeset: fa08949fe0cb
 Author:johnc
 Date:  2013-03-18 11:05 -0700
 URL:   http://hg.openjdk.java.net/hsx/hotspot-
 gc/hotspot/rev/fa08949fe0cb
 
 8009536: G1: Apache Lucene hang during reference processing
 Summary: In CMTask::do_marking_step(), Skip offering termination and
 entering the first and second synchronization barriers if called from a serial
 context, i.e. the VM thread.
 Reviewed-by: brutisso, tschatzl
 
 ! src/share/vm/gc_implementation/g1/concurrentMark.cpp
 ! src/share/vm/gc_implementation/g1/concurrentMark.hpp


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620174#comment-13620174
 ] 

Hoss Man commented on SOLR-4661:


bq. Assuming i'm correct about their being an optimization to not open a new 
searcher if the commits are identical,

I did some more experimenting and confirmed i was wrong about this -- from 
Solr's perspective a new searcher is definitely getting opened and warmed.

I'm not sure, but skimming the code I *think* this discrepancy between the 
commit point in use and the commit point on disk may just be a result of using  
DirectoryReader.openIfChanged in SolrCore.openNewSearcher ... i got lost a bit 
in the code, but is it possible the reader DirectoryReader is returning null 
because only the generation changed by the comment, but not any of the actual 
indexed data?

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT

Michael McCandless created LUCENE-4898:
--

 Summary: Allow DirectoryReader.openIfChanged to an IndexCommit 
when reader is NRT
 Key: LUCENE-4898
 URL: https://issues.apache.org/jira/browse/LUCENE-4898
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-4898.patch

This throws an IllegalArRgumentException today, but it's easy to fix
with a small change to DirectoryReader.  This is useful to do, if you
have an NRT reader and want to open a reader against a previous commit
point while sharing the SegmentReaders they have in common.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT


 [ 
https://issues.apache.org/jira/browse/LUCENE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4898:
---

Attachment: LUCENE-4898.patch

Patch.

 Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
 

 Key: LUCENE-4898
 URL: https://issues.apache.org/jira/browse/LUCENE-4898
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
 Attachments: LUCENE-4898.patch


 This throws an IllegalArRgumentException today, but it's easy to fix
 with a small change to DirectoryReader.  This is useful to do, if you
 have an NRT reader and want to open a reader against a previous commit
 point while sharing the SegmentReaders they have in common.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT


 [ 
https://issues.apache.org/jira/browse/LUCENE-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless reassigned LUCENE-4898:
--

Assignee: Michael McCandless

 Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
 

 Key: LUCENE-4898
 URL: https://issues.apache.org/jira/browse/LUCENE-4898
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Attachments: LUCENE-4898.patch


 This throws an IllegalArRgumentException today, but it's easy to fix
 with a small change to DirectoryReader.  This is useful to do, if you
 have an NRT reader and want to open a reader against a previous commit
 point while sharing the SegmentReaders they have in common.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting

2013-04-02 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620192#comment-13620192
 ] 

Yonik Seeley commented on SOLR-3755:


Nice that this is on a git branch - no stale patches, and you can see the full 
history!

Does anyone know an easy way to generate a diff?
I did the following:
{code}
git clone https://github.com/shalinmangar/lucene-solr.git lusolr_shardsplitting
cd lusolr_shardsplitting
git remote add upstream git://git.apache.org/lucene-solr.git
git diff remotes/upstream/trunk remotes/origin/trunk
{code}

But this does a diff with the current state of the trunk vs the branch.  Any 
tips from the git wizards out there?



 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620195#comment-13620195
 ] 

Mark Miller commented on SOLR-4661:
---

It seems possible:

{code}
// If in fact no changes took place, return null:
if (reader.getVersion() == segmentInfos.getVersion()) {
  reader.decRef();
  return null;
}
{code}

version described as:

{code}
  /**
   * Version number when this IndexReader was opened.
   *
   * pThis method
   * returns the version recorded in the commit that the
   * reader opened.  This version is advanced every time
   * a change is made with {@link IndexWriter}./p
   */
{code}

version is incremented when:

{code}
  /** Call this before committing if changes have been made to the
   *  segments. */
  public void changed() {
version++;
  }
{code}

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620207#comment-13620207
 ] 

Mark Miller commented on SOLR-3755:
---

AFAIK it's somewhat annoying - usually it involves doing a squash commit on a 
tmp branch and diffing with that if you want it nicely in one file/chunk. 
Otherwise git format-patch can go back n commits and make a diff for each one 
and you'd have to stitch them together.

 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620208#comment-13620208
 ] 

Mark Miller commented on SOLR-3755:
---

bq. Was trying to look into it but strangely, I haven't run into it over 15 
consecutive runs.

It's very common for these types of tests to be sensitive to the exact env 
(hardware, OS, etc). A lot of times it's some timing issue.



 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting

2013-04-02 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620215#comment-13620215
 ] 

Anshum Gupta commented on SOLR-3755:


You'd need to do a git merge and then compare it with the current branch.
 git fetch upstream
 git merge upstream/trunk
 git diff --no-prefix upstream/trunk

This should show the diff. For now, I've just merged the current state of the 
trunk with this branch. Getting the diff now should be straight forward.


 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3755) shard splitting

2013-04-02 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620224#comment-13620224
 ] 

Anshum Gupta commented on SOLR-3755:


Mark, you're right, it seems like a timing issue. I don't think even Shalin has 
been able to to recreate it too often under the same environment. Not even with 
the same seed.

 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.


[ 
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620237#comment-13620237
 ] 

Mark Miller commented on SOLR-4662:
---

As far as xml format...I'm thinking along the lines of:

note: persistent should be removed as an option.
note: adminPath should no longer be configurable - solrcloud counts on it being 
that.
note: defaultCoreName should probably also go away if using the new format - 
it's really a back compat thing that we don't want to support long term.

{noformat}

solr


  solrcloud
str name=host127.0.0.1/str
str name=hostPort${hostPort:8983}/str
  /solrcloud

  shardHandlerFactory
  ...
/solr
{noformat}

 Finalize what we're going to do with solr.xml, auto-discovery, config sets.
 ---

 Key: SOLR-4662
 URL: https://issues.apache.org/jira/browse/SOLR-4662
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

 Spinoff from SOLR-4615, breaking it out here so we can address the changes in 
 pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

2013-04-02 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620241#comment-13620241
]

Shawn Heisey commented on SOLR-4662:

bq. There's no assumption when walking the tree that any instancedirs appear as
immediate children

That's good, and is awesome for detection of existing cores on startup, but
what about features that automatically create new core directories? This
already happens with the SolrCloud collection API, and if we implement the
configs directory for config sets that aren't stored in zookeeper, it is likely
to happen for non-Cloud deployments too.

I am aware that my statements may seem somewhat disconnected, because in some
ways they are. I'm dealing with two different Solr deployments that each have
their own needs.

1) I have a pretty small SolrCloud deployment with two servers plus a third zk
node, numShards=1. I don't implement separation here, but it's not really
needed. It currently places core directories right into solr.home, but I would
like to change that.

2) My main large Solr deployment doesn't use SolrCloud, and is not likely to
use SolrCloud in the foreseeable future. That is where I have things heavily
separated into cores, data, and config.

In a cloud/zk deployment, you get dataDir separation for free, because the core
config is elsewhere. This would also be the case with filesystem-based config
sets. We therefore might not need to worry too much about the separation idea
that I initially had, but I do think that it's important to have the cores go
into a subdirectory by default.

bq. would rather not start putting a bunch of stuff back into solr.xml if we
can help it

+1 from me on that. Anything that we can move out of that file we should -
basically make it so that only what's required at a global level to locate the
rest of the resources Solr needs, plus any server-level config options that
don't have an excellent all-purpose default. I think a 'coreDirectory' option
falls into both of those categories. In a ZK-controlled world, a lot of global
config options can be stored in ZK, but there are very good reasons to have a
different coreDirectory option on each server.

bq. I might like to rm -rf solr_home and put in a new release without
touching my data

What I do for this is completely separate solr.home and CWD (jetty.home). CWD
is /opt/solr4, solr.home is /index/solr4, and /index is a different filesystem.
There are jars for jetty and log4j in /opt/solr4/lib, and extra jars for solr,
lucene, and mysql in /index/solr4/lib.

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.

[
https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620245#comment-13620245
]

crocket commented on LUCENE-4894:
-

However, without facet user guide, I wouldn't have known that it ever existed.
You may still need to advertise the facet module in
http://lucene.apache.org/core/4_x_x/index.html

Facet User Guide for lucene 4.2 has deleted classes/methods and needs more
explanations.

Key: LUCENE-4894
URL: https://issues.apache.org/jira/browse/LUCENE-4894
Project: Lucene - Core
Issue Type: Bug
Components: general/website, modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Minor

* Concurrent Indexing and Search
There is no clear explanation regarding those points below.
1. TaxonomyReader should be reopened after IndexReader.
2. TaxonomyWriter should be committed before IndexWriter. TaxonomyWriter
should be closed before IndexWriter.
The rationale is that it's ok to see categories to which no document belongs
but not ok the other way around.
Beginners may not be able to see this until after they think through it for a
long time, which most of them including me wouldn't do.
However, facet user guide doesn't explain the rationale clearly.
* DocumentBuilder FacetSearchParams.addFacetRequest
They no longer exist in lucene 4.2, but they are used in code examples.
* FacetResultNode.getLabel(TaxonomyReader)
It doesn't eixst in 4.2, but it is mentioned in Multiple Facet Requests
* ETC
I don't know if there are other points to be made.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.

[
https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620245#comment-13620245
]

crocket edited comment on LUCENE-4894 at 4/2/13 8:29 PM:
-

However, without facet user guide, I wouldn't have known that it ever existed.
You may still need to advertise the facet module in
http://lucene.apache.org/core/4_x_x/index.html
It's good to leave an advertisement in the core index(?) page.

was (Author: crocket):
However, without facet user guide, I wouldn't have known that it ever
existed.
You may still need to advertise the facet module in
http://lucene.apache.org/core/4_x_x/index.html

Facet User Guide for lucene 4.2 has deleted classes/methods and needs more
explanations.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang during reference processing

2013-04-02 Thread John Cuthbertson


Hi Uwe,

Thanks for the update. That is good to know. The bulk of the credit goes 
to Bengt who did the initial diagnosis and the prototype fix.


Thanks also for walking me through how to reproduce the issue. Once the 
magic formula for the proxy was found - your instructions were spot on. 
The tests were awesome as marking stress tests and uncovered several 
issues associated with concurrent marking overflows. I've added them to 
the set of tests I run for marking changes. :)


Cheers,

JohnC

On 4/2/2013 12:16 PM, Uwe Schindler wrote:

Hi John,

today I installed JDK8 b83 on one of the Jenkins build servers used by Apache 
Lucene: The problem with 32 bit JVMs and G1 collector is solved. I compared the 
trunk checkout of Lucene with both JVMs: In b82 it hangs, in b83 it passes. So 
I was able to re-enable 32 bit builds without the extra workaround stacksize 
option again.

Thanks for fixing this issue.

Uwe

-
Uwe Schindler
uschind...@apache.org
Apache Lucene PMC Member / Committer
Bremen, Germany
http://lucene.apache.org/


-Original Message-
From: hotspot-gc-dev-boun...@openjdk.java.net [mailto:hotspot-gc-dev-
boun...@openjdk.java.net] On Behalf Of john.cuthbert...@oracle.com
Sent: Tuesday, March 19, 2013 2:21 AM
To: hotspot-gc-...@openjdk.java.net
Subject: hg: hsx/hotspot-gc/hotspot: 8009536: G1: Apache Lucene hang
during reference processing

Changeset: fa08949fe0cb
Author:johnc
Date:  2013-03-18 11:05 -0700
URL:   http://hg.openjdk.java.net/hsx/hotspot-
gc/hotspot/rev/fa08949fe0cb

8009536: G1: Apache Lucene hang during reference processing
Summary: In CMTask::do_marking_step(), Skip offering termination and
entering the first and second synchronization barriers if called from a serial
context, i.e. the VM thread.
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

SOLR - 1093

2013-04-02 Thread Karthick Duraisamy Soundararaj

Hello Committers,
 I had submitted a patch to the SOLR - 1093
long back and I havent gotten any feedback on the same. [
https://issues.apache.org/jira/browse/SOLR-1093 ]

We have been using it in our company and the feature has been very useful.
I see other people using it too. If someone can look at it and provide a
feedback, it would be really helpful!

Thank you,
Karthick

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.


[ 
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620263#comment-13620263
 ] 

Mark Miller commented on SOLR-4662:
---

the solrcloud host is trouble spot - it will generally be different for each 
node - if this goes in zk, that type of config is still a problem - you have to 
use sys prop substitution and require system properties for setting these 
particular settings. I'm fine with that - I think you can still easily setup a 
prop file that gets auto sucked in for sys prop substitution as well.

 Finalize what we're going to do with solr.xml, auto-discovery, config sets.
 ---

 Key: SOLR-4662
 URL: https://issues.apache.org/jira/browse/SOLR-4662
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

 Spinoff from SOLR-4615, breaking it out here so we can address the changes in 
 pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1093) A RequestHandler to run multiple queries in a batch


[ 
https://issues.apache.org/jira/browse/SOLR-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620283#comment-13620283
 ] 

David Smiley commented on SOLR-1093:


-1  If this issue is strictly about a feature in which a batch of queries are 
fully known at the time of submission, then I don't think this should be 
accepted for inclusion in Solr; sorry.  Simply submit them in parallel.

Instead, I am highly in favor of a scripting request handler in which a script 
runs that submits the searches to Solr (in-VM) and can react to the results of 
one request before making another that is formulated dynamically, and can 
assemble the response data, potentially reducing both the latency and data that 
would move over the wire if this feature didn't exist.  And if you *really* 
were bent on submitting a batch of queries that are returned in a batch, then 
you could implement that with the script.

 A RequestHandler to run multiple queries in a batch
 ---

 Key: SOLR-1093
 URL: https://issues.apache.org/jira/browse/SOLR-1093
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Noble Paul
Assignee: Simon Willnauer
 Attachments: SOLR-1093.patch


 It is a common requirement that a single page requires to fire multiple 
 queries .In cases where these queries are independent of each other. If there 
 is a handler which can take in multiple queries , run them in paralll and 
 send the response as one big chunk it would be useful
 Let us say the handler is  MultiRequestHandler
 {code}
 requestHandler name=/multi class=solr.MultiRequestHandler/
 {code}
 h2.Query Syntax
 The request must specify the no:of queries as count=n
 Each request parameter must be prefixed with a number which denotes the query 
 index.optionally ,it may can also specify the handler name.
 example
 {code}
 /multi?count=21.handler=/select1.q=a:b2.handler=/select2.q=a:c
 {code}
 default handler can be '/select' so the equivalent can be
 {code} 
 /multi?count=21.q=a:b2.q=a:c
 {code}
 h2.The response
 The response will be a ListNamedList where each NamedList will be a 
 response to a query. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620302#comment-13620302
 ] 

Yago Riveiro commented on SOLR-4584:


Only with Tomcat 7.0.35

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620312#comment-13620312
 ] 

Uwe Schindler commented on SOLR-4584:
-

Did you check with latest Tomcat 7.0? The used one 7.0..35 is no longer the 
actual one and there were some fixes regard chunked request encoding since 
7.0.35, see: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

It would be good if you could try to reproduce this with the Jetty webserver 
shipped together with Solr.

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620321#comment-13620321
 ] 

Yago Riveiro commented on SOLR-4584:


Tomorrow I will try to upgrade to the last version of tomcat. I will pull some 
data from production and set up a SolrCluster with Jetty on my local 
environment to try replicate it.

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620327#comment-13620327
 ] 

Uwe Schindler commented on SOLR-4584:
-

As said before, if you can reporduce with latest Tomcat, please also use the 
included Jetty webserver (java -jar start.jar inside example folder) to run 
Solr. If this fixes the bug, there is a chunked encoding issue in Tomcat that 
may need further investigation.

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620360#comment-13620360
 ] 

Hoss Man commented on SOLR-4661:


Some more (manual) experimentation (doing empty commits, or commits with 
openSearcher=false on the master, triggering slave replication to get the slave 
ahead and then doing subsequent changes on master  replicating again) seems 
to confirm that this situation doesn't cause any actual problem in replication 
-- just confusion when looking at the replication details.  

we can add automated tests for this type of situation to future proof ourselves 
against the risk that something like this causes problems w/replication in the 
future, but let's do that in SOLR-4629 ... i think the crux of this issue is 
really one of mitigating user confusion.

I suggest we update the admin UI to de-emphasize the comparison of the 
slave(version+generation) to master(version+generation), and instead emphasize 
a comparison of the slave(version+generation) with the 
master(replicateableVersion+replicatableGeneration).

replicatableGeneration is already available in the details, we should be able 
to add replicatableVersion easy enough.

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser

2013-04-02 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620375#comment-13620375
 ] 

Jan Høydahl commented on SOLR-4646:
---

Wait a minute - I'd argue that the default here should be false and we should 
change the code?

An example is that in Norwegian language, the word and means duck, the word 
or means alder and not means seine. The same may be true for many other 
languages, and requiring uppercase operators by default makes perfect sense.

 lowercaseOperators is enabled by default for edismax query parser
 -

 Key: SOLR-4646
 URL: https://issues.apache.org/jira/browse/SOLR-4646
 Project: Solr
  Issue Type: Bug
  Components: query parsers
Affects Versions: 4.1, 4.2
Reporter: Alexander Koval

 [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators] 
 says:
 *lowercaseOperators*
 This param controls whether to try to interpret lowercase words as boolean 
 operators such as and, not and or. Set {{lowercaseOperators=true}} to 
 allow this. Default is {{*false*}}.
 But in fact {{lowercaseOperators=true}} by default.
 And if one of boolean operators in lowercase is present in query it turns off 
 {{mm}} parameter:
 * {{q=Young+6+or+AristondefType=edismaxqf=namemm=100%25debugQuery=true}}
   {{parsedquery_toString: +((name:young) (name:6) (name:ariston))}}
 * 
 {{q=Young+6+or+AristondefType=edismaxqf=namemm=100%25lowercaseOperators=truedebugQuery=true}}
   {{parsedquery_toString: +(((name:young) (name:6) (name:ariston))~3)}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)

[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated SOLR-4652:

Attachment: SOLR-4652.patch

Hi Ryan,
I reviewed your patch, which unfortunately did no longer apply to trunk,
because there were changes in CoreContainer. As your patch was no SVN patch, my
client was not able to download the correct SVN revision number for your patch,
so I had to try out. I was then able to upgrade to latest Solr trunk.

It would be better to supply Subversion patches in the future, because they
contain the metadata required to correctly apply the patches. At least mention
the revision number in SVN it was created against.

I reverted the changes in import statements and in your test I used
assertSame() instead of assertEquals(), because the classloader must be the
same (==) not equal ones.

I will commit this soon, once all tests passed.

Resource loader has broken behavior for solr.xml plugins (basically
ShardHandlerFactory)

Key: SOLR-4652
URL: https://issues.apache.org/jira/browse/SOLR-4652
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Reporter: Ryan Ernst
Assignee: Uwe Schindler
Fix For: 4.3, 5.0

Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch

I have the following scenario:
MyShardHandlerFactory is plugged in via solr.xml. The jar containing
MyShardHandlerFactory is in the shared lib dir. There are a couple issues:
1. From within a per core handler (that is loaded within the core's lib dir),
you grab the ShardHandlerFactory from CoreContainer, casting to
MyShardHandlerFactory will results in a ClassCastException with a message
like cannot cast instance of MyShardHandlerFactory to MyShardHandlerFactory.
2. Adding a custom dir for shared lib (for example mylib) does not work.
The ShardHandlerFactory is initialized before sharedLib is loaded.
I've been pouring through the code on this and I don't see an easy fix. I'll
keep looking at it, but I wanted to get this up so hopefully others have some
thoughts on how best to fix. IMO, it seems like there needs to be a clear
chain of resource loaders (one for loading solr.xml, a child for loading the
lib dir, used for solr.xml plugins, a grandchild for per core config, and a
great grandchild for per core lib dir based plugins). Right now there are
some siblings, because any place a SolrResourceLoader is created with a null
parent classloader, it gets the jetty thread's classloader as the parent.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...

2013-04-02 Thread JIRA

[
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620415#comment-13620415
]

Jan Høydahl commented on SOLR-4653:
---

[~dweiss] logging proposal is ok.

However, a better way would be to fail hard (can be made back-compat by
checking luceneMatchVersion and log only for 4.3). In that case how we include
contrib libs should change somehow. Perhaps something like this:
{code}
lib${solr.contrib.root}/extraction/lib/lib
{code}

If user supplies -Dsolr.contrib.root=/path/to/contrib then stuff will work. If
nothing is passed by opts we could default to something that would work for the
shipped example config.

Also see my proposal in SOLR-4495. For most of my multi-core deploys I don't
bother adding lib entries to all cores, but use a single
sharedLib=$\{solr.solr.home\}/lib in solr.xml. Allowing multiple sharedLib dirs
in solr.xml would allow for more flexible config.

Solr configuration should log inaccessible/ non-existent relative paths lib
dir=...
---

Key: SOLR-4653
URL: https://issues.apache.org/jira/browse/SOLR-4653
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Attachments: SOLR-4653.patch

Currently the dir path is resolved relative to core's instanceDir but if you
don't know it nothing happens (no warning, no nothing). This is very
frustrating.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)

[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler resolved SOLR-4652.
-

Resolution: Fixed

Committed to trunk and 4.x Will be released with Lucene/Solr 4.3.

Thanks Ryan, I hope we can fix the remaining issues with chaining of
classloaders (disallowing null/context class loader as default classloader,
using webapp classloader instead of context one)!

Resource loader has broken behavior for solr.xml plugins (basically
ShardHandlerFactory)

Key: SOLR-4652
URL: https://issues.apache.org/jira/browse/SOLR-4652
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Reporter: Ryan Ernst
Assignee: Uwe Schindler
Fix For: 4.3, 5.0

Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4495) solr.xml sharedLib attribtue should take a list of paths

[
https://issues.apache.org/jira/browse/SOLR-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620418#comment-13620418
]

Uwe Schindler commented on SOLR-4495:
-

Another idea (brought up in SOLR-4653) is the use of a better glob pattern
syntax. My idea was to use similar approach like ANT's fileset/classpath
definitions. We can use plexus-utils-1.1.jar, which provides DirectoryScanner
that understands patterns like {{\*\*/\*.jar}}.

Also your patch is now outdated after SOLR-4652: You should not create a
ClassLoader at all, but instead add the components of classpath to the shared
ResourceLoader using addToClassPath(). See the changes in SOLR-4652.

solr.xml sharedLib attribtue should take a list of paths

Key: SOLR-4495
URL: https://issues.apache.org/jira/browse/SOLR-4495
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Jan Høydahl
Labels: classpath, solr.xml
Fix For: 4.3

Attachments: SOLR-4495.patch

solr.xml's sharedLib is a great way to add plugins that should be shared
across all cores/collections.
For increased flexibility I would like for it to take a list of paths. Then
I'd put Solr's own contrib libs in one shared folder solrJars and custom
plugins with deps in another customerJars. That eases Solr upgrades, then
we can simply wipe and replace all jars in solrJars during upgrade.
I realize that solr.xml is going away, and so the same request will be valid
for whatever replaces solr.xml, whether it be system prop or properties file.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4408) Server hanging on startup


[ 
https://issues.apache.org/jira/browse/SOLR-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620438#comment-13620438
 ] 

Erick Erickson commented on SOLR-4408:
--

I'm a little confused as to the status of this. Francios-Xavier says the he 
just tested the fix, but I'm not clear whether it's SOLR-4400 or the patch that 
Raintung put up. If it was SOLR-4400 then I'll close this JIRA.

Thanks,
Erick

 Server hanging on startup
 -

 Key: SOLR-4408
 URL: https://issues.apache.org/jira/browse/SOLR-4408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1
 Environment: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode)
 Tomcat 7.0
 Eclipse Juno + WTP
Reporter: Francois-Xavier Bonnet
Assignee: Erick Erickson
 Fix For: 4.3

 Attachments: patch-4408.txt


 While starting, the server hangs indefinitely. Everything works fine when I 
 first start the server with no index created yet but if I fill the index then 
 stop and start the server, it hangs. Could it be a lock that is never 
 released?
 Here is what I get in a full thread dump:
 2013-02-06 16:28:52
 Full thread dump OpenJDK 64-Bit Server VM (23.2-b09 mixed mode):
 searcherExecutor-4-thread-1 prio=10 tid=0x7fbdfc16a800 nid=0x42c6 in 
 Object.wait() [0x7fbe0ab1]
java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on 0xc34c1c48 (a java.lang.Object)
   at java.lang.Object.wait(Object.java:503)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492)
   - locked 0xc34c1c48 (a java.lang.Object)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247)
   at 
 org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:94)
   at 
 org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:213)
   at 
 org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:112)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
   at 
 org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64)
   at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1594)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:722)
 coreLoadExecutor-3-thread-1 prio=10 tid=0x7fbe04194000 nid=0x42c5 in 
 Object.wait() [0x7fbe0ac11000]
java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on 0xc34c1c48 (a java.lang.Object)
   at java.lang.Object.wait(Object.java:503)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492)
   - locked 0xc34c1c48 (a java.lang.Object)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312)
   at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247)
   at 
 org.apache.solr.handler.ReplicationHandler.getIndexVersion(ReplicationHandler.java:495)
   at 
 org.apache.solr.handler.ReplicationHandler.getStatistics(ReplicationHandler.java:518)
   at 
 org.apache.solr.core.JmxMonitoredMap$SolrDynamicMBean.getMBeanInfo(JmxMonitoredMap.java:232)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512)
   at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:140)
   at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:51)
   at 
 org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:636)
   at org.apache.solr.core.SolrCore.init(SolrCore.java:809)
   at org.apache.solr.core.SolrCore.init(SolrCore.java:607)
   at 
 org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1003)
   at

[jira] [Assigned] (SOLR-3900) LogWatcher Config Not Persisted


 [ 
https://issues.apache.org/jira/browse/SOLR-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-3900:


Assignee: (was: Erick Erickson)

I'm not going to be able to work on this, plus I only took it because I was in 
the code, plus logging is currently changing so I'll leave it to more ambitious 
souls.

FWIW, solr.xml is making a resurgence so if Michael wants to pick it back up 
that'd be great!

 LogWatcher Config Not Persisted 
 

 Key: SOLR-3900
 URL: https://issues.apache.org/jira/browse/SOLR-3900
 Project: Solr
  Issue Type: Bug
  Components: multicore
Reporter: Michael Garski
Priority: Minor
 Fix For: 4.3


 When the solr.xml file is set to persistent=true, the logging element that 
 contains the LogWatcher configuration is not persisted to the new solr.xml 
 file that is written when managing the cores via core admin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

4.2.1 - Maven?

2013-04-02 Thread Steve Rowe

Hi Mark,

I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, but 
is not yet on Maven Central.

Do you plan on handling publishing to Maven?

If not, or if you'd rather somebody else did it, I can do it.

Steve

On Apr 2, 2013, at 10:36 AM, markrmil...@apache.org wrote:

 Author: markrmiller
 Date: Tue Apr  2 14:35:39 2013
 New Revision: 1717
 
 Log:
 Publish Lucene and Solr 4.2.1 release artifacts
 
 Added:
release/lucene/java/4.2.1/
release/lucene/java/4.2.1/KEYS.txt   (with props)
release/lucene/java/4.2.1/changes/
release/lucene/java/4.2.1/changes/Changes.html   (with props)
release/lucene/java/4.2.1/changes/ChangesFancyStyle.css
release/lucene/java/4.2.1/changes/ChangesFixedWidthStyle.css
release/lucene/java/4.2.1/changes/ChangesSimpleStyle.css
release/lucene/java/4.2.1/lucene-4.2.1-src.tgz   (with props)
release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.asc
release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.md5
release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.sha1
release/lucene/java/4.2.1/lucene-4.2.1.tgz   (with props)
release/lucene/java/4.2.1/lucene-4.2.1.tgz.asc
release/lucene/java/4.2.1/lucene-4.2.1.tgz.md5
release/lucene/java/4.2.1/lucene-4.2.1.tgz.sha1
release/lucene/java/4.2.1/lucene-4.2.1.zip   (with props)
release/lucene/java/4.2.1/lucene-4.2.1.zip.asc
release/lucene/java/4.2.1/lucene-4.2.1.zip.md5
release/lucene/java/4.2.1/lucene-4.2.1.zip.sha1
release/lucene/solr/4.2.1/
release/lucene/solr/4.2.1/KEYS.txt   (with props)
release/lucene/solr/4.2.1/changes/
release/lucene/solr/4.2.1/changes/Changes.html   (with props)
release/lucene/solr/4.2.1/changes/ChangesFancyStyle.css
release/lucene/solr/4.2.1/changes/ChangesFixedWidthStyle.css
release/lucene/solr/4.2.1/changes/ChangesSimpleStyle.css
release/lucene/solr/4.2.1/solr-4.2.1-src.tgz   (with props)
release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.asc
release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.md5
release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.sha1
release/lucene/solr/4.2.1/solr-4.2.1.tgz   (with props)
release/lucene/solr/4.2.1/solr-4.2.1.tgz.asc
release/lucene/solr/4.2.1/solr-4.2.1.tgz.md5
release/lucene/solr/4.2.1/solr-4.2.1.tgz.sha1
release/lucene/solr/4.2.1/solr-4.2.1.zip   (with props)
release/lucene/solr/4.2.1/solr-4.2.1.zip.asc
release/lucene/solr/4.2.1/solr-4.2.1.zip.md5
release/lucene/solr/4.2.1/solr-4.2.1.zip.sha1
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 4.2.1 - Maven?

2013-04-02 Thread Mark Miller

I ran a couple of the initial things this morning (the script that pulls 
everything down), but I've been busy since then. I do intend to do it, but 
would appreciate the help anyhow if you are up for it. Robert once told me if I 
ever publish anything wrong to maven central, I don't really get a redo :)

There are still a handful of things I need to get to - was hoping to start on 
that tonight if I don't pass out first and finish tomorrow. A lack of sleep 
mixed with an exercise restart has been catching up to me.

- Mark

On Apr 2, 2013, at 8:48 PM, Steve Rowe sar...@gmail.com wrote:

 Hi Mark,
 
 I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, 
 but is not yet on Maven Central.
 
 Do you plan on handling publishing to Maven?
 
 If not, or if you'd rather somebody else did it, I can do it.
 
 Steve
 
 On Apr 2, 2013, at 10:36 AM, markrmil...@apache.org wrote:
 
 Author: markrmiller
 Date: Tue Apr  2 14:35:39 2013
 New Revision: 1717
 
 Log:
 Publish Lucene and Solr 4.2.1 release artifacts
 
 Added:
   release/lucene/java/4.2.1/
   release/lucene/java/4.2.1/KEYS.txt   (with props)
   release/lucene/java/4.2.1/changes/
   release/lucene/java/4.2.1/changes/Changes.html   (with props)
   release/lucene/java/4.2.1/changes/ChangesFancyStyle.css
   release/lucene/java/4.2.1/changes/ChangesFixedWidthStyle.css
   release/lucene/java/4.2.1/changes/ChangesSimpleStyle.css
   release/lucene/java/4.2.1/lucene-4.2.1-src.tgz   (with props)
   release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.asc
   release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.md5
   release/lucene/java/4.2.1/lucene-4.2.1-src.tgz.sha1
   release/lucene/java/4.2.1/lucene-4.2.1.tgz   (with props)
   release/lucene/java/4.2.1/lucene-4.2.1.tgz.asc
   release/lucene/java/4.2.1/lucene-4.2.1.tgz.md5
   release/lucene/java/4.2.1/lucene-4.2.1.tgz.sha1
   release/lucene/java/4.2.1/lucene-4.2.1.zip   (with props)
   release/lucene/java/4.2.1/lucene-4.2.1.zip.asc
   release/lucene/java/4.2.1/lucene-4.2.1.zip.md5
   release/lucene/java/4.2.1/lucene-4.2.1.zip.sha1
   release/lucene/solr/4.2.1/
   release/lucene/solr/4.2.1/KEYS.txt   (with props)
   release/lucene/solr/4.2.1/changes/
   release/lucene/solr/4.2.1/changes/Changes.html   (with props)
   release/lucene/solr/4.2.1/changes/ChangesFancyStyle.css
   release/lucene/solr/4.2.1/changes/ChangesFixedWidthStyle.css
   release/lucene/solr/4.2.1/changes/ChangesSimpleStyle.css
   release/lucene/solr/4.2.1/solr-4.2.1-src.tgz   (with props)
   release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.asc
   release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.md5
   release/lucene/solr/4.2.1/solr-4.2.1-src.tgz.sha1
   release/lucene/solr/4.2.1/solr-4.2.1.tgz   (with props)
   release/lucene/solr/4.2.1/solr-4.2.1.tgz.asc
   release/lucene/solr/4.2.1/solr-4.2.1.tgz.md5
   release/lucene/solr/4.2.1/solr-4.2.1.tgz.sha1
   release/lucene/solr/4.2.1/solr-4.2.1.zip   (with props)
   release/lucene/solr/4.2.1/solr-4.2.1.zip.asc
   release/lucene/solr/4.2.1/solr-4.2.1.zip.md5
   release/lucene/solr/4.2.1/solr-4.2.1.zip.sha1
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)

2013-04-02 Thread Ryan Ernst (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620470#comment-13620470
]

Ryan Ernst commented on SOLR-4652:
--

Thanks Uwe!

I've disabled the auto reorder imports feature from IntelliJ, so that should
be better in future patches. I will also make sure to figure out the svn
revision or use an svn checkout. Sorry about the hassle!

I'm hoping to tackle refactoring of the shard handler factory stuff next, but
then coming back to classloader chaining is a possibility. As I said before, I
did start down that road...it is just a doozy. It is pretty straightforward
until you get to ZkSolrResourceLoader, then it seemed to get complicated (I
stopped there, so I am not sure if there is an easy path there).

Resource loader has broken behavior for solr.xml plugins (basically
ShardHandlerFactory)

Key: SOLR-4652
URL: https://issues.apache.org/jira/browse/SOLR-4652
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Reporter: Ryan Ernst
Assignee: Uwe Schindler
Fix For: 4.3, 5.0

Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)

[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620471#comment-13620471
]

Mark Miller commented on SOLR-4652:
---

bq. ZkSolrResourceLoader

If you fill me in, I can probably help. ZkSolrResourceLoader should be pretty
simple - it's intent is simply to load from zk if possible before following
back to how SolrResourceLoader would load - essentially.

Resource loader has broken behavior for solr.xml plugins (basically
ShardHandlerFactory)

Key: SOLR-4652
URL: https://issues.apache.org/jira/browse/SOLR-4652
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Reporter: Ryan Ernst
Assignee: Uwe Schindler
Fix For: 4.3, 5.0

Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)

[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620471#comment-13620471
]

Mark Miller edited comment on SOLR-4652 at 4/3/13 1:06 AM:
---

bq. ZkSolrResourceLoader

If you fill me in, I can probably help. ZkSolrResourceLoader should be pretty
simple - it's intent is simply to load from zk if possible before falling back
to how SolrResourceLoader would load - essentially.

was (Author: markrmil...@gmail.com):
bq. ZkSolrResourceLoader

Resource loader has broken behavior for solr.xml plugins (basically
ShardHandlerFactory)

Key: SOLR-4652
URL: https://issues.apache.org/jira/browse/SOLR-4652
Project: Solr
Issue Type: Bug
Affects Versions: 4.2
Reporter: Ryan Ernst
Assignee: Uwe Schindler
Fix For: 4.3, 5.0

Attachments: SOLR-4652.patch, SOLR-4652.patch, SOLR-4652.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4629) Stronger standard replication testing.


 [ 
https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-4629:
---

Attachment: 
SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch

[~markrmil...@gmail.com]: can you please sanity check this patch for me?

The initial motivation was adding testEmptyCommits to help verify that the 
situation observed in SOLR-4661 didn't actually cause any problems.  

Since a key point of the new test was to ensure that replication happened even 
if no new docs were added by a commit, i couldn't rely on the existing hack of 
rQuery, so i added a wait option to command=fetchindex that causes the 
command request to block until the Thread running doFetch finishes (here's 
where my first concern is: is having this option a bad idea? should we document 
it or keep it hidden for tests?)

since i was looking at rQuery, i noticed it was sleeping at least 100ms on 
every call, even if the results were already available, so i reworked that a 
bit, and in the process refactored a numFound helper utility.



Assuming this patch -- in particular the wait option on fetch index -- seems 
ok to folks, i think we could probably speed up TestReplicationhandler 
considerably by changing all of the individual tests to explicitly call 
pullFromMasterToSlave() instead of using rQuery to wait for polling ... it 
seems like we should really only need a single test of the polling feature, 
everything else being tested can be verified with blocking calls to 
command=fetchindex ... right?

 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0, 4.2.1

 Attachments: 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 4.2.1 - Maven?

2013-04-02 Thread Steve Rowe

Hi Mark,

On Apr 2, 2013, at 9:00 PM, Mark Miller markrmil...@gmail.com wrote:
 I ran a couple of the initial things this morning (the script that pulls 
 everything down), but I've been busy since then. I do intend to do it, but 
 would appreciate the help anyhow if you are up for it. Robert once told me if 
 I ever publish anything wrong to maven central, I don't really get a redo :)

Sure, I'll get started on Maven publishing.

 There are still a handful of things I need to get to - was hoping to start on 
 that tonight if I don't pass out first and finish tomorrow. A lack of sleep 
 mixed with an exercise restart has been catching up to me.

Take care of yourself :).

Thanks for making the release!

 On Apr 2, 2013, at 8:48 PM, Steve Rowe sar...@gmail.com wrote:
 
 I can see that 4.2.1 is on nearly 80% of the Apache mirrors at this point, 
 but is not yet on Maven Central.
 
 Do you plan on handling publishing to Maven?
 
 If not, or if you'd rather somebody else did it, I can do it.

Steve
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.

2013-04-02 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620485#comment-13620485
 ] 

Ryan Ernst commented on SOLR-4663:
--

+1 to failing to startup in this serious misconfiguration.

 Log an error if more than one core points to the same data dir.
 ---

 Key: SOLR-4663
 URL: https://issues.apache.org/jira/browse/SOLR-4663
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor

 In large multi-core setups, having mistakes whereby two or more cores point 
 to the same data dir seems quite possible. We should at least complain very 
 loudly in the logs if this is detected.
 Should be a very straightforward check at core discovery time.
 Is this serious enough to keep Solr from coming up at all?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4629) Stronger standard replication testing.


[ 
https://issues.apache.org/jira/browse/SOLR-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620493#comment-13620493
 ] 

Mark Miller commented on SOLR-4629:
---

Looks good to me.

bq. is having this option a bad idea? should we document it or keep it hidden 
for tests?

It seems fine to me, but it seems safer to not advertise initially. No demand 
yet anyway. I'd doc it as subject to change and unsupported myself. 

bq.  i think we could probably speed up TestReplicationhandler 

+1

 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0, 4.2.1

 Attachments: 
 SOLR-4629_emptycommittest_and_numfoundrefactor_and_waitparam.patch


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 4.2.1 - Maven?

2013-04-02 Thread Steve Rowe

On Apr 2, 2013, at 9:19 PM, Steve Rowe sar...@gmail.com wrote:
 Sure, I'll get started on Maven publishing.

This is done.  Should be on Maven Central in a couple of hours or so.

Steve


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4473) Reloading a core will not close (leak) associated DIH JDBC connection

2013-04-02 Thread Alexandre Rafalovitch (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620602#comment-13620602
 ] 

Alexandre Rafalovitch commented on SOLR-4473:
-

You are right. And, of course, there is no standard way to call that shutdown 
method. Which means it is not safe to use embedded Derby.

Unfortunately, there seem to be no way to use networked Derby either (unless I 
missed something in my test). After I change the URL and start network server, 
I get:
{noformat}
Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
Unable to execute query: select * from ALERTS Processing Document # 4
at 
org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71)
at 
org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:253)
at 
org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210)
at 
org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38)
at 
org.apache.solr.handler.dataimport.DebugLogger$2.getData(DebugLogger.java:188)
at 
org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
at 
org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:404)
... 35 more
Caused by: java.lang.NullPointerException
at 
org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:241)
... 43 more
{noformat}

Using the same URL from the command line works however. It seems that jdbc 
driver just cannot get the connection for whatever reason. I added client 
libraries and all, but it does not seem to help. And I haven't figured out how 
to connect to DIH in debug mode yet.


 Reloading a core will not close (leak) associated DIH JDBC connection
 -

 Key: SOLR-4473
 URL: https://issues.apache.org/jira/browse/SOLR-4473
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 4.1
Reporter: Alexandre Rafalovitch
 Fix For: 4.3


 I have DIH configured with Derby database. After I start Solr, I can run DIH 
 import fine. After I reload the core, DIH can no longer run with the 
 following message (excerpts): 
 ...
 EVERE: Exception while processing: vac document : 
 SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException:
  Unable to execute query: select * from ALERTS Processing Document # 1
   at 
 org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71)
   at 
 org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.init(JdbcDataSource.java:253)
   at 
 org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210)
   at 
 org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38)
   at 
 org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
   at 
 org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
   at 
 org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
   at 
 org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465)
 Caused by: java.sql.SQLException: Another instance of Derby may have already 
 booted the database PATH.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.

2013-04-02 Thread Shai Erera (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619582#comment-13619582
 ] 

Shai Erera commented on LUCENE-4897:


I think that we should use a primitive iterator, e.g. facet collections have 
IntIterator interface. And so the method should be something like {{IntIterator 
getChildren(int ordinal)}}?

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.

2013-04-02 Thread Shai Erera (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619583#comment-13619583
]

Shai Erera commented on LUCENE-4894:

The userguide is seriously outdated after all the recent refactoring. I was
wondering if we should keep it at all, or rather include a high-level
documentation under o.a.l.facet.package.html which covers the basic points, and
then focus on maintaining good javadocs at the classes / packages level. It
gets harder to maintain these documents ...

Nevertheless, if you want to take a crack at improving / fixing it, I will help
you get it in.

Facet User Guide for lucene 4.2 has deleted classes/methods and needs more
explanations.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy

2013-04-02 Thread Shai Erera (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619585#comment-13619585
 ] 

Shai Erera commented on LUCENE-4858:


Adrien, let's keep this issue focused on the Collector working in conjunction 
with SortingMP. I think the added info to diagnostics is important, to prevent 
users tripping themselves. Let's also add the Sorter ID/Key, as another way to 
make the collector robust.

We can deal w/ addIndexes later. If it will be modified to use MP, we'll get 
that support for free; if not, we'll think about what we need to do.

 Early termination with SortingMergePolicy
 -

 Key: LUCENE-4858
 URL: https://issues.apache.org/jira/browse/LUCENE-4858
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4858.patch, LUCENE-4858.patch


 Spin-off of LUCENE-4752, see 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565
  and 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282
 When an index is sorted per-segment, queries that sort according to the index 
 sort order could be early terminated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.

[
https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619601#comment-13619601
]

crocket commented on LUCENE-4894:
-

Including documentations in javadocs might do the job.

Facet User Guide for lucene 4.2 has deleted classes/methods and needs more
explanations.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602
 ] 

crocket commented on LUCENE-4897:
-

I don't know much about IntIterator, but I surmise it'd do the job.

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602
 ] 

crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM:
-

I don't know much about IntIterator, but I surmise it'll do.

  was (Author: crocket):
I don't know much about IntIterator, but I surmise it'd do.
  
 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602
 ] 

crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM:
-

I don't know much about IntIterator, but I surmise it'd do.

  was (Author: crocket):
I don't know much about IntIterator, but I surmise it'd do the job.
  
 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602
 ] 

crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM:
-

I don't know much about IntIterator, but I surmise it'll do good enough.

  was (Author: crocket):
I don't know much about IntIterator, but I surmise it'll suffice.
  
 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-4897) Add a sugar API for traversing categories.


[ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619602#comment-13619602
 ] 

crocket edited comment on LUCENE-4897 at 4/2/13 7:42 AM:
-

I don't know much about IntIterator, but I surmise it'll suffice.

  was (Author: crocket):
I don't know much about IntIterator, but I surmise it'll do.
  
 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

How to consume DocTermOrds for MultiValuedFields

2013-04-02 Thread Varun Thacker

final DocTermOrds docTermOrds =
FieldCache.DEFAULT.getDocTermOrds(atomicReader, multiValuedField);
final TermsEnum termsEnum = docTermOrds.getOrdTermsEnum(atomicReader);
DocTermOrds.TermOrdsIterator reuse = docTermOrds.lookup(doc, reuse);

int[] buffer = new int[5];
StringBuilder indexedFieldValue = new StringBuilder();

  do {
int chunk = reuse.read(buffer);
for (int idx = 0; idx  chunk; idx++) {
  int key = buffer[idx];
  termsEnum.seekExact((long) key);
  String fieldValue = termsEnum.term().utf8ToString();
  indexedFieldValue.append(fieldValue);
}
//Match indexedFieldValue here
  } while((chunk = buffer.length));


This is how I am am consuming DocTermOrds.

Doing this gives me all the unique tokens across all the values in the
multiValuedField for that document.

How can I get each of the values in the field individually? Is there any
other cache impl. where I can

-- 


Regards,
Varun Thacker
http://www.vthacker.in/

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619728#comment-13619728
]

Erick Erickson commented on SOLR-4662:
--

I may actually have some time on some long flights to work on this, I'd really
like to nail this and get it _over_. So I'd like to get the design agreed so I
don't have to re-do the re-done.

It seems like the root issue here is that we have this configuration file that
is trying to serve too many purposes. It started as a way to get basic
configuration information back in the single-core days. Then it morphed into a
place to get all the core information. Then it morphed into a place where we
could specify a bunch of SolrCloud parameters. Then it morphed into a place to
not really get core information but specify that that info get discovered. Now,
with SolrCloud one question is whether we should even have it or should all
this info be stored in Zookeeper. Having local files around that you have to
have on each node before starting solr seems counter to having configurations
managed by ZK.

Straw-man proposal:

So, what if we allow a SolrConfigurationProvider? Specifying none or the
default we'll provide does just what happens now. It seems like the other stock
one we could supply is one that reads the info from ZK. Don't know what else is
out there, but that's just the point. People could plug in something that read
their DB, something that read a properties file G. Whatever. There's a start
on what the interface would look like here in ConfigSolr, which I pulled out
when trying to make a properties file. I doubt it's entirely complete, but
should be a pretty good start. Maybe this becomes an option on the command
line? e.g. -Dsolr.configProvider=org.solr.core.XmlConfigProvider as the
default? And if -DzkHost=url to zk is provided, default to
-Dsolr.configProvider=org.solr.core.ZkConfigProvider?

It seems like default behavior is then mostly a matter of which provider we use
if none is specified. It'd be a pretty simple matter to switch between whether
we use ZK or a solr.xml file based on whether we had a zkHost specified, and
prefer the one that reads solr.xml in 4.x and the one that reads ZK in 5.x or
whatever...

Let me be the first to say that I have NOT thought this through very carefully,
and note how I'm glossing over getting the appropriate info up into ZK in the
first place. My purpose here is to get the discussion going, I don't
particularly care if this approach is adopted or not. I _do_ care that whatever
we decide on doesn't do another 180 turn...

Let the discussion begin!

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4897) Add a sugar API for traversing categories.


 [ 
https://issues.apache.org/jira/browse/LUCENE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4897:
---

Labels: newdev  (was: )

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev

 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4894) Facet User Guide for lucene 4.2 has deleted classes/methods and needs more explanations.

[
https://issues.apache.org/jira/browse/LUCENE-4894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619729#comment-13619729
]

Michael McCandless commented on LUCENE-4894:

+1 to remove the userGuide and absorb it into javadocs.

Facet User Guide for lucene 4.2 has deleted classes/methods and needs more
explanations.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2412) Multipath hierarchical faceting

2013-04-02 Thread Toke Eskildsen (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Toke Eskildsen updated SOLR-2412:
-

Attachment: SOLR-2412.patch

Improved base startup speed and added experimental optional high-speed high-mem 
structure builder. Patch only tested with Solr 4.0.

 Multipath hierarchical faceting
 ---

 Key: SOLR-2412
 URL: https://issues.apache.org/jira/browse/SOLR-2412
 Project: Solr
  Issue Type: New Feature
  Components: SearchComponents - other
Affects Versions: 4.0
 Environment: Fast IO when huge hierarchies are used
Reporter: Toke Eskildsen
  Labels: contrib, patch
 Attachments: SOLR-2412.patch, SOLR-2412.patch, SOLR-2412.patch, 
 SOLR-2412.patch, SOLR-2412.patch


 Hierarchical faceting with slow startup, low memory overhead and fast 
 response. Distinguishing features as compared to SOLR-64 and SOLR-792 are
   * Multiple paths per document
   * Query-time analysis of the facet-field; no special requirements for 
 indexing besides retaining separator characters in the terms used for faceting
   * Optional custom sorting of tag values
   * Recursive counting of references to tags at all levels of the output
 This is a shell around LUCENE-2369, making it work with the Solr API. The 
 underlying principle is to reference terms by their ordinals and create an 
 index wide documents to tags map, augmented with a compressed representation 
 of hierarchical levels.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619777#comment-13619777
 ] 

Dawid Weiss commented on SOLR-4653:
---

Thanks for clarification, Hoss. What you say makes sense but the common 
practice seems to be that:
* people modify the example's configuration files and overwrite them just 
because all the paths are relative from those directories and pointing at 
contribs,
* when you want to create an isolate configuration and pass it to somebody to, 
say, run with -Dsolr.solr.home it's hard because you need to know absolute 
installation paths or make the user install that configuration in an exact 
folder under solr's unpacked structure. If they change anything -- boom, things 
don't work and nobody knows what's going on.

I think the middle ground here is to at least log a warning when a fileset is 
empty (and provide the basedir against which it was resolved). This looks 
suspicious and provides enough information to recover from the problem.

 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial

 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619784#comment-13619784
]

Mark Miller commented on SOLR-4662:
---

Quick notes:

I don't think it has really morphed.

solr.xml has always been our only config file for the system or corecontainer
level. Everything that has joined the corecontainer was added because it's not
core level, and that's always been the role of solr.xml - home of the above
SolrCore level.

Let's talk about the overall strategy before we nail down the impl.

IMO, solr.xml has a few issues:

1. It should not define cores. Solr should not have to write to this config
file, and cores should be define by directory locations.
2. The SolrCloud params are all cores attributes, but they should be in a
better structure, similar to the shard handler definition that can now live in
solr.xml, and what we do in solrconfig.xml.
3. We should consider how most of the solr.xml config can live in ZooKeeper
when in SolrCloud mode. Much of this is not something you want to have to tweak
on every node - it's going to be the same - you generally want to set a
zkClientTimeout for your collection, not for each node. Same for shard handler.
I think it's worth forcing some consistency for all nodes, such as the same
host context. It will also be possible to override those things per node with
sys prop notation. zkHost could no longer be specified in solr.xml.

So, I think we need to be able to detect and read the old solr.xml format some
way (lot's of choices I think), as well as detect and read the new format
(which will be very similar to the old). In 5 we stop supporting the old
format. Example ships with the new format.

In terms of impl, I think you are on the right track. I don't think we should
expose any user plugins at this point though. That should be internal work.
Let's decide if we should support arbitrary impls for users later. It has an
ongoing cost, in this area in particular I think. I think we want to reserve
all API rights here.

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4656) Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting


[ 
https://issues.apache.org/jira/browse/SOLR-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619802#comment-13619802
 ] 

Erick Erickson commented on SOLR-4656:
--

Committed trunk: r - 1463543

 Add hl.maxMultiValuedToExamine to limit the number of multiValued entries 
 examined while highlighting
 -

 Key: SOLR-4656
 URL: https://issues.apache.org/jira/browse/SOLR-4656
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, SOLR-4656.patch, 
 SOLR-4656-trunk.patch


 I'm looking at an admittedly pathological case of many, many entries in a 
 multiValued field, and trying to implement a way to limit the number 
 examined, analogous to maxAnalyzedChars, see the patch.
 Along the way, I noticed that we do what looks like unnecessary copying of 
 the fields to be examined. We call Document.getFields, which copies all of 
 the fields and values to the returned array. Then we copy all of those to 
 another array, converting them to Strings. Then we actually examine them. a 
 this doesn't seem very efficient and b reduces the benefit from limiting the 
 number of mv values examined.
 So the attached does two things:
 1 attempts to fix this
 2 implements hl.maxMultiValuedToExamine
 I'd _really_ love it if someone who knows the highlighting code takes a peek 
 at the fix to see if I've messed things up, the changes are actually pretty 
 minimal.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4881) Add a set iterator to SentinelIntSet


 [ 
https://issues.apache.org/jira/browse/LUCENE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated LUCENE-4881:
-

Summary: Add a set iterator to SentinelIntSet  (was: Add a set iterator to 
SentinalIntSet)

 Add a set iterator to SentinelIntSet
 

 Key: LUCENE-4881
 URL: https://issues.apache.org/jira/browse/LUCENE-4881
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4881_SentinalIntSet_int_iterator.patch, 
 SentinelIntSet_docs.patch


 I'm working on code that needs a hash based int Set.  It will need to iterate 
 over the values, but SentinalIntSet doesn't have this utility feature.  It 
 should be pretty easy to add.
 FYI this is an out-growth of a question I posed to the dev list, examining 3 
 different int hash sets out there: SentinalIntSet, IntHashSet (in Lucene 
 facet module) and the 3rd party IntOpenHashSet (HPPC) -- see 
 http://lucene.472066.n3.nabble.com/IntHashSet-SentinelIntSet-SortedIntDocSet-td4037516.html
   I decided to go for SentinalIntSet because it's already in Lucene-core, 
 adding the method I need should be easy, and it has a nice lean 
 implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.


[ 
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619866#comment-13619866
 ] 

Mark Miller commented on SOLR-4662:
---

So from my point of view:

1. is essentially done
2. is what we should tie up here, keeping in mind 3
3. we should make another jira issue and follow on with

 Finalize what we're going to do with solr.xml, auto-discovery, config sets.
 ---

 Key: SOLR-4662
 URL: https://issues.apache.org/jira/browse/SOLR-4662
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

 Spinoff from SOLR-4615, breaking it out here so we can address the changes in 
 pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

2013-04-02 Thread Shawn Heisey (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619867#comment-13619867
 ] 

Shawn Heisey commented on SOLR-4662:


I too think that solr.xml should not store cores.  Auto-discovery is a nice 
thing, but it makes it more difficult to have a nice clean layout where the 
core configs and data are contained within separate subdirectories.  I suppose 
that each autodiscovered core properties file could have a relative dataDir 
that goes up one or two directories, just like my current setup, and that might 
be good enough.  I would also want to have something like a coreDirectory 
parameter, which I would set to cores so that the main solr.solr.home 
directory would be very clean.

One option is to have a cores.xml file for more complex layouts where the user 
wants to specify everything.  At first I thought about a cloud.xml file for 
SolrCloud properties, but once you start down the path of multiple config 
files, the explosion might never stop.

Here's what things look like inside solr.xml on my setup that's not well suited 
for SolrCloud, and a snippet of the full directory structure.  The full picture 
is more complex than this, with relative symlinks in conf directories and 
relative xinclude paths in solrconfig.xml, but this gives you the basic idea:

{noformat}
core loadOnStartup=true instanceDir=cores/inc_0/ transient=false 
name=inclive dataDir=../../data/inc_0/
core loadOnStartup=true instanceDir=cores/inc_1/ transient=false 
name=incbuild dataDir=../../data/inc_1/

├── cores
│   ├── inc_0
│   │   └── conf
│   ├── inc_1
│   │   └── conf
├── data
│   ├── inc_0
│   │   ├── index
│   │   └── tlog
│   ├── inc_1
│   │   ├── index
│   │   └── tlog
└── lib
{noformat}

I'm not sure there is a better location than solr.xml for zkHost, but I 
definitely think it should be in a config file.  **Requiring** -DzkHost on 
startup is a bad idea - generic startup scripts become very difficult.  Keeping 
all of the config after that in zookeeper is an idea that is growing on me, as 
long as the initial contact to zookeeper won't suffer from a low default client 
timeout before zkClientTimeout can be read.

If you give Solr (or CloudSolrServer) only one of the hosts in your zookeeper 
ensemble (perhaps localhost:port/chroot) will it automatically configure itself 
with the entire ensemble?  If not, is there a way to build this functionality 
in?

The fact that Solr does not come equipped with instructions for a standalone 
zookeeper process or a functioning standalone zookeeper is problematic in my 
opinion.  If I find some time, I can whip up a wiki page.  I do wish zkcli.sh 
was more self-contained.  I can eventually come up with a wiki page for that 
too.


 Finalize what we're going to do with solr.xml, auto-discovery, config sets.
 ---

 Key: SOLR-4662
 URL: https://issues.apache.org/jira/browse/SOLR-4662
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

 Spinoff from SOLR-4615, breaking it out here so we can address the changes in 
 pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619872#comment-13619872
]

Erick Erickson commented on SOLR-4662:
--

H. Point taken about not exposing a pluggable version yet, now that you
mention it that seems premature. Hardening all that before exposing something
we then have to support makes sense. We can still program to the interface I
mentioned as much as possible to make that easier in future but no big deal
either way.

1 is done.
2 OK, what does that look like? Is this just a simple transformation like
solr
solrConfigFactory name=solrConfigFactory clase=SolrConfigFactory
str name=persistent${solr.xml.persist:false}/str
str name=adminPath/admin/cores/str
str name=defaultCoreNamecollection1/str
str name=host127.0.0.1/str
str name=hostPort${hostPort:8983}/str
str name=hostContext${hostContext:solr}/str
str name=shareSchema${shareSchema:false}/str

shardHandlerFactory name=shardHandlerFactory
class=HttpShardHandlerFactory
int name=socketTimeout${socketTimeout:12}/int
int name=connTimeout${connTimeout:15000}/int
/shardHandlerFactory

str name=zkClientTimeout${solr.zkclienttimeout:3}/str
str name=numShards${numShards:3}/str
str name=distribUpdateConnTimeout${distribUpdateConnTimeout:15000}/str
str name=distribUpdateSoTimeout${distribUpdateSoTimeout:12}/str
/solrConfigFactory

/solr

This form doesn't allow cores to be here at all. Is there any necessity to have
a factory here or are you thinking these should just be child nodes of solr?
Would shardHandlerFactory be inside or outside the new factory? As you can
tell, how all this fits together is something of a mystery to me. But having a
solrConfigFactory node as the immediate child of solr and encompassing all
the rest would allow easy detection of old -vs- new style XML. Adding a version
attribute to the solr tag seems possible too, but I don't really like that, I
think there's less user-level maintenance if we use solrConfigFactory,
implementing up different handlers for different versions if/when we change
again, which should be very rare.

3 On that note, it's not clear to me we need solr.xml at all in true cloud
mode. In the absence of solr.xml but presence of zkHost, just get everything
from ZK. Look, you know how ZK-ignorant I am, be gentle G. The rest of the
time, anything you could possibly want from solr.xml that wasn't present, ask
ZK for it and use defaults if neither source had it. By not present, that
means neither in the solr.xml file nor as a sysprop. Along the way removing
DEF_SOLR_XML from ConfigSolrXml would be a Good Thing maybe.

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


 [ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dawid Weiss updated SOLR-4653:
--

Attachment: SOLR-4653.patch

This is my take at this having considered a few other alternatives. It logs 
this at startup currently:

{code}
Can't find (or read) directory to add to classloader: /total/crap/dir/ignored 
(resolved as: 
C:\Work\lucene-solr-svn\trunk\solr\example\solr\collection1\total\crap\dir\ignored).
{code}

And indeed the example config contains:

{code}
  !-- If a 'dir' option (with or without a regex) is used and nothing
   is found that matches, it will be ignored
--
  lib dir=/total/crap/dir/ignored / 
{code}

Perhaps the comment should be changed/ made more polite too.


 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619876#comment-13619876
 ] 

Dawid Weiss commented on SOLR-4653:
---

If no objections I'll commit this in a few hours.

 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-2412) Architecture Diagrams needed for Lucene, Solr and Nutch

2013-04-02 Thread Furkan KAMACI (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619890#comment-13619890
 ] 

Furkan KAMACI commented on LUCENE-2412:
---

It would be nice if we had updated it and explained in more detail. Just for an 
example: Update Request Handling - optional language detection - 
Analysing(stamming, lemmitazing etc.) - Search Request Handling - Scoring - 
Soundex - etc. etc.?

 Architecture Diagrams needed for Lucene, Solr and Nutch
 ---

 Key: LUCENE-2412
 URL: https://issues.apache.org/jira/browse/LUCENE-2412
 Project: Lucene - Core
  Issue Type: Task
  Components: core/other
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: arch.pdf, LIA2_01_04.pdf, NutchArch.pdf, solr-arch.pdf




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.


[ 
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619895#comment-13619895
 ] 

Erick Erickson commented on SOLR-4662:
--

Shawn:

Couple of things:

1 there's no reason you can't have your individual data dirs specified in 
core.properties point wherever you want. Not sure that handles your case but 
thought I'd mention it. I'm not keen on maintaining a separate specify 
everything xml file, does the ability to specify your data dir for each core 
do what you need?

2 SOLR-4478 (another thing I hope to have done Real Soon now) will allow 
configsets. Basically in solr_home/configs (TBD) there will be directories 
like conf1, conf2 etc, which will be full Solr configuration directories. 
Then you can specify a configSet property in your individual core.properties 
file and that core will make use of the named config set, incidentally sharing 
all the setup between cores that use the same config set (i.e. won't parse/load 
the solrconfig.xml and schema.xml separately for each core that names the same 
config set).

Keep the comments coming!

 Finalize what we're going to do with solr.xml, auto-discovery, config sets.
 ---

 Key: SOLR-4662
 URL: https://issues.apache.org/jira/browse/SOLR-4662
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Blocker

 Spinoff from SOLR-4615, breaking it out here so we can address the changes in 
 pieces.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898
 ] 

Uwe Schindler commented on SOLR-4653:
-

Just one additional idea: There are comments about the regex in the current 
code and complexity for users. How about using ANT-style filesets for 
specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar 
from Maven, which contains DirectoryScanner that is able to parse things like 
**/*.jar. I use that in the fobidden APIs CLI and Mojo classes: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261

Otherwise +1 to commit!

 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898
 ] 

Uwe Schindler edited comment on SOLR-4653 at 4/2/13 3:00 PM:
-

Just one additional idea: There are comments about the regex in the current 
code and complexity for users. How about using ANT-style filesets for 
specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar 
from Maven, which contains DirectoryScanner that is able to parse things like 
{{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261

Otherwise +1 to commit!

  was (Author: thetaphi):
Just one additional idea: There are comments about the regex in the current 
code and complexity for users. How about using ANT-style filesets for 
specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar 
from Maven, which contains DirectoryScanner that is able to parse things like 
**/*.jar. I use that in the fobidden APIs CLI and Mojo classes: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261

Otherwise +1 to commit!
  
 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619898#comment-13619898
 ] 

Uwe Schindler edited comment on SOLR-4653 at 4/2/13 3:01 PM:
-

Just one additional idea: There are comments about the regex in the current 
code and complexity for users. How about using ANT-style filesets for 
specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar 
from Maven, which contains DirectoryScanner that is able to parse things like 
{{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#257

Otherwise +1 to commit!

  was (Author: thetaphi):
Just one additional idea: There are comments about the regex in the current 
code and complexity for users. How about using ANT-style filesets for 
specifying the lib dirs? We dont need ANT for that, just plexus-utils-1.1.jar 
from Maven, which contains DirectoryScanner that is able to parse things like 
{{\*\*/\*.jar}}. I use that in the fobidden APIs CLI and Mojo classes: 
https://code.google.com/p/forbidden-apis/source/browse/trunk/src/main/java/de/thetaphi/forbiddenapis/CliMain.java#261

Otherwise +1 to commit!
  
 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-4881) Add a set iterator to SentinelIntSet

[
https://issues.apache.org/jira/browse/LUCENE-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Smiley resolved LUCENE-4881.
--

Resolution: Won't Fix

I committed better javadocs, including sample code to iterate the values.

Closing issue as won't fix (for now). If at some point we want an iterator, the
patch is here and it can be re-considered.

Add a set iterator to SentinelIntSet

Key: LUCENE-4881
URL: https://issues.apache.org/jira/browse/LUCENE-4881
Project: Lucene - Core
Issue Type: Improvement
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor
Fix For: 4.3

Attachments: LUCENE-4881_SentinalIntSet_int_iterator.patch,
SentinelIntSet_docs.patch

I'm working on code that needs a hash based int Set. It will need to iterate
over the values, but SentinalIntSet doesn't have this utility feature. It
should be pretty easy to add.
FYI this is an out-growth of a question I posed to the dev list, examining 3
different int hash sets out there: SentinalIntSet, IntHashSet (in Lucene
facet module) and the 3rd party IntOpenHashSet (HPPC) -- see
http://lucene.472066.n3.nabble.com/IntHashSet-SentinelIntSet-SortedIntDocSet-td4037516.html
I decided to go for SentinalIntSet because it's already in Lucene-core,
adding the method I need should be easy, and it has a nice lean
implementation.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-trunk-MacOSX ([[ Exception while replacing ENV. Please report this as a bug. ]]

2013-04-02 Thread Policeman Jenkins Server

{{ java.lang.NullPointerException }})
 - Build # 372 - Failure!
MIME-Version: 1.0
Content-Type: multipart/mixed; 
boundary==_Part_90_1788693553.1364915769483
X-Jenkins-Job: Lucene-Solr-trunk-MacOSX
X-Jenkins-Result: FAILURE
Precedence: bulk

--=_Part_90_1788693553.1364915769483
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/372/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}

No tests ran.

Build Log:
[...truncated 10103 lines...]
[junit4:junit4] Suite: org.apache.solr.client.solrj.TestBatchUpdate
[junit4:junit4]   1 60572 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] WARN  
org.apache.solr.SolrTestCaseJ4  ? startTrackingSearchers: numOpens=37 
numCloses=37
[junit4:junit4]   1 60634 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.SolrJettyTestBase  ? Randomized ssl (true) and clientAuth 
(false)
[junit4:junit4]   1 60635 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.SolrTestCaseJ4  ? initCore
[junit4:junit4]   1 60636 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.SolrTestCaseJ4  ? initCore end
[junit4:junit4]   1 60651 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.eclipse.jetty.server.Server  ? jetty-8.1.8.v20121106
[junit4:junit4]   1 61049 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.eclipse.jetty.util.ssl.SslContextFactory  ? Enabled Protocols [SSLv2Hello, 
SSLv3, TLSv1, TLSv1.1, TLSv1.2] of [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]
[junit4:junit4]   1 61058 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.eclipse.jetty.server.AbstractConnector  ? Started 
SslSelectChannelConnector@127.0.0.1:51160
[junit4:junit4]   1 61060 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.servlet.SolrDispatchFilter  ? SolrDispatchFilter.init()
[junit4:junit4]   1 61062 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.SolrResourceLoader  ? JNDI not configured for solr 
(NoInitialContextEx)
[junit4:junit4]   1 61063 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.SolrResourceLoader  ? using system property 
solr.solr.home: 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr
[junit4:junit4]   1 61063 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.CoreContainer  ? looking for solr config file: 
/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/solr.xml
[junit4:junit4]   1 61065 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.CoreContainer  ? New CoreContainer 984960070
[junit4:junit4]   1 61067 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.CoreContainer  ? Loading CoreContainer using Solr Home: 
'/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/'
[junit4:junit4]   1 61068 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.core.SolrResourceLoader  ? new SolrResourceLoader for 
directory: 
'/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/example/solr/'
[junit4:junit4]   1 61184 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
socketTimeout to: 0
[junit4:junit4]   1 61185 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting urlScheme 
to: http://
[junit4:junit4]   1 61185 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
connTimeout to: 0
[junit4:junit4]   1 61186 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
maxConnectionsPerHost to: 20
[junit4:junit4]   1 61187 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
corePoolSize to: 0
[junit4:junit4]   1 61187 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
maximumPoolSize to: 2147483647
[junit4:junit4]   1 61188 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
maxThreadIdleTime to: 5
[junit4:junit4]   1 61189 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting 
sizeOfQueue to: -1
[junit4:junit4]   1 61190 
[SUITE-TestBatchUpdate-seed#[F0B79D6E55FFA148]-worker] INFO  
org.apache.solr.handler.component.HttpShardHandlerFactory  ? Setting

[jira] [Created] (SOLR-4663) Log an error if more than one core points to the same data dir.

Erick Erickson created SOLR-4663:


 Summary: Log an error if more than one core points to the same 
data dir.
 Key: SOLR-4663
 URL: https://issues.apache.org/jira/browse/SOLR-4663
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor


In large multi-core setups, having mistakes whereby two or more cores point to 
the same data dir seems quite possible. We should at least complain very loudly 
in the logs if this is detected.

Should be a very straightforward check at core discovery time.

Is this serious enough to keep Solr from coming up at all?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619933#comment-13619933
 ] 

Erick Erickson commented on SOLR-4653:
--

+1 to making the message more polite. The rest of the patch too!

 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4883) Hide FieldCache behind an UninvertingFilterReader

2013-04-02 Thread Alan Woodward (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-4883:
--

Attachment: LUCENE-4883.patch

New patch, with a NumericDocValues uninverter.  Also a basic test.

NumericDocValues doesn't work with 32-bit values yet (the test for IntField 
fails); I need to somehow detect at uninversion-time how wide the indexed 
values are.

 Hide FieldCache behind an UninvertingFilterReader
 -

 Key: LUCENE-4883
 URL: https://issues.apache.org/jira/browse/LUCENE-4883
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch


 From a discussion on the mailing list:
 {{
 rmuir:
 I think instead FieldCache should actually be completely package
 private and hidden behind a UninvertingFilterReader and accessible via
 the existing AtomicReader docValues methods.
 }}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4883) Hide FieldCache behind an UninvertingFilterReader


[ 
https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619944#comment-13619944
 ] 

David Smiley commented on LUCENE-4883:
--

What does NumericDocValues uninverter mean?  DocValues are inherently 
un-inverted.

 Hide FieldCache behind an UninvertingFilterReader
 -

 Key: LUCENE-4883
 URL: https://issues.apache.org/jira/browse/LUCENE-4883
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch


 From a discussion on the mailing list:
 {{
 rmuir:
 I think instead FieldCache should actually be completely package
 private and hidden behind a UninvertingFilterReader and accessible via
 the existing AtomicReader docValues methods.
 }}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4883) Hide FieldCache behind an UninvertingFilterReader

2013-04-02 Thread Alan Woodward (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619945#comment-13619945
 ] 

Alan Woodward commented on LUCENE-4883:
---

Something that will uninvert a LongField or DoubleField into a NumericDocValues 
representation.

 Hide FieldCache behind an UninvertingFilterReader
 -

 Key: LUCENE-4883
 URL: https://issues.apache.org/jira/browse/LUCENE-4883
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Attachments: LUCENE-4883.patch, LUCENE-4883.patch, LUCENE-4883.patch


 From a discussion on the mailing list:
 {{
 rmuir:
 I think instead FieldCache should actually be completely package
 private and hidden behind a UninvertingFilterReader and accessible via
 the existing AtomicReader docValues methods.
 }}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

2013-04-02 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619964#comment-13619964
]

Shawn Heisey commented on SOLR-4662:

bq. does the ability to specify your data dir for each core do what you need?

As long the dataDir specified in a core properties file retains all its current
capabilities relative to instanceDir, then yes, that will work nicely. As I
mentioned, I would like to see a config option (probably in solr.xml, name
suggestion coreDirectory) to specify a relative or absolute path where it will
look for auto-detected instanceDirs. For the thousands of cores users, this
will be very important, so that solr.solr.home isn't cluttered - it might have
solr.xml (or its replacement) and a handful of directories like cores, lib, and
maybe data. I'd like to see that parameter default to cores but I am not
opposed to it being . or having no default value at all.

bq. Basically in solr_home/configs (TBD) there will be directories like
conf1, conf2 etc.

I like this idea. I would want to make sure that relative xincludes are
possible, just as they currently are with config sets in zookeeper. If the xml
goes away and gets replaced by a properties file, including subconfigs won't be
as important, but it would be nice if it were still possible.

Finalize what we're going to do with solr.xml, auto-discovery, config sets.
---

Spinoff from SOLR-4615, breaking it out here so we can address the changes in
pieces.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4888) SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1

2013-04-02 Thread Adrien Grand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619969#comment-13619969
 ] 

Adrien Grand commented on LUCENE-4888:
--

I plan to commit soon unless someone objects. I think the changes are correct 
but please let me know if you would like to review it as this patch modifies 
some touchy code (such as SloppyPhraseScorer.advance).

 SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1
 --

 Key: LUCENE-4888
 URL: https://issues.apache.org/jira/browse/LUCENE-4888
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 4.2
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-4888.patch, LUCENE-4888.patch


 SloppyPhraseScorer calls DocsAndPositionsEnum.advance with target = -1 
 although the behavior of this method is undefined in such cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy

2013-04-02 Thread Adrien Grand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619971#comment-13619971
 ] 

Adrien Grand commented on LUCENE-4858:
--

bq. We can deal w/ addIndexes later. If it will be modified to use MP, we'll 
get that support for free; if not, we'll think about what we need to do.

Sounds good to me.


 Early termination with SortingMergePolicy
 -

 Key: LUCENE-4858
 URL: https://issues.apache.org/jira/browse/LUCENE-4858
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4858.patch, LUCENE-4858.patch


 Spin-off of LUCENE-4752, see 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565
  and 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282
 When an index is sorted per-segment, queries that sort according to the index 
 sort order could be early terminated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13619994#comment-13619994
 ] 

Mark Miller commented on SOLR-4584:
---

That's what I did when I tried to recreate this (though I used rows=0 as you 
originally reported) - it proxied the requests fine for me.

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-4656) Add hl.maxMultiValuedToExamine to limit the number of multiValued entries examined while highlighting


 [ 
https://issues.apache.org/jira/browse/SOLR-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-4656.
--

   Resolution: Fixed
Fix Version/s: 5.0
   4.3

4x: r - 1463627

 Add hl.maxMultiValuedToExamine to limit the number of multiValued entries 
 examined while highlighting
 -

 Key: SOLR-4656
 URL: https://issues.apache.org/jira/browse/SOLR-4656
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.3, 5.0

 Attachments: SOLR-4656-4x.patch, SOLR-4656-4x.patch, SOLR-4656.patch, 
 SOLR-4656-trunk.patch


 I'm looking at an admittedly pathological case of many, many entries in a 
 multiValued field, and trying to implement a way to limit the number 
 examined, analogous to maxAnalyzedChars, see the patch.
 Along the way, I noticed that we do what looks like unnecessary copying of 
 the fields to be examined. We call Document.getFields, which copies all of 
 the fields and values to the returned array. Then we copy all of those to 
 another array, converting them to Strings. Then we actually examine them. a 
 this doesn't seem very efficient and b reduces the benefit from limiting the 
 number of mv values examined.
 So the attached does two things:
 1 attempts to fix this
 2 implements hl.maxMultiValuedToExamine
 I'd _really_ love it if someone who knows the highlighting code takes a peek 
 at the fix to see if I've messed things up, the changes are actually pretty 
 minimal.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


 [ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yago Riveiro updated SOLR-4584:
---

Attachment: select

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620012#comment-13620012
 ] 

Yago Riveiro commented on SOLR-4584:


:S, I tried again and doesn't work. I changed the wt to javabin for the browse 
doesn't interpret the response and the response is truncated, you can see it in 
file select that I'm attach.

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Reopened] (LUCENE-949) AnalyzingQueryParser can't work with leading wildcards.


 [ 
https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley reopened LUCENE-949:
-


Reopening at the request of [~talli...@mitre.org] who intends to attach a 
patch.  Regular users can't re-open JIRA issues, apparently.

 AnalyzingQueryParser can't work with leading wildcards.
 ---

 Key: LUCENE-949
 URL: https://issues.apache.org/jira/browse/LUCENE-949
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/queryparser
Affects Versions: 2.2
Reporter: Stefan Klein

 The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following 
 changes to accept leading wildcards:
   protected Query getWildcardQuery(String field, String termStr) throws 
 ParseException
   {
   String useTermStr = termStr;
   String leadingWildcard = null;
   if (*.equals(field))
   {
   if (*.equals(useTermStr))
   return new MatchAllDocsQuery();
   }
   boolean hasLeadingWildcard = (useTermStr.startsWith(*) || 
 useTermStr.startsWith(?)) ? true : false;
   if (!getAllowLeadingWildcard()  hasLeadingWildcard)
   throw new ParseException('*' or '?' not allowed as 
 first character in WildcardQuery);
   if (getLowercaseExpandedTerms())
   {
   useTermStr = useTermStr.toLowerCase();
   }
   if (hasLeadingWildcard)
   {
   leadingWildcard = useTermStr.substring(0, 1);
   useTermStr = useTermStr.substring(1);
   }
   List tlist = new ArrayList();
   List wlist = new ArrayList();
   /*
* somewhat a hack: find/store wildcard chars in order to put 
 them back
* after analyzing
*/
   boolean isWithinToken = (!useTermStr.startsWith(?)  
 !useTermStr.startsWith(*));
   isWithinToken = true;
   StringBuffer tmpBuffer = new StringBuffer();
   char[] chars = useTermStr.toCharArray();
   for (int i = 0; i  useTermStr.length(); i++)
   {
   if (chars[i] == '?' || chars[i] == '*')
   {
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = false;
   }
   else
   {
   if (!isWithinToken)
   {
   wlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = true;
   }
   tmpBuffer.append(chars[i]);
   }
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   }
   else
   {
   wlist.add(tmpBuffer.toString());
   }
   // get Analyzer from superclass and tokenize the term
   TokenStream source = getAnalyzer().tokenStream(field, new 
 StringReader(useTermStr));
   org.apache.lucene.analysis.Token t;
   int countTokens = 0;
   while (true)
   {
   try
   {
   t = source.next();
   }
   catch (IOException e)
   {
   t = null;
   }
   if (t == null)
   {
   break;
   }
   if (!.equals(t.termText()))
   {
   try
   {
   tlist.set(countTokens++, t.termText());
   }
   catch (IndexOutOfBoundsException ioobe)
   {
   countTokens = -1;
   }
   }
   }
   try
   {
   source.close();
   }
   catch (IOException e)
   {
   // ignore
   }
   if (countTokens != tlist.size())
   {

[jira] [Commented] (SOLR-4584) Request proxy mechanism not work if rows param is equal to zero


[ 
https://issues.apache.org/jira/browse/SOLR-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620033#comment-13620033
 ] 

Mark Miller commented on SOLR-4584:
---

Have you tried it with the jetty we ship, or just tomcat?

 Request proxy mechanism not work if rows param is equal to zero
 ---

 Key: SOLR-4584
 URL: https://issues.apache.org/jira/browse/SOLR-4584
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Centos 6, Tomcat 7
Reporter: Yago Riveiro
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
 02.png, Screen Shot 03.png, select


 If I try to do a request like:
 http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*rows=0
 The request fail. The solr UI logging has this error:
 {code:java} 
 null:org.apache.solr.common.SolrException: Error trying to proxy request for 
 url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
 {code} 
 Chrome says:
 This webpage is not available
 The webpage at 
 http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*rows=0 might 
 be temporarily down or it may have moved permanently to a new web address.
 Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
 If the param rows is set to rows=4 or superior the query return data as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-949) AnalyzingQueryParser can't work with leading wildcards.

2013-04-02 Thread Timothy Allison (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Allison updated LUCENE-949:
---

Attachment: AnalyzingQueryParser.java

This allows for leading wildcards in the AnalyzingQueryParser if 
setAllowLeadingWildcard is set to true.

 AnalyzingQueryParser can't work with leading wildcards.
 ---

 Key: LUCENE-949
 URL: https://issues.apache.org/jira/browse/LUCENE-949
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/queryparser
Affects Versions: 2.2
Reporter: Stefan Klein
 Attachments: AnalyzingQueryParser.java


 The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following 
 changes to accept leading wildcards:
   protected Query getWildcardQuery(String field, String termStr) throws 
 ParseException
   {
   String useTermStr = termStr;
   String leadingWildcard = null;
   if (*.equals(field))
   {
   if (*.equals(useTermStr))
   return new MatchAllDocsQuery();
   }
   boolean hasLeadingWildcard = (useTermStr.startsWith(*) || 
 useTermStr.startsWith(?)) ? true : false;
   if (!getAllowLeadingWildcard()  hasLeadingWildcard)
   throw new ParseException('*' or '?' not allowed as 
 first character in WildcardQuery);
   if (getLowercaseExpandedTerms())
   {
   useTermStr = useTermStr.toLowerCase();
   }
   if (hasLeadingWildcard)
   {
   leadingWildcard = useTermStr.substring(0, 1);
   useTermStr = useTermStr.substring(1);
   }
   List tlist = new ArrayList();
   List wlist = new ArrayList();
   /*
* somewhat a hack: find/store wildcard chars in order to put 
 them back
* after analyzing
*/
   boolean isWithinToken = (!useTermStr.startsWith(?)  
 !useTermStr.startsWith(*));
   isWithinToken = true;
   StringBuffer tmpBuffer = new StringBuffer();
   char[] chars = useTermStr.toCharArray();
   for (int i = 0; i  useTermStr.length(); i++)
   {
   if (chars[i] == '?' || chars[i] == '*')
   {
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = false;
   }
   else
   {
   if (!isWithinToken)
   {
   wlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = true;
   }
   tmpBuffer.append(chars[i]);
   }
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   }
   else
   {
   wlist.add(tmpBuffer.toString());
   }
   // get Analyzer from superclass and tokenize the term
   TokenStream source = getAnalyzer().tokenStream(field, new 
 StringReader(useTermStr));
   org.apache.lucene.analysis.Token t;
   int countTokens = 0;
   while (true)
   {
   try
   {
   t = source.next();
   }
   catch (IOException e)
   {
   t = null;
   }
   if (t == null)
   {
   break;
   }
   if (!.equals(t.termText()))
   {
   try
   {
   tlist.set(countTokens++, t.termText());
   }
   catch (IndexOutOfBoundsException ioobe)
   {
   countTokens = -1;
   }
   }
   }
   try
   {
   source.close();
   }
   catch (IOException e)
   {
   // ignore
   }

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI

2013-04-02 Thread Aditya (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620037#comment-13620037
 ] 

Aditya commented on SOLR-4661:
--

Double checked .. and everything looks good. Step to reproduce this issue is 
simple. Just apply commit on master without posting any documents. The next 
replication you will see the difference of Version and gen on Slave. I remember 
in Solr3.5 applying commit with no pending document will not increment the 
version and gen on master. 

JVM
Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 
23.5-b02)
Processors : 4
Args:
-Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties
-Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxPermSize=256m
-Xmx3g
-Xms3g
-Djboss.server.default.config=standalone.xml
-Djava.awt.headless=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-Dsolr.data.dir=/storage/solrdata/
-Denable.slave=true
-Denable.master=false
-Dsolr.solr.home=/opt/solr
-Dorg.jboss.resolver.warning=true
-Djava.net.preferIPv4Stack=true
-XX:+TieredCompilation
-XX:+UseCompressedOops
-D[Standalone]

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4661) Index Version Gen Number out of sync on Admin UI

2013-04-02 Thread Aditya (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620037#comment-13620037
 ] 

Aditya edited comment on SOLR-4661 at 4/2/13 5:41 PM:
--

Double checked .. and everything looks good. Step to reproduce this issue is 
simple. Just apply commit on master without posting any documents. The next 
replication you will see the difference of Version and gen on Slave. I remember 
in Solr3.5 applying commit with no pending document will not increment the 
version and gen on master. 


From the Slave ---
JVM
Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 
23.5-b02)
Processors : 4
Args:
-Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties
-Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxPermSize=256m
-Xmx3g
-Xms3g
-Djboss.server.default.config=standalone.xml
-Djava.awt.headless=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-Dsolr.data.dir=/storage/solrdata/
-Denable.slave=true
-Denable.master=false
-Dsolr.solr.home=/opt/solr
-Dorg.jboss.resolver.warning=true
-Djava.net.preferIPv4Stack=true
-XX:+TieredCompilation
-XX:+UseCompressedOops
-D[Standalone]

  was (Author: abakle):
Double checked .. and everything looks good. Step to reproduce this issue 
is simple. Just apply commit on master without posting any documents. The next 
replication you will see the difference of Version and gen on Slave. I remember 
in Solr3.5 applying commit with no pending document will not increment the 
version and gen on master. 

JVM
Runtime : Oracle Corporation Java HotSpot(TM) 64-Bit Server VM (1.7.0_09 
23.5-b02)
Processors : 4
Args:
-Dlogging.configuration=file:/opt/jboss/standalone/configuration/logging.properties
-Dorg.jboss.boot.log.file=/opt/jboss/standalone/log/boot.log
-XX:+UseG1GC
-XX:+UnlockExperimentalVMOptions
-XX:MaxPermSize=256m
-Xmx3g
-Xms3g
-Djboss.server.default.config=standalone.xml
-Djava.awt.headless=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-Dsolr.data.dir=/storage/solrdata/
-Denable.slave=true
-Denable.master=false
-Dsolr.solr.home=/opt/solr
-Dorg.jboss.resolver.warning=true
-Djava.net.preferIPv4Stack=true
-XX:+TieredCompilation
-XX:+UseCompressedOops
-D[Standalone]
  
 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-949) AnalyzingQueryParser can't work with leading wildcards.

2013-04-02 Thread Timothy Allison (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620036#comment-13620036
 ] 

Timothy Allison edited comment on LUCENE-949 at 4/2/13 5:42 PM:


This allows for leading wildcards in the AnalyzingQueryParser if 
setAllowLeadingWildcard is set to true.  

  was (Author: talli...@mitre.org):
This allows for leading wildcards in the AnalyzingQueryParser if 
setAllowLeadingWildcard is set to true.
  
 AnalyzingQueryParser can't work with leading wildcards.
 ---

 Key: LUCENE-949
 URL: https://issues.apache.org/jira/browse/LUCENE-949
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/queryparser
Affects Versions: 2.2
Reporter: Stefan Klein
 Attachments: AnalyzingQueryParser.java


 The getWildcardQuery mehtod in AnalyzingQueryParser.java need the following 
 changes to accept leading wildcards:
   protected Query getWildcardQuery(String field, String termStr) throws 
 ParseException
   {
   String useTermStr = termStr;
   String leadingWildcard = null;
   if (*.equals(field))
   {
   if (*.equals(useTermStr))
   return new MatchAllDocsQuery();
   }
   boolean hasLeadingWildcard = (useTermStr.startsWith(*) || 
 useTermStr.startsWith(?)) ? true : false;
   if (!getAllowLeadingWildcard()  hasLeadingWildcard)
   throw new ParseException('*' or '?' not allowed as 
 first character in WildcardQuery);
   if (getLowercaseExpandedTerms())
   {
   useTermStr = useTermStr.toLowerCase();
   }
   if (hasLeadingWildcard)
   {
   leadingWildcard = useTermStr.substring(0, 1);
   useTermStr = useTermStr.substring(1);
   }
   List tlist = new ArrayList();
   List wlist = new ArrayList();
   /*
* somewhat a hack: find/store wildcard chars in order to put 
 them back
* after analyzing
*/
   boolean isWithinToken = (!useTermStr.startsWith(?)  
 !useTermStr.startsWith(*));
   isWithinToken = true;
   StringBuffer tmpBuffer = new StringBuffer();
   char[] chars = useTermStr.toCharArray();
   for (int i = 0; i  useTermStr.length(); i++)
   {
   if (chars[i] == '?' || chars[i] == '*')
   {
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = false;
   }
   else
   {
   if (!isWithinToken)
   {
   wlist.add(tmpBuffer.toString());
   tmpBuffer.setLength(0);
   }
   isWithinToken = true;
   }
   tmpBuffer.append(chars[i]);
   }
   if (isWithinToken)
   {
   tlist.add(tmpBuffer.toString());
   }
   else
   {
   wlist.add(tmpBuffer.toString());
   }
   // get Analyzer from superclass and tokenize the term
   TokenStream source = getAnalyzer().tokenStream(field, new 
 StringReader(useTermStr));
   org.apache.lucene.analysis.Token t;
   int countTokens = 0;
   while (true)
   {
   try
   {
   t = source.next();
   }
   catch (IOException e)
   {
   t = null;
   }
   if (t == null)
   {
   break;
   }
   if (!.equals(t.termText()))
   {
   try
   {
   tlist.set(countTokens++, t.termText());
   }
   catch (IndexOutOfBoundsException ioobe)
   {
   countTokens = -1;
   }

[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set

2013-04-02 Thread Yonik Seeley (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620064#comment-13620064
]

Yonik Seeley commented on SOLR-4478:

bq. 2 property in core.properties is configName?

Yes, we need to align this with solr cloud config as much as possible.
Having configSet in some places and configName in other places isn't so hot ;-)

Allow cores to specify a named config set
-

Key: SOLR-4478
URL: https://issues.apache.org/jira/browse/SOLR-4478
Project: Solr
Issue Type: Improvement
Affects Versions: 4.2, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson

Part of moving forward to the new way, after SOLR-4196 etc... I propose an
additional parameter specified on the core node in solr.xml or as a
parameter in the discovery mode core.properties file, call it configSet,
where the value provided is a path to a directory, either absolute or
relative. Really, this is as though you copied the conf directory somewhere
to be used by more than one core.
Straw-man: There will be a directory solr_home/configsets which will be the
default. If the configSet parameter is, say, myconf, then I'd expect a
directory named myconf to exist in solr_home/configsets, which would look
something like
solr_home/configsets/myconf/schema.xml
solrconfig.xml
stopwords.txt
velocity
velocity/query.vm
etc.
If multiple cores used the same configSet, schema, solrconfig etc. would all
be shared (i.e. shareSchema=true would be assumed). I don't see a good
use-case for _not_ sharing schemas, so I don't propose to allow this to be
turned off. Hmmm, what if shareSchema is explicitly set to false in the
solr.xml or properties file? I'd guess it should be honored but maybe log a
warning?
Mostly I'm putting this up for comments. I know that there are already
thoughts about how this all should work floating around, so before I start
any work on this I thought I'd at least get an idea of whether this is the
way people are thinking about going.
Configset can be either a relative or absolute path, if relative it's assumed
to be relative to solr_home.
Thoughts?

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4661) Index Version Gen Number out of sync on Admin UI


[ 
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620073#comment-13620073
 ] 

Hoss Man commented on SOLR-4661:


Aditya: in your thread on the solr-user@lucene list, you posted some other 
examples of the generation being higher on the slave then on the master, and 
you also posted some short log files from both your master  slave, but the log 
files you posted don't seem to directly correspond to the snippets you posted 
from requesting /replication?command=details in any of your mails or in this 
issue (the generation numbers logged by SnapPuller on the slave don't match up)

Can you please attach a zip file containing a single cohesive example of:
* a master solrconfig.xml
* a slave solrconfig.xml (if different)
* the log files for both the master and slave from JVM startup to jvm shutdown
* any number of files containing the full response of getting the replication 
details form the master  slave _with_ the timestamp of when these files were 
generated.

The timestamps being crucial to helping us stitch together where in the flow of 
log messages you are seeing this inconsistency.

If you are using bash, running two commands like this (one for master and one 
for slave) while solr is running should be suitable...

{noformat}
while true; do date --utc  curl -sS 
http://localhost:8983/solr/collection1/replication?command=detailsindent=truewt=json;
  echo  echo  sleep 2; done 21  slave_rep_details.txt
{noformat}

 Index Version  Gen Number out of sync on Admin UI
 --

 Key: SOLR-4661
 URL: https://issues.apache.org/jira/browse/SOLR-4661
 Project: Solr
  Issue Type: Bug
  Components: replication (java), web gui
Affects Versions: 4.2
 Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
Reporter: Aditya
  Labels: gui, replication, web
 Attachments: IndexVersionSyncIssue.jpg


 Index and Gen number on Slave is higher than master. 
 If you apply commit on master with no pending docs then the commit time stamp 
 and gen is incremented. When Slaves polls master for replication it see the 
 index version difference and starts replicating but all files are skipped. 
 On Admin UI (on Slaves) the version number displayed for master is old where 
 as for slave is the latest which is higher than master.
 Below is the response from master (/replication?command=details) where i see 
 two different Version an Gen numbers. This creates confusion of having 
 version out of sync, though its not. 
 response
 lst name=responseHeader
 int name=status0/int
 int name=QTime1/int
 /lst
 lst name=details
 str name=indexSize1.52 GB/str
 str name=indexPath/storage/solrdata/index//str
 arr name=commits
 lst
 long name=indexVersion{color:red}1364835609803{color}/long
 long name=generation{color:red}34{color}/long
 arr name=filelist.../arr
 /lst
 /arr
 str name=isMastertrue/str
 str name=isSlavefalse/str
 long name=indexVersion{color:red}1364778010902{color}/long
 long name=generation{color:red}31{color}/long
 lst name=master
 str name=confFilesschema.xml/str
 arr name=replicateAfter
 strcommit/str
 strstartup/str
 /arr
 str name=replicationEnabledtrue/str
 long name=replicatableGeneration34/long
 /lst
 /lst
 str name=WARNING
 This response format is experimental. It is likely to change in the future.
 /str
 /response

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4653) Solr configuration should log inaccessible/ non-existent relative paths lib dir=...


[ 
https://issues.apache.org/jira/browse/SOLR-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13620093#comment-13620093
 ] 

Dawid Weiss commented on SOLR-4653:
---

I saw the comment about glob patterns, Uwe. I just won't have the time to do it 
thoroughly (with proper testing etc.) so I'd rather file another issue for it. 
If somebody can get there sooner, fine. If not, I'll fix it in my spare cycles 
at some point.

 Solr configuration should log inaccessible/ non-existent relative paths lib 
 dir=...
 ---

 Key: SOLR-4653
 URL: https://issues.apache.org/jira/browse/SOLR-4653
 Project: Solr
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Attachments: SOLR-4653.patch


 Currently the dir path is resolved relative to core's instanceDir but if you 
 don't know it nothing happens (no warning, no nothing). This is very 
 frustrating.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-4664) ZkStateReader should update aliases on construction.

Mark Miller created SOLR-4664:
-

 Summary: ZkStateReader should update aliases on construction.
 Key: SOLR-4664
 URL: https://issues.apache.org/jira/browse/SOLR-4664
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.3, 5.0


Currently they just use a watcher, so if you create the zkstatereader after 
updating aliases, it won't see them, unless another update happens. This might 
be done most often with CloudSolrServer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4664) ZkStateReader should update aliases on construction.