date:20120312

2012-03-12 Thread Stefan Matheis (steffkes) (Assigned) (JIRA)


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

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

Any more comments on this before we move on? How do you feel about leaving 
indexConfig and mainIndex sections as is in all the test solrconfigs, but 
update the DIH example configs? We can tackle upgrading all the test files in 
4.x in another issue.

 Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
 --

 Key: SOLR-1052
 URL: https://issues.apache.org/jira/browse/SOLR-1052
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Jan Høydahl
Priority: Minor
  Labels: solrconfig.xml
 Fix For: 3.6, 4.0

 Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch, 
 SOLR-1052-3x.patch


 Given that we now handle multiple cores via the solr.xml and the discussion 
 around indexDefaults and mainIndex at 
 http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults
 We should deprecate/remove the use of indexDefaults and just rely on 
 mainIndex, as it doesn't seem to serve any purpose and is confusing to 
 explain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3864) support offsets in MemoryPostings

2012-03-12 Thread Michael McCandless (Commented) (JIRA)


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

Michael McCandless commented on LUCENE-3864:


Patch looks good!

 support offsets in MemoryPostings
 -

 Key: LUCENE-3864
 URL: https://issues.apache.org/jira/browse/LUCENE-3864
 Project: Lucene - Java
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Robert Muir
 Attachments: LUCENE-3864.patch, LUCENE-3864.patch


 Really we should add this for Sep  Pulsing too... but this is one more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3208) Implement Logging UI with /admin/logging handler


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

Stefan Matheis (steffkes) reassigned SOLR-3208:
---

Assignee: Stefan Matheis (steffkes)

 Implement Logging UI with /admin/logging handler
 

 Key: SOLR-3208
 URL: https://issues.apache.org/jira/browse/SOLR-3208
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Ryan McKinley
Assignee: Stefan Matheis (steffkes)
Priority: Blocker
 Fix For: 4.0


 The admin UI currently uses a stub /logging.json to display a tree.  It 
 should use the LogLevelHandler

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (SOLR-3208) Implement Logging UI with /admin/logging handler

2012-03-12 Thread Stefan Matheis (steffkes) (Resolved) (JIRA)


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

Stefan Matheis (steffkes) resolved SOLR-3208.
-

Resolution: Fixed

Removed Stub and use LogLevelHandler, which was implemented in SOLR-2459

 Implement Logging UI with /admin/logging handler
 

 Key: SOLR-3208
 URL: https://issues.apache.org/jira/browse/SOLR-3208
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Ryan McKinley
Assignee: Stefan Matheis (steffkes)
Priority: Blocker
 Fix For: 4.0


 The admin UI currently uses a stub /logging.json to display a tree.  It 
 should use the LogLevelHandler

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler

2012-03-12 Thread Stefan Matheis (steffkes) (Assigned) (JIRA)


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

Stefan Matheis (steffkes) reassigned SOLR-3232:
---

Assignee: Stefan Matheis (steffkes)

 Admin UI: query form should have a menu to pick a request handler
 -

 Key: SOLR-3232
 URL: https://issues.apache.org/jira/browse/SOLR-3232
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0


 The query form in the admin UI could use an improvement regarding how the 
 request handler is chosen; presently all there is is a text input for 'qt'.  
 The first choice to make in the form above the query should really be the 
 request handler since it actually handles the request before any other 
 parameters do anything.  It'd be great if it was a dynamically driven menu 
 defaulting to /select.  Similar to how the DIH page finds DIH request 
 handlers, this page could find the request handlers with a class of 
 SearchHandler.  Their names would be added to a list, and if the name 
 didn't start with a '/' then it would be prefixed with '/select?qt='.
 I did something similar (without the menu) to the old 3x UI in a patch to 
 SOLR-3161 which will hopefully get committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler

2012-03-12 Thread Stefan Matheis (steffkes) (Updated) (JIRA)


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

Stefan Matheis (steffkes) updated SOLR-3232:


Attachment: SOLR-3232.patch

Something like that David?

Actually i'm getting /browse and search as possible Handlers, i guess this 
is because SOLR-3161 is pending, right?

 Admin UI: query form should have a menu to pick a request handler
 -

 Key: SOLR-3232
 URL: https://issues.apache.org/jira/browse/SOLR-3232
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3232.patch


 The query form in the admin UI could use an improvement regarding how the 
 request handler is chosen; presently all there is is a text input for 'qt'.  
 The first choice to make in the form above the query should really be the 
 request handler since it actually handles the request before any other 
 parameters do anything.  It'd be great if it was a dynamically driven menu 
 defaulting to /select.  Similar to how the DIH page finds DIH request 
 handlers, this page could find the request handlers with a class of 
 SearchHandler.  Their names would be added to a list, and if the name 
 didn't start with a '/' then it would be prefixed with '/select?qt='.
 I did something similar (without the menu) to the old 3x UI in a patch to 
 SOLR-3161 which will hopefully get committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Exposing Solr routing to SolrJ client

2012-03-12 Thread Stefan Matheis (steffkes) (Created) (JIRA)

Hey Per,

A couple things:

1. Distributed realtime get is coming - I know Yonik was looking at this 
recently but got caught up in some other things.

2. There is a Solrj client that is aware of the cluster state - its called 
CloudSolrServer. You give it the zookeeper address rather than a node's 
address. Currently it doesn't send directly to the leader, but this is planned 
- it's a little tricky due to lack of access to the Schema for hashing, but 
likely coming soon - there is a JIRA issue for it. Clients in other languages 
should be able to do the same thing.

- Mark

On Mar 12, 2012, at 5:26 AM, Per Steffensen wrote:

 Hi
 
 I believe Solr(Cloud) is doing some internal routing of update-requests to 
 make sure documents are stored in the correct core/shard decided by Solrs 
 internal routing algoritm (I believe it basically finds out who is the 
 leader-shard for a given document, using shared information in ZK, info about 
 the collection and hash(document.id)). All nice and cool.
 
 I also believe realtime-gets are not forwarded internally in Solr through 
 this routing algorithm, and that it therefore is impossible to do 
 realtime-gets from a client, because you dont know which core/shard to 
 contact directly, again because you dont know the routing alogrithm. If Im 
 wrong, it would be very helpfull with a few directions on how to do 
 realtime-gets from a client to a Solr servers system containing many shards 
 and collection. If Im right, I think it would be very nice if the the routing 
 algorithm was somehow exposed to the client (in code reachable from SolrJ) so 
 that you can get to do realtime-gets from a SolrJ-based client - if it should 
 be done automatically for you of if the client using SolrJ explicitly needs 
 to call some code to get info about the core to contact, is not so important 
 for now.
 
 Such a solution would also make it possible to get rid of another performance 
 related problem, that most update-requests has to be transported among JVMs 
 twice to reach their destination. First from client to some random Solr 
 server, and then from this Solr server to the Solr server holding the core 
 involved in the update. If routing information was available for the client 
 it could make sure to route its updates directly to the core (the one 
 currently playing the role as leader-shard for the shard to which the routing 
 algorithm maps the document) involved in the update.
 
 ElasticSearch has a solution to this problem by the usage of Node Client 
 (instead of just Transport Client), where a node client is basically a real 
 node in the system that just doesnt store document, but which have all the 
 logic and shared information like e.g. routing algorithm available - 
 http://www.elasticsearch.org/guide/reference/java-api/client.html. It 
 certainly doesnt have to be like that with Solr clients, but it would be nice 
 if somehow routing logic where available to the SolrJ so that it can send its 
 updates (and realtime-gets) directly to the correct destination.
 
 Hope to get some comments on this issue.
 
 Regards, Per Steffensen
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

- Mark Miller
lucidimagination.com












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

[jira] [Created] (SOLR-3234) Remove contrib/dataimporthandler's webapp jsp

Remove contrib/dataimporthandler's webapp jsp
-

 Key: SOLR-3234
 URL: https://issues.apache.org/jira/browse/SOLR-3234
 Project: Solr
  Issue Type: Task
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor


the contrib/dataimporthandler contains .jsp files which are copied to the main 
.war file using the 
[add-to-war|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/contrib-build.xml?view=markup#L34]
 target of solr/contrib/contrib-build.xml

I guess the build-target is still okay, since it may be needed that additional 
files are deployed to the admin-area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3234) Remove contrib/dataimporthandler's webapp jsp

2012-03-12 Thread Stefan Matheis (steffkes) (Updated) (JIRA)


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

Stefan Matheis (steffkes) updated SOLR-3234:


Attachment: SOLR-3234.patch

Remove .jsp files from dataimporthandler

 Remove contrib/dataimporthandler's webapp jsp
 -

 Key: SOLR-3234
 URL: https://issues.apache.org/jira/browse/SOLR-3234
 Project: Solr
  Issue Type: Task
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Attachments: SOLR-3234.patch


 the contrib/dataimporthandler contains .jsp files which are copied to the 
 main .war file using the 
 [add-to-war|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/contrib-build.xml?view=markup#L34]
  target of solr/contrib/contrib-build.xml
 I guess the build-target is still okay, since it may be needed that 
 additional files are deployed to the admin-area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (LUCENE-3855) TestStressNRT failures (reproducible)

2012-03-12 Thread Michael McCandless (Resolved) (JIRA)


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

Michael McCandless resolved LUCENE-3855.


Resolution: Fixed

 TestStressNRT failures (reproducible)
 -

 Key: LUCENE-3855
 URL: https://issues.apache.org/jira/browse/LUCENE-3855
 Project: Lucene - Java
  Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Michael McCandless
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3855.patch, 
 hoss-r1298470-fixed-seed__TEST-org.apache.lucene.index.TestStressNRT.xml, 
 output1.log, output2.log, output3.log, output4.log


 Build server logs. Reproduces on at least two machines.
 {noformat}
 [junit] - Standard Error -
 [junit] NOTE: reproduce with: ant test -Dtestcase=TestStressNRT 
 -Dtestmethod=test 
 -Dtests.seed=69468941c1bbf693:19e66d58475da929:69e9d2f81769b6d0 
 -Dargs=-Dfile.encoding=UTF-8
 [junit] NOTE: test params are: codec=Lucene3x, 
 sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=ro, 
 timezone=Etc/GMT+1
 [junit] NOTE: all tests run in this JVM:
 [junit] [TestStressNRT]
 [junit] NOTE: Linux 3.0.0-16-generic amd64/Sun Microsystems Inc. 1.6.0_27 
 (64-bit)/cpus=2,threads=1,free=74960064,total=135987200
 [junit] -  ---
 [junit] Testcase: test(org.apache.lucene.index.TestStressNRT):Caused 
 an ERROR
 [junit] MockDirectoryWrapper: cannot close: there are still open files: 
 {_ng.cfs=8}
 [junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close: 
 there are still open files: {_ng.cfs=8}
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
 [junit]   at 
 org.apache.lucene.index.TestStressNRT.test(TestStressNRT.java:385)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:743)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:639)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:538)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:600)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
 [junit]   at 
 org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
 [junit]   at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
 [junit]   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 [junit] Caused by: java.lang.RuntimeException: unclosed IndexInput: 
 _ng.cfs
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
 [junit]   at 
 org.apache.lucene.store.MockDirectoryWrapper$1.openSlice(MockDirectoryWrapper.java:777)
 [junit]   at 
 org.apache.lucene.store.CompoundFileDirectory.openInput(CompoundFileDirectory.java:221)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.TermInfosReader.init(TermInfosReader.java:112)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xFields.init(Lucene3xFields.java:84)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat$1.init(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.codecs.lucene3x.PreFlexRWPostingsFormat.fieldsProducer(PreFlexRWPostingsFormat.java:51)
 [junit]   at 
 org.apache.lucene.index.SegmentCoreReaders.init(SegmentCoreReaders.java:108)
 [junit]   at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:51)
 [junit]   at 
 org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3587)
 [junit]   at 
 org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
 [junit]   at 
 org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
 [junit] 
 [junit] 
 [junit] Test org.apache.lucene.index.TestStressNRT FAILED
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SOLR-3159) Upgrade to Jetty 8

2012-03-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)

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

Stefan Matheis (steffkes) commented on SOLR-3159:
-

bq. Another little glitch i just noticed is that aparently with the new jetty
configs JSP support isn't enabled? loading http://localhost:8983/solr/ works
fine, but http://localhost:8983/solr/admin/dataimport.jsp gives a 500 error
JSP support not configured

Yepp, just created SOLR-3234 for that. We have just missed them, while sorting
out all JSP-Files in SOLR-3202. They should be no longer required ,since we use
now Handlers and Servlets for all the UI related stuff.

Upgrade to Jetty 8
--

Key: SOLR-3159
URL: https://issues.apache.org/jira/browse/SOLR-3159
Project: Solr
Issue Type: Task
Reporter: Ryan McKinley
Priority: Minor
Fix For: 4.0

Attachments: SOLR-3159-maven.patch

Solr is currently tested (and bundled) with a patched jetty-6 version.
Ideally we can release and test with a standard version.
Jetty-6 (at codehaus) is just maintenance now. New development and
improvements are now hosted at eclipse. Assuming performance is equivalent,
I think we should switch to Jetty 8.

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

[jira] [Resolved] (LUCENE-3864) support offsets in MemoryPostings

2012-03-12 Thread Robert Muir (Resolved) (JIRA)


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

Robert Muir resolved LUCENE-3864.
-

   Resolution: Fixed
Fix Version/s: 4.0

thanks for reviewing Mike

 support offsets in MemoryPostings
 -

 Key: LUCENE-3864
 URL: https://issues.apache.org/jira/browse/LUCENE-3864
 Project: Lucene - Java
  Issue Type: Improvement
Affects Versions: 4.0
Reporter: Robert Muir
 Fix For: 4.0

 Attachments: LUCENE-3864.patch, LUCENE-3864.patch


 Really we should add this for Sep  Pulsing too... but this is one more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (SOLR-3235) Whitespace issue in synonym list

2012-03-12 Thread Johannes Brucher (Created) (JIRA)

Whitespace issue in synonym list


 Key: SOLR-3235
 URL: https://issues.apache.org/jira/browse/SOLR-3235
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 3.5, 3.4
 Environment: Windows 7
Firefox 10.0.2
Solr example (start.jar)
Reporter: Johannes Brucher


If you use the following schema.xml entrie:

fieldType name=contenttype class=solr.TextField  multiValued=true 
omitNorms=true
  analyzer type=index
   tokenizer class=solr.KeywordTokenizerFactory/
 filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=false/
   /analyzer
   analyzer type=query
 tokenizer class=solr.KeywordTokenizerFactory/
   /analyzer
/fieldType

With a synonym list having such entrie:

text/html;\ charset=ISO-8859-1 = html

Solr 3.4 and 3.5 can't handle the whitespace between html; and charset and 
no synonym substitution is processed. The same config works find in Solr 3.3.
No exception or error is thrown.

This is my first jira ticket, so if I mist something let me know...


Regrads


Johannes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3026) eDismax: Locking down which fields can be explicitly queried (user fields aka uf)

2012-03-12 Thread Updated


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

Jan Høydahl updated SOLR-3026:
--

Attachment: SOLR-3026-3x.patch

Attaching patch for branch_3x.

 eDismax: Locking down which fields can be explicitly queried (user fields aka 
 uf)
 -

 Key: SOLR-3026
 URL: https://issues.apache.org/jira/browse/SOLR-3026
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-3026-3x.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch


 We need a way to specify exactly what fields should be available to the end 
 user as fielded search.
 In the original SOLR-1553, there's a patch implementing user fields, but it 
 was never committed even if that issue was closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3234) Remove contrib/dataimporthandler's webapp jsp

2012-03-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


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

Erik Hatcher commented on SOLR-3234:


I haven't looked, but is the functionality provided by these JSPs recreated 
with the ajax/HTML UI now?

 Remove contrib/dataimporthandler's webapp jsp
 -

 Key: SOLR-3234
 URL: https://issues.apache.org/jira/browse/SOLR-3234
 Project: Solr
  Issue Type: Task
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Attachments: SOLR-3234.patch


 the contrib/dataimporthandler contains .jsp files which are copied to the 
 main .war file using the 
 [add-to-war|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/contrib-build.xml?view=markup#L34]
  target of solr/contrib/contrib-build.xml
 I guess the build-target is still okay, since it may be needed that 
 additional files are deployed to the admin-area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3231) Add the ability to KStemmer to preserve the original token when stemming

2012-03-12 Thread Jamie Johnson (Commented) (JIRA)


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

Jamie Johnson commented on SOLR-3231:
-

this should (unless I messed it up which is possible) also produce a token for 
the original term.  For instance if the term was bricks it should produce 
tokens for bricks and brick.  If that's not the case please let me know.

{code:title=TestKStemFilterFactory.java|borderStyle=solid}
package org.apache.solr.analysis;

import java.io.Reader;
import java.io.StringReader;

import org.apache.lucene.analysis.MockTokenizer;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.tokenattributes.CharTermAttribute;

/**
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the License); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

/**
 * Simple tests to ensure the kstem filter factory is working.
 */
public class TestKStemFilterFactory extends BaseTokenTestCase {
  public void testStemming() throws Exception {
Reader reader = new StringReader(bricks);
KStemFilterFactory factory = new KStemFilterFactory();
TokenStream stream = factory.create(new MockTokenizer(reader, 
MockTokenizer.WHITESPACE, false));
assertTokenStreamContents(stream, new String[] { bricks, brick }, new 
int[]{1, 0});

  }
}

{code} 

That is what this tests right?

 Add the ability to KStemmer to preserve the original token when stemming
 

 Key: SOLR-3231
 URL: https://issues.apache.org/jira/browse/SOLR-3231
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Jamie Johnson
 Attachments: KStemFilter.patch


 While using the PorterStemmer, I found that there were often times that it 
 was far to aggressive in it's stemming.  In my particular case it is 
 unrealistic to provide a protected word list which captures all possible 
 words which should not be stemmed.  To avoid this I proposed a solution 
 whereby we store the original token as well as the stemmed token so exact 
 searches would always work.  Based on discussions on the mailing list Ahmet 
 Arslan, I believe the attached patch to KStemmer provides the desired 
 capabilities through a configuration parameter.  This largely is a copy of 
 the org.apache.lucene.wordnet.SynonymTokenFilter.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-788) MoreLikeThis should support distributed search

2012-03-12 Thread Jamie Johnson (Commented) (JIRA)


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

Jamie Johnson commented on SOLR-788:


I haven't had a chance to really play with this lately, can you give an example 
of the query you are running?

 MoreLikeThis should support distributed search
 --

 Key: SOLR-788
 URL: https://issues.apache.org/jira/browse/SOLR-788
 Project: Solr
  Issue Type: Improvement
  Components: MoreLikeThis
Reporter: Grant Ingersoll
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: AlternateDistributedMLT.patch, MLT.patch, 
 MoreLikeThisComponentTest.patch, SolrMoreLikeThisPatch.txt


 The MoreLikeThis component should support distributed processing.
 See SOLR-303.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3235) Whitespace issue in synonym list

2012-03-12 Thread Johannes Brucher (Updated) (JIRA)


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

Johannes Brucher updated SOLR-3235:
---

Fix Version/s: 3.4
  Description: 
If you use the following schema.xml entrie:

fieldType name=contenttype class=solr.TextField  multiValued=true 
omitNorms=true
  analyzer type=index
   tokenizer class=solr.KeywordTokenizerFactory/
 filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=false/
   /analyzer
   analyzer type=query
 tokenizer class=solr.KeywordTokenizerFactory/
   /analyzer
/fieldType

With a synonym list having such entrie:

text/html;\ charset=ISO-8859-1 = html

Solr 3.4 and 3.5 can't handle the whitespace between html; and charset and 
no synonym substitution is processed. The same config works find in Solr 3.3.
No exception or error is thrown.

This is my first jira ticket, so if I mist something let me know...


Regrads


Johannes

Edit: Ok found the solution for that problem. Provide the following:

filter class=solr.SynonymFilterFactory synonyms=synonyms.txt 
ignoreCase=true expand=false
tokenizerFactory=solr.KeywordTokenizerFactory /

As tokenizerFactory you should use solr.KeywordTokenizerFactory instead of 
solr.WhitespaceTokenizerFactory.

See the javadocs for more details:
https://builds.apache.org/job/Solr-trunk/javadoc/org/apache/solr/analysis/SynonymFilterFactory.html


  was:
If you use the following schema.xml entrie:

fieldType name=contenttype class=solr.TextField  multiValued=true 
omitNorms=true
  analyzer type=index
   tokenizer class=solr.KeywordTokenizerFactory/
 filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=false/
   /analyzer
   analyzer type=query
 tokenizer class=solr.KeywordTokenizerFactory/
   /analyzer
/fieldType

With a synonym list having such entrie:

text/html;\ charset=ISO-8859-1 = html

Solr 3.4 and 3.5 can't handle the whitespace between html; and charset and 
no synonym substitution is processed. The same config works find in Solr 3.3.
No exception or error is thrown.

This is my first jira ticket, so if I mist something let me know...


Regrads


Johannes

   Issue Type: New Feature  (was: Bug)

 Whitespace issue in synonym list
 

 Key: SOLR-3235
 URL: https://issues.apache.org/jira/browse/SOLR-3235
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 3.4, 3.5
 Environment: Windows 7
 Firefox 10.0.2
 Solr example (start.jar)
Reporter: Johannes Brucher
  Labels: synonyms
 Fix For: 3.4


 If you use the following schema.xml entrie:
 fieldType name=contenttype class=solr.TextField  multiValued=true 
 omitNorms=true
   analyzer type=index
tokenizer class=solr.KeywordTokenizerFactory/
  filter class=solr.SynonymFilterFactory 
 synonyms=synonyms.txt ignoreCase=true expand=false/
/analyzer
analyzer type=query
  tokenizer class=solr.KeywordTokenizerFactory/
/analyzer
 /fieldType
 With a synonym list having such entrie:
 text/html;\ charset=ISO-8859-1 = html
 Solr 3.4 and 3.5 can't handle the whitespace between html; and charset 
 and no synonym substitution is processed. The same config works find in Solr 
 3.3.
 No exception or error is thrown.
 This is my first jira ticket, so if I mist something let me know...
 Regrads
 Johannes
 Edit: Ok found the solution for that problem. Provide the following:
 filter class=solr.SynonymFilterFactory synonyms=synonyms.txt 
 ignoreCase=true expand=false
   tokenizerFactory=solr.KeywordTokenizerFactory /
 As tokenizerFactory you should use solr.KeywordTokenizerFactory instead of 
 solr.WhitespaceTokenizerFactory.
 See the javadocs for more details:
 https://builds.apache.org/job/Solr-trunk/javadoc/org/apache/solr/analysis/SynonymFilterFactory.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (SOLR-3235) Whitespace issue in synonym list

2012-03-12 Thread Johannes Brucher (Resolved) (JIRA)


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

Johannes Brucher resolved SOLR-3235.


Resolution: Not A Problem

 Whitespace issue in synonym list
 

 Key: SOLR-3235
 URL: https://issues.apache.org/jira/browse/SOLR-3235
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 3.4, 3.5
 Environment: Windows 7
 Firefox 10.0.2
 Solr example (start.jar)
Reporter: Johannes Brucher
  Labels: synonyms
 Fix For: 3.4


 If you use the following schema.xml entrie:
 fieldType name=contenttype class=solr.TextField  multiValued=true 
 omitNorms=true
   analyzer type=index
tokenizer class=solr.KeywordTokenizerFactory/
  filter class=solr.SynonymFilterFactory 
 synonyms=synonyms.txt ignoreCase=true expand=false/
/analyzer
analyzer type=query
  tokenizer class=solr.KeywordTokenizerFactory/
/analyzer
 /fieldType
 With a synonym list having such entrie:
 text/html;\ charset=ISO-8859-1 = html
 Solr 3.4 and 3.5 can't handle the whitespace between html; and charset 
 and no synonym substitution is processed. The same config works find in Solr 
 3.3.
 No exception or error is thrown.
 This is my first jira ticket, so if I mist something let me know...
 Regrads
 Johannes
 Edit: Ok found the solution for that problem. Provide the following:
 filter class=solr.SynonymFilterFactory synonyms=synonyms.txt 
 ignoreCase=true expand=false
   tokenizerFactory=solr.KeywordTokenizerFactory /
 As tokenizerFactory you should use solr.KeywordTokenizerFactory instead of 
 solr.WhitespaceTokenizerFactory.
 See the javadocs for more details:
 https://builds.apache.org/job/Solr-trunk/javadoc/org/apache/solr/analysis/SynonymFilterFactory.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3234) Remove contrib/dataimporthandler's webapp jsp


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

Stefan Matheis (steffkes) commented on SOLR-3234:
-

Yes, at last should be - [the last reported 
issue|https://issues.apache.org/jira/browse/SOLR-2667?focusedCommentId=13184471page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13184471]
 was fixed within SOLR-3162. If we need additional Functionality, tell me :) 

 Remove contrib/dataimporthandler's webapp jsp
 -

 Key: SOLR-3234
 URL: https://issues.apache.org/jira/browse/SOLR-3234
 Project: Solr
  Issue Type: Task
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Attachments: SOLR-3234.patch


 the contrib/dataimporthandler contains .jsp files which are copied to the 
 main .war file using the 
 [add-to-war|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/contrib/contrib-build.xml?view=markup#L34]
  target of solr/contrib/contrib-build.xml
 I guess the build-target is still okay, since it may be needed that 
 additional files are deployed to the admin-area.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (SOLR-3026) eDismax: Locking down which fields can be explicitly queried (user fields aka uf)

2012-03-12 Thread Resolved


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

Jan Høydahl resolved SOLR-3026.
---

Resolution: Fixed

Committed in branch_3x

 eDismax: Locking down which fields can be explicitly queried (user fields aka 
 uf)
 -

 Key: SOLR-3026
 URL: https://issues.apache.org/jira/browse/SOLR-3026
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-3026-3x.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch


 We need a way to specify exactly what fields should be available to the end 
 user as fielded search.
 In the original SOLR-1553, there's a patch implementing user fields, but it 
 was never committed even if that issue was closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler


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

Erik Hatcher commented on SOLR-3232:


Stefan - /browse and search *are* SearchHandler's.  Even with SOLR-3161, these 
are legitimate request handlers to issue search requests to.

In your page you have this:
{code}
handlers[key]['class'] === 'org.apache.solr.handler.component.SearchHandler'
{code}

That simply isn't sufficient for determining a SearchHandler though and 
this points out more about why doing this sort of stuff client-side is brittle. 
  You really need a Java-side instanceof check to be sure if a request 
handler is *subclassed* from SearchHandler, not just directly but perhaps 
indirectly (like StandardRequestHandler).

Again, I'll just toss this out there because I feel strongly about 
HTML-inside-JavaScript-strings and everything coming from Ajax calls this way - 
the VelocityResponseWriter allows for very simple server-side templating and 
internal access to these sorts of things.  It'd be easy to generate a drop-down 
box (or JavaScript string array, whatever you'd like) using Solr's internal 
state and instanceof kinda checks.  An example from your patch on this is:

Also, in light of SOLR-3161, it's risky to add checks for acceptable request 
handlers anywhere in a secondary manner as the logic may not match.  It's 
important to ensure that what's presented matches what is truly available, and 
this be done using common server-side logic.

 Admin UI: query form should have a menu to pick a request handler
 -

 Key: SOLR-3232
 URL: https://issues.apache.org/jira/browse/SOLR-3232
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3232.patch


 The query form in the admin UI could use an improvement regarding how the 
 request handler is chosen; presently all there is is a text input for 'qt'.  
 The first choice to make in the form above the query should really be the 
 request handler since it actually handles the request before any other 
 parameters do anything.  It'd be great if it was a dynamically driven menu 
 defaulting to /select.  Similar to how the DIH page finds DIH request 
 handlers, this page could find the request handlers with a class of 
 SearchHandler.  Their names would be added to a list, and if the name 
 didn't start with a '/' then it would be prefixed with '/select?qt='.
 I did something similar (without the menu) to the old 3x UI in a patch to 
 SOLR-3161 which will hopefully get committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3758) Allow the ComplexPhraseQueryParser to search order or un-order proximity queries.


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

Tomás Fernández Löbbe commented on LUCENE-3758:
---

I think that makes sense. The query is different so it should have a different 
syntax.

 Allow the ComplexPhraseQueryParser to search order or un-order proximity 
 queries.
 -

 Key: LUCENE-3758
 URL: https://issues.apache.org/jira/browse/LUCENE-3758
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/queryparser
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Fix For: 4.0

 Attachments: LUCENE-3758.patch


 The ComplexPhraseQueryParser use SpanNearQuery, but always set the inOrder 
 value hardcoded to true. This could be configurable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Exposing Solr routing to SolrJ client

2012-03-12 Thread Per Steffensen

Mark Miller skrev:

Hey Per,

A couple things:

1. Distributed realtime get is coming - I know Yonik was looking at this
recently but got caught up in some other things.

Fantistic! I believe, if the client becomes routing aware, it is only
necessary when you are sending more than one id (using ids) in your
realtime-get request, and even then the distribution (to several Solr
servers and merging of results from those) could happen in the client
(or not, if you dont think that is appropriate).

2. There is a Solrj client that is aware of the cluster state - its called
CloudSolrServer. You give it the zookeeper address rather than a node's
address. Currently it doesn't send directly to the leader, but this is planned
Nice! So you plan to solve the two hop problem (as ElasticSearch calls
it) that I was mentioning!
http://www.elasticsearch.org/guide/reference/java-api/client.html

- it's a little tricky due to lack of access to the Schema for hashing, but
likely coming soon - there is a JIRA issue for it. Clients in other languages
should be able to do the same thing.

But can I do realtime-get from a SolrJ client already, then? You say
that CloudSolrServer does not go directly to leader yet, and if I am
correct when I claim that realtime-get (/get) requests are not routed on
serverside to leader, then I will still not be able to do realtime-get
using CloudSolrServer. Am I correct that I cant do it yet, even using
CloudSolrServer?

BTW, congratulations and thanks, for the terrific work you guys are
doing on Solr(Cloud)! Hope to get to contribute versioning (for
optimistic locking) and a unique key feature that allows the operation
to fail if the document already exists (instead of just automatically
deleting what is already there).

- Mark

On Mar 12, 2012, at 5:26 AM, Per Steffensen wrote:

I believe Solr(Cloud) is doing some internal routing of update-requests to make
sure documents are stored in the correct core/shard decided by Solrs internal
routing algoritm (I believe it basically finds out who is the leader-shard for
a given document, using shared information in ZK, info about the collection and
hash(document.id)). All nice and cool.

I also believe realtime-gets are not forwarded internally in Solr through this routing
algorithm, and that it therefore is impossible to do realtime-gets from a
client, because you dont know which core/shard to contact directly, again because you
dont know the routing alogrithm. If Im wrong, it would be very helpfull with a few
directions on how to do realtime-gets from a client to a Solr servers system containing
many shards and collection. If Im right, I think it would be very nice if the the routing
algorithm was somehow exposed to the client (in code reachable from SolrJ) so that you
can get to do realtime-gets from a SolrJ-based client - if it should be done
automatically for you of if the client using SolrJ explicitly needs to call some code to
get info about the core to contact, is not so important for now.

Such a solution would also make it possible to get rid of another performance related
problem, that most update-requests has to be transported among JVMs twice to reach
their destination. First from client to some random Solr server, and then from this
Solr server to the Solr server holding the core involved in the update. If routing information was
available for the client it could make sure to route its updates directly to the core (the one
currently playing the role as leader-shard for the shard to which the routing algorithm maps the
document) involved in the update.

ElasticSearch has a solution to this problem by the usage of Node Client (instead of
just Transport Client), where a node client is basically a real node in the system that
just doesnt store document, but which have all the logic and shared information like e.g. routing
algorithm available - http://www.elasticsearch.org/guide/reference/java-api/client.html. It
certainly doesnt have to be like that with Solr clients, but it would be nice if somehow routing
logic where available to the SolrJ so that it can send its updates (and realtime-gets) directly to
the correct destination.

Hope to get some comments on this issue.

Regards, Per Steffensen

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

- Mark Miller
lucidimagination.com

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

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-03-12 Thread Erik Hatcher (Issue Comment Edited) (JIRA)

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

Erik Hatcher commented on SOLR-3161:

bq. It's not clear... do these proposals eliminate the possibility of using
qt=/myhandler? I'm not sure we should be removing functionality that many have
found useful.

My DispatchingRequestHandler currently (but only as a first draft) handles
/-prefixed handlers to dispatch to them. But *only* if they are instanceof
SearchHandler. Without DispatchingRequestHandler, and handleSelect=false, no
qt dispatching is possible.

bq. edit: a quick look at the patch suggests that (after enabling qt) that
leading-slash named handlers will still be accessible via qt - but I couldn't
discern the final intention from the various comments in this issue.

Again, yes, currently, but only if it is a SearchHandler. There's a TODO in
there to consider eliminate dispatching to /-prefixed handlers. I'm +1 on
that. But it could be made even more flexible such that a list of allowed
handlers is provided, or a regex pattern, or ... whatever. I just like that
the crazy dispatching logic is moved out of SolrDispatchFilter and simplified,
making it entirely up to the designer of the configuration to determine whether
to wire in the DispatchingRequestHandler as /select or not. I'd generally
prefer not, leaving everything as /-prefixed handlers that can only be
dispatched to directly with no qt magic capability whatsoever.

Use of 'qt' should be restricted to searching and should not start with a '/'
-

Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0

Attachments: SOLR-3161-disable-qt-by-default.patch,
SOLR-3161-dispatching-request-handler.patch,
SOLR-3161-dispatching-request-handler.patch

I haven't yet looked at the code involved for suggestions here; I'm speaking
based on how I think things should work and not work, based on intuitiveness
and security. In general I feel it is best practice to use '/' leading
request handler names and not use qt, but I don't hate it enough when used
in limited (search-only) circumstances to propose its demise. But if someone
proposes its deprecation that then I am +1 for that.
Here is my proposal:
Solr should error if the parameter qt is supplied with a leading '/'.
(trunk only)
Solr should only honor qt if the target request handler extends
solr.SearchHandler.
The new admin UI should only use 'qt' when it has to. For the query screen,
it could present a little pop-up menu of handlers to choose from, including
/select?qt=mycustom for handlers that aren't named with a leading '/'. This
choice should be positioned at the top.
And before I forget, me or someone should investigate if there are any
similar security problems with the shards.qt parameter. Perhaps shards.qt can
abide by the same rules outlined above.
Does anyone foresee any problems with this proposal?
On a related subject, I think the notion of a default request handler is bad
- the default=true thing. Honestly I'm not sure what it does, since I
noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'.
Assuming it doesn't do anything useful anymore, I think it would be clearer
to use requestHandler name=/select class=solr.SearchHandler instead of
what's there now. The delta is to put the leading '/' on this request handler
name, and remove the default attribute.

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

[jira] [Issue Comment Edited] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

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

Erik Hatcher edited comment on SOLR-3161 at 3/12/12 2:02 PM:
-

bq. It's not clear... do these proposals eliminate the possibility of using
qt=/myhandler? I'm not sure we should be removing functionality that many have
found useful.

Again, yes, currently, but only if it is a SearchHandler. There's a TODO in
there to consider eliminating dispatching to /-prefixed handlers. I'm +1 on
that. But it could be made even more flexible such that a list of allowed
handlers is provided, or a regex pattern, or ... whatever. I just like that
the crazy dispatching logic is moved out of SolrDispatchFilter and simplified,
making it entirely up to the designer of the configuration to determine whether
to wire in the DispatchingRequestHandler as /select or not. I'd generally
prefer not, leaving everything as /-prefixed handlers that can only be
dispatched to directly with no qt magic capability whatsoever.

was (Author: ehatcher):
bq. It's not clear... do these proposals eliminate the possibility of using
qt=/myhandler? I'm not sure we should be removing functionality that many have
found useful.

Use of 'qt' should be restricted to searching and should not start with a '/'
-

Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0

Attachments: SOLR-3161-disable-qt-by-default.patch,
SOLR-3161-dispatching-request-handler.patch,
SOLR-3161-dispatching-request-handler.patch

[jira] [Commented] (SOLR-3026) eDismax: Locking down which fields can be explicitly queried (user fields aka uf)


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

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

Created documentation page for eDisMax: 
http://wiki.apache.org/solr/ExtendedDisMax

 eDismax: Locking down which fields can be explicitly queried (user fields aka 
 uf)
 -

 Key: SOLR-3026
 URL: https://issues.apache.org/jira/browse/SOLR-3026
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 3.1, 3.2, 3.3, 3.4, 3.5
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 3.6, 4.0

 Attachments: SOLR-3026-3x.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, SOLR-3026.patch, 
 SOLR-3026.patch, SOLR-3026.patch


 We need a way to specify exactly what fields should be available to the end 
 user as fielded search.
 In the original SOLR-1553, there's a patch implementing user fields, but it 
 was never committed even if that issue was closed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable

2012-03-12 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-3221:
--

OK, this passes all the tests on my mac. I'll have a chance to look over the 
code today. I'll commit this today or tomorrow unless somebody finds something.

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable

2012-03-12 Thread Erick Erickson (Commented) (JIRA)


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

Erick Erickson commented on SOLR-3221:
--

OK, this passes all the tests on my mac. I'll have a chance to look over the 
code today. I'll commit this today or tomorrow unless somebody finds something.

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Exposing Solr routing to SolrJ client


On Mar 12, 2012, at 9:39 AM, Per Steffensen wrote:

 Mark Miller skrev:
 Hey Per,
 
 A couple things:
 
 1. Distributed realtime get is coming - I know Yonik was looking at this 
 recently but got caught up in some other things.
   
 
 Fantistic! I believe, if the client becomes routing aware, it is only 
 necessary when you are sending more than one id (using ids) in your 
 realtime-get request, and even then the distribution (to several Solr servers 
 and merging of results from those) could happen in the client (or not, if you 
 dont think that is appropriate).
 2. There is a Solrj client that is aware of the cluster state - its called 
 CloudSolrServer. You give it the zookeeper address rather than a node's 
 address. Currently it doesn't send directly to the leader, but this is 
 planned
 Nice! So you plan to solve the two hop problem (as ElasticSearch calls it) 
 that I was mentioning! 
 http://www.elasticsearch.org/guide/reference/java-api/client.html
  - it's a little tricky due to lack of access to the Schema for hashing, but 
 likely coming soon - there is a JIRA issue for it. Clients in other 
 languages should be able to do the same thing.
   
 
 But can I do realtime-get from a SolrJ client already, then? You say that 
 CloudSolrServer does not go directly to leader yet, and if I am correct when 
 I claim that realtime-get (/get) requests are not routed on serverside to 
 leader, then I will still not be able to do realtime-get using 
 CloudSolrServer. Am I correct that I cant do it yet, even using 
 CloudSolrServer?

Right, you can't yet even with CloudSolrServer - but I think it will be done 
soon - certainly before the 4 release anyway.

 
 BTW, congratulations and thanks, for the terrific work you guys are doing on 
 Solr(Cloud)! Hope to get to contribute versioning (for optimistic locking) 
 and a unique key feature that allows the operation to fail if the document 
 already exists (instead of just automatically deleting what is already there).
 - Mark
 
 On Mar 12, 2012, at 5:26 AM, Per Steffensen wrote:
 
   
 
 Hi
 
 I believe Solr(Cloud) is doing some internal routing of update-requests to 
 make sure documents are stored in the correct core/shard decided by Solrs 
 internal routing algoritm (I believe it basically finds out who is the 
 leader-shard for a given document, using shared information in ZK, info 
 about the collection and hash(document.id)). All nice and cool.
 
 I also believe realtime-gets are not forwarded internally in Solr through 
 this routing algorithm, and that it therefore is impossible to do 
 realtime-gets from a client, because you dont know which core/shard to 
 contact directly, again because you dont know the routing alogrithm. If Im 
 wrong, it would be very helpfull with a few directions on how to do 
 realtime-gets from a client to a Solr servers system containing many shards 
 and collection. If Im right, I think it would be very nice if the the 
 routing algorithm was somehow exposed to the client (in code reachable from 
 SolrJ) so that you can get to do realtime-gets from a SolrJ-based client - 
 if it should be done automatically for you of if the client using SolrJ 
 explicitly needs to call some code to get info about the core to contact, 
 is not so important for now.
 
 Such a solution would also make it possible to get rid of another 
 performance related problem, that most update-requests has to be 
 transported among JVMs twice to reach their destination. First from client 
 to some random Solr server, and then from this Solr server to the Solr 
 server holding the core involved in the update. If routing information was 
 available for the client it could make sure to route its updates directly 
 to the core (the one currently playing the role as leader-shard for the 
 shard to which the routing algorithm maps the document) involved in the 
 update.
 
 ElasticSearch has a solution to this problem by the usage of Node Client 
 (instead of just Transport Client), where a node client is basically a 
 real node in the system that just doesnt store document, but which have all 
 the logic and shared information like e.g. routing algorithm available - 
 http://www.elasticsearch.org/guide/reference/java-api/client.html
 . It certainly doesnt have to be like that with Solr clients, but it would 
 be nice if somehow routing logic where available to the SolrJ so that it 
 can send its updates (and realtime-gets) directly to the correct 
 destination.
 
 Hope to get some comments on this issue.
 
 Regards, Per Steffensen
 
 -
 To unsubscribe, e-mail: 
 dev-unsubscr...@lucene.apache.org
 
 For additional commands, e-mail: 
 dev-h...@lucene.apache.org
 
 
 
 
 
 - Mark Miller
 lucidimagination.com
 
 
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: 
 dev-unsubscr...@lucene.apache.org
 
 For additional commands,

[jira] [Commented] (SOLR-788) MoreLikeThis should support distributed search

2012-03-12 Thread Jamie Johnson (Commented) (JIRA)


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

Jamie Johnson commented on SOLR-788:


After spending a bit looking at this, it appears that something has changed 
since last this patch was written which is preventing this from working 
properly.  I didn't write the original patch so I'm having difficulty figuring 
out specifically what is wrong.  Currently I am getting the following when 
running this

{code:xml} 
lst name=moreLikeThis
null name=8001ed40-5b54-4ca6-9a17-ffb16179a1de/
null name=652bfc99-96dd-49a3-8232-057995788b93/
null name=f422dfbd-d534-490b-b86c-6d0e6586dc7c/
null name=a0eb8e1b-299e-41cc-a52c-36c2d75f7171/
null name=05e01ad4-9d7a-4399-931b-257494ed9385/
null name=894fa0ac-4ac7-4121-a9c5-45c24ba5e6dd/
null name=b70b4ac4-ac09-42d7-8728-2aa6e236b757/
null name=be92fa6b-fbf1-4688-8f2f-edbd659ec50e/
null name=4fa6fb91-8433-4bde-866c-0102b3070f88/
null name=04109cda-f7e1-4280-903c-e1564585b3e8/
/lst
{code} 

If I run with distrib=false this works so definitely is something with the 
patch. 

 MoreLikeThis should support distributed search
 --

 Key: SOLR-788
 URL: https://issues.apache.org/jira/browse/SOLR-788
 Project: Solr
  Issue Type: Improvement
  Components: MoreLikeThis
Reporter: Grant Ingersoll
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: AlternateDistributedMLT.patch, MLT.patch, 
 MoreLikeThisComponentTest.patch, SolrMoreLikeThisPatch.txt


 The MoreLikeThis component should support distributed processing.
 See SOLR-303.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-2898) Support grouped faceting

2012-03-12 Thread Ariel Zerbib (Updated) (JIRA)


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

Ariel Zerbib updated SOLR-2898:
---

Comment: was deleted

(was: Actually, in case off multiple group.field parameters, the first 
group.field parameter is used.
Is the choice per facet (with facet.group.after=true) of which group.field to 
use enhancement (the first if not specified) doable?

We use group functionality and it works well. Some new required facets need to 
be calculated according to an other group field (with facet.group.after=true). 
Only facet results are relevant for secondary group fields and not result.)

 Support grouped faceting
 

 Key: SOLR-2898
 URL: https://issues.apache.org/jira/browse/SOLR-2898
 Project: Solr
  Issue Type: New Feature
Reporter: Martijn van Groningen
 Fix For: 4.0

 Attachments: SOLR-2898.patch, SOLR-2898.patch, SOLR-2898.patch, 
 SOLR-2898.patch


 Support grouped faceting. As described in LUCENE-3097 (matrix counts).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-1052) Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml


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

David Smiley commented on SOLR-1052:


Thanks for tackling this Jan; this needed to happen a long time ago!
If you said that your patch will abort if mainIndex  indexConfig are present, 
then you will be forced to upgrade the test configs; no?  Any way, if your 
opinion is that it's easier to split the work into a separate issue then I 
think that's fine.

 Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
 --

 Key: SOLR-1052
 URL: https://issues.apache.org/jira/browse/SOLR-1052
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Jan Høydahl
Priority: Minor
  Labels: solrconfig.xml
 Fix For: 3.6, 4.0

 Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch, 
 SOLR-1052-3x.patch


 Given that we now handle multiple cores via the solr.xml and the discussion 
 around indexDefaults and mainIndex at 
 http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults
 We should deprecate/remove the use of indexDefaults and just rely on 
 mainIndex, as it doesn't seem to serve any purpose and is confusing to 
 explain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler


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

David Smiley commented on SOLR-3232:


Erik, I admit that your /handlers Velocity template presented in SOLR-3161 was 
remarkably succinct and readable but it does force the use of Velocity which 
isn't in core, just as JSPs aren't for similar reasons.  How about 
SolrInfoMBeanHandler.java adds a simple searchHandler attribute with 
true/false?

 Admin UI: query form should have a menu to pick a request handler
 -

 Key: SOLR-3232
 URL: https://issues.apache.org/jira/browse/SOLR-3232
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3232.patch


 The query form in the admin UI could use an improvement regarding how the 
 request handler is chosen; presently all there is is a text input for 'qt'.  
 The first choice to make in the form above the query should really be the 
 request handler since it actually handles the request before any other 
 parameters do anything.  It'd be great if it was a dynamically driven menu 
 defaulting to /select.  Similar to how the DIH page finds DIH request 
 handlers, this page could find the request handlers with a class of 
 SearchHandler.  Their names would be added to a list, and if the name 
 didn't start with a '/' then it would be prefixed with '/select?qt='.
 I did something similar (without the menu) to the old 3x UI in a patch to 
 SOLR-3161 which will hopefully get committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12716 - Failure

2012-03-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12716/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.TestPluginEnable

Error Message:
Uncaught exception by thread: Thread[TimeLimitedCollector timer thread,5,]

Stack Trace:
org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread:
 Uncaught exception by thread: Thread[TimeLimitedCollector timer thread,5,]
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:60)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
Caused by: org.apache.lucene.util.ThreadInterruptedException: 
java.lang.InterruptedException: sleep interrupted
at 
org.apache.lucene.search.TimeLimitingCollector$TimerThread.run(TimeLimitingCollector.java:268)
Caused by: java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at 
org.apache.lucene.search.TimeLimitingCollector$TimerThread.run(TimeLimitingCollector.java:266)




Build Log (for compile errors):
[...truncated 7647 lines...]



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

[jira] [Commented] (SOLR-1052) Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml


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

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

In 3.6 (which the patch is for) it will only print a warning, so old configs 
will work.

Have not yet started 4.x patch, still need to decide what should happen with 
old configs in 4.x. Perhaps warn if supplied config  LUCENE_40 but if config 
version is = LUCENE_40 we fail?

 Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
 --

 Key: SOLR-1052
 URL: https://issues.apache.org/jira/browse/SOLR-1052
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Jan Høydahl
Priority: Minor
  Labels: solrconfig.xml
 Fix For: 3.6, 4.0

 Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch, 
 SOLR-1052-3x.patch


 Given that we now handle multiple cores via the solr.xml and the discussion 
 around indexDefaults and mainIndex at 
 http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults
 We should deprecate/remove the use of indexDefaults and just rely on 
 mainIndex, as it doesn't seem to serve any purpose and is confusing to 
 explain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases

2012-03-12 Thread Luca Cavanna (Commented) (JIRA)


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

Luca Cavanna commented on SOLR-2719:


Since this issue is blocker for 4.0, it would great to close it soon. Let me 
know if there's something more I can do to help!

 REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing 
 fl=my-field-name type usecases
 -

 Key: SOLR-2719
 URL: https://issues.apache.org/jira/browse/SOLR-2719
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 4.0
Reporter: Nik V. Babichev
Priority: Blocker
  Labels: field, fl, query, queryparser
 Fix For: 4.0

 Attachments: SOLR-2719.patch, SOLR-2719.patch


 fl=my-hyphen-field in query params parsed as my instead of 
 my-hyphen-field.
 OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing
 in which check chars if (!Character.isJavaIdentifierPart(ch)  ch != '.')
 Hyphen is not JavaIdentifierPart and this check break when first - is found.
 This problem solve by passing '-' to check:
 if (!Character.isJavaIdentifierPart(ch)  ch != '.'  ch != '-') break;
 But I don't know how it can affect on whole project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-03-12 Thread Yonik Seeley (Commented) (JIRA)

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

Yonik Seeley commented on SOLR-3161:

I don't think we should remove the ability to use qt with /-prefixed handlers,
esp since the current patch here would disable qt by default.

Use of 'qt' should be restricted to searching and should not start with a '/'
-

Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0

Attachments: SOLR-3161-disable-qt-by-default.patch,
SOLR-3161-dispatching-request-handler.patch,
SOLR-3161-dispatching-request-handler.patch

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

[jira] [Created] (LUCENE-3865) MemoryIndex does not allow user to add multiple values for a single field name

2012-03-12 Thread Dave Seltzer (Created) (JIRA)

MemoryIndex does not allow user to add multiple values for a single field name
--

 Key: LUCENE-3865
 URL: https://issues.apache.org/jira/browse/LUCENE-3865
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: All
Reporter: Dave Seltzer
Priority: Minor


When using MemoryIndex.addField the following operation throws an 
IllegalArgumentException:

index.addField(foobar, value1, LuceneAnalyzer); 
index.addField(foobar, value2, LuceneAnalyzer); 

This throws:
java.lang.IllegalArgumentException: field must not be added more than once

According to Uwe Schindler on the java-user mailing list this violates the 
IndexWriter/IndexReader contract.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-03-12 Thread Stefan Matheis (steffkes) (Assigned) (JIRA)

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

David Smiley commented on SOLR-3161:

BTW I forgot to add a CHANGES.txt in my patch pending commit; it will be as
follows:
{quote}
Upgrading from Solr 3.5
--
SOLR-3161: requestDispatcher handleSelect=false is now the default. An
existing config will probably work as-is because handleSelect was explicitly
enabled in default configs. HandleSelect makes /select work as well as enables
the 'qt' parameter. Instead, consider explicitly configuring /select as is
done in the example solrconfig.xml, and register your other search handlers
with a leading '/' which is a recommended practice.
{quote}

Erik, I very much agree with your sentiment that the dispatching logic get
moved out of SolrDispatchFilter and get simplified and made configurable and
clear in the solrconfig.xml. IMO, the current situation should stay in place in
3x (notwithstanding additions of safety checks to prevent qt=/update).
4x/trunk could then get your DispatchingRequestHandler (credit to Hoss for the
idea) and _removal_ of SolrRequestDispatcher's handleSelect.

By the way, I _suspect_ that assuming /select works is so ingrained into
various parts of Solr, that we may want to log a warning if there isn't one
registered at this path. Maybe I'm wrong but we'll see as we proceed.

Use of 'qt' should be restricted to searching and should not start with a '/'
-

Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0

Attachments: SOLR-3161-disable-qt-by-default.patch,
SOLR-3161-dispatching-request-handler.patch,
SOLR-3161-dispatching-request-handler.patch

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

[jira] [Assigned] (SOLR-3098) analysis gui hangs if no tokens are output


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

Stefan Matheis (steffkes) reassigned SOLR-3098:
---

Assignee: Stefan Matheis (steffkes)

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev

 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-2719) REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing fl=my-field-name type usecases

2012-03-12 Thread Yonik Seeley (Assigned) (JIRA)


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

Yonik Seeley reassigned SOLR-2719:
--

Assignee: Yonik Seeley

 REGRESSION ReturnFields incorrect parse fields with hyphen - breaks existing 
 fl=my-field-name type usecases
 -

 Key: SOLR-2719
 URL: https://issues.apache.org/jira/browse/SOLR-2719
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 4.0
Reporter: Nik V. Babichev
Assignee: Yonik Seeley
Priority: Blocker
  Labels: field, fl, query, queryparser
 Fix For: 4.0

 Attachments: SOLR-2719.patch, SOLR-2719.patch


 fl=my-hyphen-field in query params parsed as my instead of 
 my-hyphen-field.
 OAS.search.ReturnFields use method getId() from OAS.search.QueryParsing
 in which check chars if (!Character.isJavaIdentifierPart(ch)  ch != '.')
 Hyphen is not JavaIdentifierPart and this check break when first - is found.
 This problem solve by passing '-' to check:
 if (!Character.isJavaIdentifierPart(ch)  ch != '.'  ch != '-') break;
 But I don't know how it can affect on whole project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3865) MemoryIndex does not allow user to add multiple values for a single field name

2012-03-12 Thread Uwe Schindler (Commented) (JIRA)


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

Uwe Schindler commented on LUCENE-3865:
---

Thanks for opening this, I will have a look into this. If I am able to fix this 
easily, I will assign myself!

 MemoryIndex does not allow user to add multiple values for a single field name
 --

 Key: LUCENE-3865
 URL: https://issues.apache.org/jira/browse/LUCENE-3865
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.5
 Environment: All
Reporter: Dave Seltzer
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 When using MemoryIndex.addField the following operation throws an 
 IllegalArgumentException:
 index.addField(foobar, value1, LuceneAnalyzer); 
 index.addField(foobar, value2, LuceneAnalyzer); 
 This throws:
 java.lang.IllegalArgumentException: field must not be added more than once
 According to Uwe Schindler on the java-user mailing list this violates the 
 IndexWriter/IndexReader contract.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-3865) MemoryIndex does not allow user to add multiple values for a single field name

2012-03-12 Thread Uwe Schindler (Updated) (JIRA)


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

Uwe Schindler updated LUCENE-3865:
--

Component/s: (was: core/index)
 modules/other

 MemoryIndex does not allow user to add multiple values for a single field name
 --

 Key: LUCENE-3865
 URL: https://issues.apache.org/jira/browse/LUCENE-3865
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/other
Affects Versions: 3.5
 Environment: All
Reporter: Dave Seltzer
Priority: Minor
   Original Estimate: 1h
  Remaining Estimate: 1h

 When using MemoryIndex.addField the following operation throws an 
 IllegalArgumentException:
 index.addField(foobar, value1, LuceneAnalyzer); 
 index.addField(foobar, value2, LuceneAnalyzer); 
 This throws:
 java.lang.IllegalArgumentException: field must not be added more than once
 According to Uwe Schindler on the java-user mailing list this violates the 
 IndexWriter/IndexReader contract.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'

2012-03-12 Thread Stefan Matheis (steffkes) (Updated) (JIRA)

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

David Smiley commented on SOLR-3161:

bq. Yonik: I don't think we should remove the ability to use qt with /-prefixed
handlers, esp since the current patch here would disable qt by default.

Ok. In my view, the worst part of qt=/update is that it's not actually a
search. I'd love adding the SearchHandler instanceof restriction. However
Hoss says he doesn't like it:

bq. 2) assuming qt should be allowed only if it is an instance of
solr.SearchHandler seems narrow minded to me – it puts a totally arbitrary
limitation on the ability for people to have their own request handlers that
are treated as first class citizens and seems just as likely to lead to
suprise and frustration as it is to appreciation for the safety of the
feature (not to mention it procludes perfectly safe query type handlers like
MLTHnadler and AnalysisRequestHandler

Hoss, my answer to you is to not use 'qt' for these cases; register the
handlers with a leading '/', and for that matter, Erik and I _suggest_ that
'qt' not get used at all although we acknowledge it's still there for those
that love it.

Perhaps the restriction to appease most people's wishes should be to error IFF
qt starts with a '/' AND it doesn't extend SearchHandler.

~ David

Use of 'qt' should be restricted to searching and should not start with a '/'
-

Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0

Attachments: SOLR-3161-disable-qt-by-default.patch,
SOLR-3161-dispatching-request-handler.patch,
SOLR-3161-dispatching-request-handler.patch

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

[jira] [Updated] (SOLR-3098) analysis gui hangs if no tokens are output


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

Stefan Matheis (steffkes) updated SOLR-3098:


Component/s: web gui

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev

 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-2490) PropertiesRequestHandler; encode line.separator

2012-03-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


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

Stefan Matheis (steffkes) commented on SOLR-2490:
-

Just FYI -- I've created an hacky workaround for the admin-ui - using an regex 
to extract the {{line.seperator}}-value from the raw response (which still 
contains the {{\n}}): 
https://github.com/steffkes/solr-admin/commit/c68427da9791b1f758c4185853ca8735dc47ec84#diff-0



 PropertiesRequestHandler; encode line.separator
 ---

 Key: SOLR-2490
 URL: https://issues.apache.org/jira/browse/SOLR-2490
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 Currently, the XML looks like this:
 {code}!-- .. --
 str name=java.io.tmpdir/tmp/str
 str name=line.separator
 /str
 str name=java.vm.specification.vendorSun Microsystems Inc./str
 !-- .. --{code}
 would be good to have this instead:
 {code}!-- .. --
 str name=java.io.tmpdir/tmp/str
 str name=line.separator\n/str
 str name=java.vm.specification.vendorSun Microsystems Inc./str
 !-- .. --{code}
 afterwords we will be able to display to used line seperator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3188) New admin page: Enable Polling button disappears after disabling polling and reloading page

2012-03-12 Thread Stefan Matheis (steffkes) (Assigned) (JIRA)


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

Stefan Matheis (steffkes) reassigned SOLR-3188:
---

Assignee: Stefan Matheis (steffkes)

 New admin page: Enable Polling button disappears after disabling polling 
 and reloading page
 -

 Key: SOLR-3188
 URL: https://issues.apache.org/jira/browse/SOLR-3188
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Neil Hooey
Assignee: Stefan Matheis (steffkes)
Priority: Minor
  Labels: admin

 When you go to this URL on a slave:
 http://localhost:8983/solr/#/singlecore/replication
 And click the Disable Polling button, you see a red bar that says 
 invalid_master. I'm not sure why I get this red bar, as I haven't tested it 
 outside of my own installation, but it seems normal.
 If you then refresh the page, the Replicate Now and Enable Polling 
 buttons disappear. It seems like their generation is being interrupted by the 
 invalid_master error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3205) Better error reporting from Analysis UI

2012-03-12 Thread Stefan Matheis (steffkes) (Assigned) (JIRA)


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

Stefan Matheis (steffkes) reassigned SOLR-3205:
---

Assignee: Stefan Matheis (steffkes)

 Better error reporting from Analysis UI
 ---

 Key: SOLR-3205
 URL: https://issues.apache.org/jira/browse/SOLR-3205
 Project: Solr
  Issue Type: Bug
  Components: web gui
Reporter: Ryan McKinley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0


 The new analysis UI does not behave well with invalid input.  To reproduce, 
 from /#/singlecore/analysis
  * Select a number field (int) 
  * put in invalid text (hello)
  * click Analyse Values
 The UI will have a red banner, but not say anything useful.  The log file 
 will say:
 {code}
 SEVERE: org.apache.solr.common.SolrException: Invalid Number: hello
   at 
 org.apache.solr.analysis.TrieTokenizer.reset(TrieTokenizerFactory.java:113)
   at 
 org.apache.solr.analysis.TrieTokenizer.init(TrieTokenizerFactory.java:76)
 {code}
 Hopefully we can get the UI to say Invalid Number: hello

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler

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

Erik Hatcher commented on SOLR-3232:

bq. Erik, I admit that your /handlers Velocity template presented in SOLR-3161
was remarkably succinct and readable but it does force the use of Velocity
which isn't in core, just as JSPs aren't for similar reasons.

I'll admit to beating a dead horse here I suppose. It's a bit frustrating that
something that is so easy and trivial using something already sort-of available
isn't really available. But the reasons aren't really that similar JSPs
require a JDK. VRW only requires another .jar. Anyway, I'll let it go, and
just roll my eyes at all the hacks and duplication that building an entirely
Ajax UI using pure JSON responses entails.

Admin UI: query form should have a menu to pick a request handler
-

Key: SOLR-3232
URL: https://issues.apache.org/jira/browse/SOLR-3232
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
Fix For: 4.0

Attachments: SOLR-3232.patch

The query form in the admin UI could use an improvement regarding how the
request handler is chosen; presently all there is is a text input for 'qt'.
The first choice to make in the form above the query should really be the
request handler since it actually handles the request before any other
parameters do anything. It'd be great if it was a dynamically driven menu
defaulting to /select. Similar to how the DIH page finds DIH request
handlers, this page could find the request handlers with a class of
SearchHandler. Their names would be added to a list, and if the name
didn't start with a '/' then it would be prefixed with '/select?qt='.
I did something similar (without the menu) to the old 3x UI in a patch to
SOLR-3161 which will hopefully get committed.

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

[jira] [Resolved] (LUCENENET-54) ArgumentOurOfRangeException caused by SF.Snowball.Ext.DanishStemmer

2012-03-12 Thread Christopher Currens (Resolved) (JIRA)


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

Christopher Currens resolved LUCENENET-54.
--

Resolution: Fixed

 ArgumentOurOfRangeException caused by SF.Snowball.Ext.DanishStemmer
 ---

 Key: LUCENENET-54
 URL: https://issues.apache.org/jira/browse/LUCENENET-54
 Project: Lucene.Net
  Issue Type: Bug
Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
 Environment: Windows XP SP2, lucene.net v2.0 004
Reporter: Torsten Rendelmann
Priority: Critical
 Fix For: Lucene.Net 3.0.3


 Exception Information
 System.SystemException: System.Reflection.TargetInvocationException: 
 Exception has been thrown by the target of an invocation. --- 
 System.ArgumentOutOfRangeException: Index and length must refer to a location 
 within the string.
 Parameter name: length
at System.String.Substring(Int32 startIndex, Int32 length)
at System.Text.StringBuilder.ToString(Int32 startIndex, Int32 length)
at SF.Snowball.SnowballProgram.slice_to(StringBuilder s)
at SF.Snowball.Ext.DanishStemmer.r_undouble()
at SF.Snowball.Ext.DanishStemmer.Stem()
--- End of inner exception stack trace ---
at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, 
 BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo 
 culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess)
at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, 
 BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo 
 culture, Boolean verifyAccess)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags 
 invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at System.Reflection.MethodInfo.Invoke(Object obj, Object[] parameters)
at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
at Lucene.Net.Index.DocumentWriter.InvertDocument(Document doc)
at Lucene.Net.Index.DocumentWriter.AddDocument(String segment, Document 
 doc)
at Lucene.Net.Index.IndexWriter.AddDocument(Document doc, Analyzer 
 analyzer)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LUCENENET-475) DanishStemmer doesn't work.

2012-03-12 Thread Christopher Currens (Resolved) (JIRA)


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

Christopher Currens resolved LUCENENET-475.
---

   Resolution: Fixed
Fix Version/s: Lucene.Net 3.0.3

This has already been fixed in trunk.  Contrib was largely forgotten about in 
past released, though this has changed during the development of 3.x.

 DanishStemmer doesn't work.
 ---

 Key: LUCENENET-475
 URL: https://issues.apache.org/jira/browse/LUCENENET-475
 Project: Lucene.Net
  Issue Type: Bug
  Components: Lucene.Net Contrib
Affects Versions: Lucene.Net 2.9.4g
Reporter: Johannes Hansen
  Labels: danish, snowball, stemmer
 Fix For: Lucene.Net 3.0.3


 The following code fails with a ArgumentOutOfRangeException in line 467 of 
 \src\contrib\Snowball\SF\Snowball\SnowballProgram.cs:
 var stemmer = new DanishStemmer();
 stemmer.SetCurrent(heste);
 stemmer.Stem();
 Console.WriteLine(stemmer.GetCurrent());
 Expected: Output hest to console.
 Possible fix: Seems like the line should have been
 s.Append(current.ToString(bra, len));
 instead of:
 s.Append(current.ToString(bra, ket));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler

2012-03-12 Thread Mark Miller (Commented) (JIRA)

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

Mark Miller commented on SOLR-3232:
---

bq. How about SolrInfoMBeanHandler.java adds a simple searchHandler attribute
with true/false?

+1 - something like that sounds reasonable. No reason you shouldn't be able to
determine this from SolrInfoMBeanHandler.

Admin UI: query form should have a menu to pick a request handler
-

Key: SOLR-3232
URL: https://issues.apache.org/jira/browse/SOLR-3232
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
Fix For: 4.0

Attachments: SOLR-3232.patch

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

[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output

2012-03-12 Thread Robert Muir (Commented) (JIRA)


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

Robert Muir commented on SOLR-3098:
---

Thanks for looking Stefan :)

I'm not sure also (would need to test) if the same bug also happens if the text 
ends with a stopword.
In other words, if we tried entering test the into text_en fieldtype... could 
be a more general form of the problem.


 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev

 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (SOLR-3236) StreamingUpdateSolrServer javadoc incomplete

2012-03-12 Thread Shawn Heisey (Created) (JIRA)

StreamingUpdateSolrServer javadoc incomplete


 Key: SOLR-3236
 URL: https://issues.apache.org/jira/browse/SOLR-3236
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 3.5, 4.0
Reporter: Shawn Heisey
Priority: Trivial
 Fix For: 3.6, 4.0


The javadoc for the StreamingUpdateSolrServer class is incomplete.  I'm 
relatively new to all this, the patches I will submit include my best guess at 
what it should say.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3236) StreamingUpdateSolrServer javadoc incomplete

2012-03-12 Thread Shawn Heisey (Updated) (JIRA)


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

Shawn Heisey updated SOLR-3236:
---

Attachment: SOLR-3236-3x.patch
SOLR-3236.patch

Patches for trunk and branch_3x.

 StreamingUpdateSolrServer javadoc incomplete
 

 Key: SOLR-3236
 URL: https://issues.apache.org/jira/browse/SOLR-3236
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 3.5, 4.0
Reporter: Shawn Heisey
Priority: Trivial
 Fix For: 3.6, 4.0

 Attachments: SOLR-3236-3x.patch, SOLR-3236.patch


 The javadoc for the StreamingUpdateSolrServer class is incomplete.  I'm 
 relatively new to all this, the patches I will submit include my best guess 
 at what it should say.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3229) TermVectorComponent does not return terms in distributed search

2012-03-12 Thread Stefan Matheis (steffkes) (Updated) (JIRA)


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

Hang Xie updated SOLR-3229:
---

Attachment: TermVectorComponent.patch

Revised patch, no longer fails unit test.

 TermVectorComponent does not return terms in distributed search
 ---

 Key: SOLR-3229
 URL: https://issues.apache.org/jira/browse/SOLR-3229
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0
 Environment: Ubuntu 11.10, openjdk-6
Reporter: Hang Xie
  Labels: patch
 Fix For: 4.0

 Attachments: TermVectorComponent.patch, TermVectorComponent.patch


 TermVectorComponent does not return terms in distributed search, the 
 distributedProcess() incorrectly uses Solr Unique Key to do subrequests, 
 while process() expects Lucene document ids. Also, parameters are transferred 
 in different format thus making distributed search returns no result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output

2012-03-12 Thread Uwe Schindler (Commented) (JIRA)


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

Uwe Schindler commented on SOLR-3098:
-

Is the infinite loop occuring in FieldAnalysisRequestHandler?

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev

 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output

2012-03-12 Thread Robert Muir (Commented) (JIRA)


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

Robert Muir commented on SOLR-3098:
---

It didn't seem like it to me. If I recall, the browser appears hung (a 
front-end thing only),
but cpu usage was still 0%.

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev

 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.

2012-03-12 Thread Nguyen Kien Trung (Commented) (JIRA)


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

Nguyen Kien Trung commented on SOLR-2690:
-

hi David, I'm one of 100s people having this issue. I applied your patch on 
3.3, and modified the {{SimpleFacetsTest}} to cover a simple timezone test 
scenario. However, the tests for {{DateField}} and {{TrieDateField}} fail. Is 
there an additional changes need to be made on SimpleFacets?

{code:lang=java|title=SimpleFacetsTest#indexDateFacets}
add_doc(i, 2012, f, 2007-07-30T07:07:07.070Z);
add_doc(i, 2015, f, 2007-07-30T23:07:07.070Z); // one more record
{code}

{code:lang=java|title=SimpleFacetsTest#helpTestDateFacets}
...
final String jul4 = rangeMode ? [.='1'  ] : [.='2'  ];

assertQ(check counts for day of facet by day using UTC timezone,
req( q, *:*
,rows, 0
,facet, true
,p, f
,p+.start, 2007-07-30T00:00:00.000Z
,p+.end,   2007-07-31T00:00:00.000Z
,p+.gap,   +1DAY
,tz, UTC
)
,*[count(+pre+/int)=+(rangeMode ? 1 : 1)+]
,pre+/int[@name='2007-07-30T00:00:00Z'][.='2']
);

assertQ(check counts for day of facet by day using Asia/Singapore (UTC+8) 
timezone,
req( q, *:*
,rows, 0
,facet, true
,p, f
,p+.start, 2007-07-30T00:00:00.000Z
,p+.end,   2007-07-31T00:00:00.000Z
,p+.gap,   +1DAY
,tz, Asia/Singapore
)
,*[count(+pre+/int)=+(rangeMode ? 1 : 1)+]
,pre+/int[@name='2007-07-30T00:00:00Z'][.='1']
);// fail here, still returns 2 instead of 1, already set 
tests.timezone parameter to UTC to make sure data indexed in UTC
...
{code}

 Date Faceting or Range Faceting doesn't take timezone into account.
 ---

 Key: SOLR-2690
 URL: https://issues.apache.org/jira/browse/SOLR-2690
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.3
Reporter: David Schlotfeldt
 Attachments: add-tz-parameter.patch, add-tz-parameter.patch, 
 timezone-facet-component.tgz

   Original Estimate: 3h
  Remaining Estimate: 3h

 Timezone needs to be taken into account when doing date math. Currently it 
 isn't. DateMathParser instances created are always being constructed with 
 UTC. This is a huge issue when it comes to faceting. Depending on your 
 timezone day-light-savings changes the length of a month. A facet gap of 
 +1MONTH is different depending on the timezone and the time of the year.
 I believe the issue is very simple to fix. There are three places in the code 
 DateMathParser is created. All three are configured with the timezone being 
 UTC. If a user could specify the TimeZone to pass into DateMathParser this 
 faceting issue would be resolved.
 Though it would be nice if we could always specify the timezone 
 DateMathParser uses (since date math DOES depend on timezone) its really only 
 essential that we can affect DateMathParser the SimpleFacets uses when 
 dealing with the gap of the date facets.
 Another solution is to expand the syntax of the expressions DateMathParser 
 understands. For example we could allow (?timeZone=VALUE) to be added 
 anywhere within an expression. VALUE would be the id of the timezone. When 
 DateMathParser reads this in sets the timezone on the Calendar it is using.
 Two examples:
 - (?timeZone=America/Chicago)NOW/YEAR
 - (?timeZone=America/Chicago)+1MONTH
 I would be more then happy to modify DateMathParser and provide a patch. I 
 just need a committer to agree this needs to be resolved and a decision needs 
 to be made on the syntax used
 Thanks!
 David

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3134) Include shard Information in response

2012-03-12 Thread Russell Black (Commented) (JIRA)


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

Russell Black commented on SOLR-3134:
-

Hi Ryan, 

Sorry to keep bothering you about this, but can you comment on your intentions 
with respect to committing the 3x patch?



 Include shard Information in response
 -

 Key: SOLR-3134
 URL: https://issues.apache.org/jira/browse/SOLR-3134
 Project: Solr
  Issue Type: Improvement
  Components: SearchComponents - other
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Fix For: 4.0

 Attachments: SOLR-3134-shard-info-3_5-backport.patch, 
 SOLR-3134-shard-info-3_x-backport.patch, SOLR-3134-shard-info-fix.patch, 
 SOLR-3134-shard-info.patch


 For distributed search where each shard represents a logically different 
 index (or physical location), it would be great to know the hit count for 
 each shard.
 In addition, it would be nice to get error info for each shard rather then 
 aborting the whole request when something fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-788) MoreLikeThis should support distributed search

2012-03-12 Thread Jamie Johnson (Updated) (JIRA)


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

Jamie Johnson updated SOLR-788:
---

Attachment: MLT.patch

I tracked down what was causing the issue on my part, the original patch 
assumed the unique key field was id and in my index it's key.  I've updated 
the patch to look that up now.  I also supplied multiple fields and that worked 
properly (as far as I can tell).  

 MoreLikeThis should support distributed search
 --

 Key: SOLR-788
 URL: https://issues.apache.org/jira/browse/SOLR-788
 Project: Solr
  Issue Type: Improvement
  Components: MoreLikeThis
Reporter: Grant Ingersoll
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, 
 MoreLikeThisComponentTest.patch, SolrMoreLikeThisPatch.txt


 The MoreLikeThis component should support distributed processing.
 See SOLR-303.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3098) analysis gui hangs if no tokens are output


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

Stefan Matheis (steffkes) updated SOLR-3098:


Attachment: SOLR-3098.patch

Sorry Robert for the late Response, just discovered this Issue.

Uwe: Just a Frontend/Javascript Issue, the StandardTokenizer is dropping out 
the 'the'. So further Tokenizer/Filters are empty and therefore have no 
positionHistory Property, which was expected to proceed correctly.

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev
 Attachments: SOLR-3098.patch


 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3232) Admin UI: query form should have a menu to pick a request handler

2012-03-12 Thread Stefan Matheis (steffkes) (Commented) (JIRA)


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

Stefan Matheis (steffkes) commented on SOLR-3232:
-

bq. How about SolrInfoMBeanHandler.java adds a simple searchHandler attribute 
with true/false?
+1 

Just to note it, some of the Handlers which are defined with {{startup=lazy}} 
are shown as {{Lazy[solr.SearchHandler]}} in the mbean-Output, don't know if 
this requires a specific Handling

 Admin UI: query form should have a menu to pick a request handler
 -

 Key: SOLR-3232
 URL: https://issues.apache.org/jira/browse/SOLR-3232
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: David Smiley
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3232.patch


 The query form in the admin UI could use an improvement regarding how the 
 request handler is chosen; presently all there is is a text input for 'qt'.  
 The first choice to make in the form above the query should really be the 
 request handler since it actually handles the request before any other 
 parameters do anything.  It'd be great if it was a dynamically driven menu 
 defaulting to /select.  Similar to how the DIH page finds DIH request 
 handlers, this page could find the request handlers with a class of 
 SearchHandler.  Their names would be added to a list, and if the name 
 didn't start with a '/' then it would be prefixed with '/select?qt='.
 I did something similar (without the menu) to the old 3x UI in a patch to 
 SOLR-3161 which will hopefully get committed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output

2012-03-12 Thread Ryan McKinley (Commented) (JIRA)


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

Ryan McKinley commented on SOLR-3098:
-

Stefan... feel free to commit this type of change without review.  For big 
things, it is good to have some review, but for minor fixes like this, just 
dive in!

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev
 Attachments: SOLR-3098.patch


 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-788) MoreLikeThis should support distributed search

2012-03-12 Thread Vadim Kisselmann (Commented) (JIRA)


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

Vadim Kisselmann commented on SOLR-788:
---

Hi Jamie,
Unfortunately, I can't reproduce this bug now, but i try it this week.

I use edismax as default query handler.
My queries looks like (default select with mlt-params):
http://localhost:8080/solr/shard_1/select?shards=localhost:8080/solr/shard_1,localhost:8080/solr/shard_2indent=trueq=solrmlt=truemlt.fl=text,titlemlt.qf=textmlt.mintf=1mlt.minwl=3mlt.boost=truerows=10mlt.mindf=1start=0

OR with mlt-handler:
http://localhost:8080/solr/shard_1/mlt?shards=localhost:8080/solr/shard_1,localhost:8080/solr/shard_2indent=trueq=solrmlt.fl=text,titlemlt.qf=textmlt.mintf=1mlt.minwl=3mlt.boost=truerows=10mlt.mindf=1start=0mlt.interestingTerms=details

With more than one field in mlt.fl I get HTTP 400 exceptions.


Thanks for the new patch, I will test it this week :) 






 MoreLikeThis should support distributed search
 --

 Key: SOLR-788
 URL: https://issues.apache.org/jira/browse/SOLR-788
 Project: Solr
  Issue Type: Improvement
  Components: MoreLikeThis
Reporter: Grant Ingersoll
Priority: Minor
 Fix For: 3.6, 4.0

 Attachments: AlternateDistributedMLT.patch, MLT.patch, MLT.patch, 
 MoreLikeThisComponentTest.patch, SolrMoreLikeThisPatch.txt


 The MoreLikeThis component should support distributed processing.
 See SOLR-303.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12719 - Failure

2012-03-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12719/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=91 closes=90

Stack Trace:
junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 
closes=90
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
at 
org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
at 
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
at 
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
at 
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
at 
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)




Build Log (for compile errors):
[...truncated 8841 lines...]



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

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12719 - Failure

I've only had a bit of time trying to repro this with my where was this 
searcher/core opened from debug code - I got busy with other things before 
hitting pa dirt though - but it's still got my attention!

On Mar 12, 2012, at 4:36 PM, Apache Jenkins Server wrote:

 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12719/
 
 1 tests failed.
 FAILED:  
 junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest
 
 Error Message:
 ERROR: SolrIndexSearcher opens=91 closes=90
 
 Stack Trace:
 junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 
 closes=90
   at 
 org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
   at 
 org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
   at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
   at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
   at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
   at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
 
 
 
 
 Build Log (for compile errors):
 [...truncated 8841 lines...]
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

- Mark Miller
lucidimagination.com












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

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12719 - Failure

2012-03-12 Thread Yonik Seeley

Took a quick look, and at the end I see

152287 T188 C0 P15739 oasc.RecoveryStrategy.doRecovery SEVERE Recovery
failed - trying again...
155191 T1 oas.SolrTestCaseJ4.endTrackingSearchers SEVERE ERROR:
SolrIndexSearcher opens=91 closes=90

So the recovery thread is still going, hence a core is still open (and
an associated searcher).

-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10



On Mon, Mar 12, 2012 at 4:39 PM, Mark Miller markrmil...@gmail.com wrote:
 I've only had a bit of time trying to repro this with my where was this 
 searcher/core opened from debug code - I got busy with other things before 
 hitting pa dirt though - but it's still got my attention!

 On Mar 12, 2012, at 4:36 PM, Apache Jenkins Server wrote:

 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12719/

 1 tests failed.
 FAILED:  
 junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

 Error Message:
 ERROR: SolrIndexSearcher opens=91 closes=90

 Stack Trace:
 junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=91 
 closes=90
       at 
 org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:211)
       at 
 org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:100)
       at 
 org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
       at 
 org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
       at 
 org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
       at 
 org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)




 Build Log (for compile errors):
 [...truncated 8841 lines...]



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

 - Mark Miller
 lucidimagination.com












 -
 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

Re: Exposing Solr routing to SolrJ client

2012-03-12 Thread Per Steffensen



Right, you can't yet even with CloudSolrServer - but I think it will 
be done soon - certainly before the 4 release anyway.
Ok, I will cross my fingers for it to be done soon. Thanks for your kind 
help.


Regards, Steff

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

[jira] [Commented] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter

2012-03-12 Thread Yonik Seeley (Commented) (JIRA)

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

Yonik Seeley commented on SOLR-3230:

bq. There is no way to cache and force the order on 1st request?

You would currently need to use the lucene query parser to construct a single
query with both:
{code}
fq=+_query_:{!bbox} +_query_:{!geofilt}
{code}

Not pretty, but lets you experiment at least.

bq. Parameter? style=range or fieldcache? Default to fieldcache as it is now?

perhaps method=fc?
As far as the default, it's really tough to tell. For small distances, I'd
guess that range queries would normally be faster, and that's likely to be the
common case?

Performance improvement for geofilt by doing a bbox approximation and then
Filter
-

Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Grant Ingersoll
Fix For: 4.0

Attachments: SOLR-3230.patch

This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment

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

[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable

2012-03-12 Thread Yonik Seeley (Commented) (JIRA)


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

Yonik Seeley commented on SOLR-3221:


bq. The above monitor contention would appear to suggest that in some cases its 
possible for liveness issues to occur and for simple queries to be starved of 
resources simply due to a lack of attention from the viewpoint of context 
switching.

that's pretty interesting... how many concurrent requests were you running 
through a single aggregator?

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Exposing Solr routing to SolrJ client

2012-03-12 Thread Yonik Seeley

On Mon, Mar 12, 2012 at 8:15 AM, Mark Miller markrmil...@gmail.com wrote:
 Currently it doesn't send directly to the leader, but this is planned - it's 
 a little tricky due to lack of access to the Schema for hashing

Hmmm, why is this?  Identification of the uniqueKey field?  Maybe we
just assume id, or let the user configure it if it's something
different.  That should really be best practice along with sticking
to normal java identifiers for field names.

-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10

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

Re: Exposing Solr routing to SolrJ client


On Mar 12, 2012, at 5:32 PM, Yonik Seeley wrote:

 On Mon, Mar 12, 2012 at 8:15 AM, Mark Miller markrmil...@gmail.com wrote:
 Currently it doesn't send directly to the leader, but this is planned - it's 
 a little tricky due to lack of access to the Schema for hashing
 
 Hmmm, why is this?  Identification of the uniqueKey field?  Maybe we
 just assume id, or let the user configure it if it's something
 different.  That should really be best practice along with sticking
 to normal java identifiers for field names.

Yeah, for id my plan was just let the user supply the field, perhaps default to 
id. The other issue is that we hash on the indexed value though - which we get 
though a customizable field type method impl last I recall. I think this tends 
to be the same as the raw text for the types we care about. But we have to make 
some assumptions - it's not really arbitrary support - though it should easily 
cover the current common types of numeric or string. I think most impls end up 
using UnicodeUtil.UTF16toUTF8 and hopefully most toInternal methods simply 
return what is passed in (ie use the base class impl)...


  /** Given an indexed term, append the human readable representation*/
  public CharsRef indexedToReadable(BytesRef input, CharsRef output) {
UnicodeUtil.UTF8toUTF16(input, output);
return output;
  }


  public String toInternal(String val) {
// - used in delete when a Term needs to be created.
// - used by the default getTokenizer() and createField()
return val;
  }

 
 -Yonik
 lucenerevolution.com - Lucene/Solr Open Source Search Conference.
 Boston May 7-10
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

- Mark Miller
lucidimagination.com










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

Re: Exposing Solr routing to SolrJ client

2012-03-12 Thread Yonik Seeley

On Mon, Mar 12, 2012 at 5:39 PM, Mark Miller markrmil...@gmail.com wrote:

 On Mar 12, 2012, at 5:32 PM, Yonik Seeley wrote:

 On Mon, Mar 12, 2012 at 8:15 AM, Mark Miller markrmil...@gmail.com wrote:
 Currently it doesn't send directly to the leader, but this is planned - 
 it's a little tricky due to lack of access to the Schema for hashing

 Hmmm, why is this?  Identification of the uniqueKey field?  Maybe we
 just assume id, or let the user configure it if it's something
 different.  That should really be best practice along with sticking
 to normal java identifiers for field names.

 Yeah, for id my plan was just let the user supply the field, perhaps default 
 to id. The other issue is that we hash on the indexed value though - which we 
 get though a customizable field type method impl last I recall. I think this 
 tends to be the same as the raw text for the types we care about. But we have 
 to make some assumptions - it's not really arbitrary support - though it 
 should easily cover the current common types of numeric or string. I think 
 most impls end up using UnicodeUtil.UTF16toUTF8 and hopefully most toInternal 
 methods simply return what is passed in (ie use the base class impl)...


Non string (or compatible) ids are more trouble than they are
worth... and since cloud is new, I think it would be fine to say use
a string id.

-Yonik
lucenerevolution.com - Lucene/Solr Open Source Search Conference.
Boston May 7-10

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

[jira] [Commented] (SOLR-3098) analysis gui hangs if no tokens are output

2012-03-12 Thread Uwe Schindler (Commented) (JIRA)


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

Uwe Schindler commented on SOLR-3098:
-

Thanks! Looks like not a hang (like infinite loop), it was simply a 
javascript error that halted the script... If you dont have the Javascript 
consoile open, you would simply wonder why nothing happens. Die, 
(JavaScript|UntypedLanguage), die :-)

 analysis gui hangs if no tokens are output
 --

 Key: SOLR-3098
 URL: https://issues.apache.org/jira/browse/SOLR-3098
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Stefan Matheis (steffkes)
  Labels: newdev
 Attachments: SOLR-3098.patch


 try entering the for text_en

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3162) Continue work on new admin UI

2012-03-12 Thread Aliaksandr Zhuhrou (Commented) (JIRA)


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

Aliaksandr Zhuhrou commented on SOLR-3162:
--

Guys, does the new admin interface works with the war deployment for solr?
I got NullPointerException on the 
org.apache.solr.servlet.LoadAdminUiServlet#doGet
File f = new File(getServletContext().getRealPath(admin.html)); 
I am using tomcat 7.0.23 for deployment.
Also I may mess something with solr.war

 Continue work on new admin UI
 -

 Key: SOLR-3162
 URL: https://issues.apache.org/jira/browse/SOLR-3162
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis, web gui
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
 Fix For: 4.0

 Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, 
 SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, 
 SOLR-3162.patch, SOLR-3162.patch


 There have been more improvements to how the new UI works, but the current 
 open bugs are getting hard to keep straight. This is the new catch-all JIRA 
 for continued improvements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module

2012-03-12 Thread Ryan McKinley (Commented) (JIRA)


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

Ryan McKinley commented on LUCENE-3795:
---

I think this is ready for /trunk

Unless there are objections, I will commit tomorrow -- and we can iterate from 
there

 Replace spatial contrib module with LSP's spatial-lucene module
 ---

 Key: LUCENE-3795
 URL: https://issues.apache.org/jira/browse/LUCENE-3795
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0


 I propose that Lucene's spatial contrib module be replaced with the 
 spatial-lucene module within Lucene Spatial Playground (LSP).  LSP has been 
 in development for approximately 1 year by David Smiley, Ryan McKinley, and 
 Chris Male and we feel it is ready.  LSP is here: 
 http://code.google.com/p/lucene-spatial-playground/  and the spatial-lucene 
 module is intuitively in svn/trunk/spatial-lucene/.
 I'll add more comments to prevent the issue description from being too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module

2012-03-12 Thread Robert Muir (Commented) (JIRA)

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

Robert Muir commented on LUCENE-3795:
-

I'm still hoping the logging issue will get resolved.

Can we please remove this dependency? Again I don't think we should be logging
at this level.
For example its dangerous and bogus to suppress exceptions and log instead:
this is an API component.

Higher level code (e.g. Solr) with more context can implement logging
appropriately, but we should just throw
Exceptions for Lucene API users.

For example, TwoDoublesStrategy.makeQuery has this code:
{code}
} catch(Exception ex) {
log.warn(error making score, ex);
}
{code}

Replace spatial contrib module with LSP's spatial-lucene module
---

Key: LUCENE-3795
URL: https://issues.apache.org/jira/browse/LUCENE-3795
Project: Lucene - Java
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 4.0

I propose that Lucene's spatial contrib module be replaced with the
spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been
in development for approximately 1 year by David Smiley, Ryan McKinley, and
Chris Male and we feel it is ready. LSP is here:
http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene
module is intuitively in svn/trunk/spatial-lucene/.
I'll add more comments to prevent the issue description from being too long.

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

[jira] [Commented] (SOLR-3221) Make Shard handler threadpool configurable

2012-03-12 Thread Greg Bowyer (Commented) (JIRA)


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

Greg Bowyer commented on SOLR-3221:
---

About 100 Requests/second 

 Make Shard handler threadpool configurable
 --

 Key: SOLR-3221
 URL: https://issues.apache.org/jira/browse/SOLR-3221
 Project: Solr
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Greg Bowyer
Assignee: Erick Erickson
  Labels: distributed, http, shard
 Attachments: SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-3x_branch.patch, 
 SOLR-3221-3x_branch.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, 
 SOLR-3221-trunk.patch, SOLR-3221-trunk.patch, SOLR-3221-trunk.patch


 From profiling of monitor contention, as well as observations of the
 95th and 99th response times for nodes that perform distributed search
 (or ‟aggregator‟ nodes) it would appear that the HttpShardHandler code
 currently does a suboptimal job of managing outgoing shard level
 requests.
 Presently the code contained within lucene 3.5's SearchHandler and
 Lucene trunk / 3x's ShardHandlerFactory create arbitrary threads in
 order to service distributed search requests. This is done presently to
 limit the size of the threadpool such that it does not consume resources
 in deployment configurations that do not use distributed search.
 This unfortunately has two impacts on the response time if the node
 coordinating the distribution is under high load.
 The usage of the MaxConnectionsPerHost configuration option results in
 aggressive activity on semaphores within HttpCommons, it has been
 observed that the aggregator can have a response time far greater than
 that of the searchers. The above monitor contention would appear to
 suggest that in some cases its possible for liveness issues to occur and
 for simple queries to be starved of resources simply due to a lack of
 attention from the viewpoint of context switching.
 With, as mentioned above the http commons connection being hotly
 contended
 The fair, queue based configuration eliminates this, at the cost of
 throughput.
 This patch aims to make the threadpool largely configurable allowing for
 those using solr to choose the throughput vs latency balance they
 desire.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module

2012-03-12 Thread Ryan McKinley (Commented) (JIRA)


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

Ryan McKinley commented on LUCENE-3795:
---

I think we can remove logging... i'll take a look

 Replace spatial contrib module with LSP's spatial-lucene module
 ---

 Key: LUCENE-3795
 URL: https://issues.apache.org/jira/browse/LUCENE-3795
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 4.0


 I propose that Lucene's spatial contrib module be replaced with the 
 spatial-lucene module within Lucene Spatial Playground (LSP).  LSP has been 
 in development for approximately 1 year by David Smiley, Ryan McKinley, and 
 Chris Male and we feel it is ready.  LSP is here: 
 http://code.google.com/p/lucene-spatial-playground/  and the spatial-lucene 
 module is intuitively in svn/trunk/spatial-lucene/.
 I'll add more comments to prevent the issue description from being too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3162) Continue work on new admin UI

2012-03-12 Thread Thomas Weidman (Commented) (JIRA)


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

Thomas Weidman commented on SOLR-3162:
--

Hi, I've made some adjustments to Dataimport admin handler UI that others may 
like:

1) js\scripts\dataimport.js - add new var in dataimport.html template loading:

 var buttons = $( 'button.actions', dataimport_element );

2) Add event for button.actions

buttons.on('click', function () {
$.ajax({
url : handler_url + '?command=' 
+ $(this).attr('command'),
dataType : 'xml',
beforeSend : function( xhr, 
settings )
{
},
success : function( response, 
text_status, xhr )
{
console.debug( response 
);

dataimport_fetch_status();
},
error : function( xhr, 
text_status, error_thrown )
{
console.debug( 
arguments );
},
complete : function( xhr, 
text_status )
{
}
});
});


3) Add buttons to template


fieldset
legend style=padding:10px 5px; 2px 
5pxcommands/legend
button class=actions command=full-importFull 
Import/button
nbsp;nbsp;
button class=actions command=delta-importDelta 
Import/button
/fieldset

 Continue work on new admin UI
 -

 Key: SOLR-3162
 URL: https://issues.apache.org/jira/browse/SOLR-3162
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis, web gui
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
 Fix For: 4.0

 Attachments: SOLR-3162-index.png, SOLR-3162-schema-browser.png, 
 SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, SOLR-3162.patch, 
 SOLR-3162.patch, SOLR-3162.patch


 There have been more improvements to how the new UI works, but the current 
 open bugs are getting hard to keep straight. This is the new catch-all JIRA 
 for continued improvements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3229) TermVectorComponent does not return terms in distributed search


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

Hang Xie updated SOLR-3229:
---

Attachment: TermVectorComponent.patch

Revised, it seems distributedProcess() is unnecessary and can be removed, the 
only major change is add finishStage() to merge responses for subrequests to 
shards.

 TermVectorComponent does not return terms in distributed search
 ---

 Key: SOLR-3229
 URL: https://issues.apache.org/jira/browse/SOLR-3229
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0
 Environment: Ubuntu 11.10, openjdk-6
Reporter: Hang Xie
  Labels: patch
 Fix For: 4.0

 Attachments: TermVectorComponent.patch


 TermVectorComponent does not return terms in distributed search, the 
 distributedProcess() incorrectly uses Solr Unique Key to do subrequests, 
 while process() expects Lucene document ids. Also, parameters are transferred 
 in different format thus making distributed search returns no result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3229) TermVectorComponent does not return terms in distributed search


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

Hang Xie updated SOLR-3229:
---

Attachment: (was: TermVectorComponent.patch)

 TermVectorComponent does not return terms in distributed search
 ---

 Key: SOLR-3229
 URL: https://issues.apache.org/jira/browse/SOLR-3229
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0
 Environment: Ubuntu 11.10, openjdk-6
Reporter: Hang Xie
  Labels: patch
 Fix For: 4.0

 Attachments: TermVectorComponent.patch


 TermVectorComponent does not return terms in distributed search, the 
 distributedProcess() incorrectly uses Solr Unique Key to do subrequests, 
 while process() expects Lucene document ids. Also, parameters are transferred 
 in different format thus making distributed search returns no result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3229) TermVectorComponent does not return terms in distributed search