[jira] Created: (SOLR-706) Fast auto-complete suggestions
Fast auto-complete suggestions -- Key: SOLR-706 URL: https://issues.apache.org/jira/browse/SOLR-706 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.4 Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 1.4 A lot of users have suggested that facet.prefix in Solr is not the most efficient way to implement an auto-complete suggestion feature. A fast in-memory trie like structure has often been suggested instead. This issue aims to incorporate a faster/efficient way to answer auto-complete queries in Solr. Refer to the following discussion on solr-dev -- http://markmail.org/message/sjjojrnroo3msugj -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-430: --- Attachment: SOLR-430.patch Changes to QueryResponse to parse SpellCheckComponent's response. # The SpellCheckResponse inner class is probably big enough to deserve a separate source file. # Need to add test cases. SpellcheckerRequest / Response -- Key: SOLR-430 URL: https://issues.apache.org/jira/browse/SOLR-430 Project: Solr Issue Type: New Feature Components: clients - java, spellchecker Affects Versions: 1.3 Reporter: Matthew Runo Attachments: SOLR-430.patch SolrJ should support sending a request that interacts with the SpellCheckComponent from SOLR-572 and handling the results in a sane manner so users of SolrJ can make use of the SpellCheckComponent code without parsing XML themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CHANGES.txt
On Aug 16, 2008, at 10:52 PM, Koji Sekiguchi wrote: BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when solr 1.3 is released? I don't have any strong opinion on that. Since solr-ruby will ship (it gets packaged, right?) with Solr 1.3 distribution, the version that it ships with should be considered the official one for that release. How Apache releases and rubyforge gem releases sync I'm not yet sure how we should do that. Unfortunately I haven't been doing very much Ruby lately. The active folks in solr-ruby get to make the decisions... so whatever you feel is best I'm fine with for now. :) Erik
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623379#action_12623379 ] Yonik Seeley commented on SOLR-647: --- bq. How will SolrCore#getCoreDescriptor() work. what will it return? The original core descriptor (the original name). bq. should the getCore() have synchronized block? CoreContainer.getCore() does. I removed CoreDescriptor.getCore() bq. can we manage with a ConcurrentHashMap? A lock to be obtained per request looks like too much of a price . It could be reworked in the future, but a single synchronized map lookup per top-level request is certainly nothing to worry about - there are probably at least hundreds of synchronized calls per average request. Do SolrCore.close() in a refcounted way --- Key: SOLR-647 URL: https://issues.apache.org/jira/browse/SOLR-647 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Assignee: Yonik Seeley Fix For: 1.3 Attachments: refcount_example.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, SOLR-647.patch, SOLR-647.patch The method _SolrCore.close()_ directly closes the core . It can cause Exceptions for in-flight requests. The _close()_ method should just do a decrement on refcount and the actual close must happen when the last request being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r686780 - in /lucene/solr/trunk: ./ client/java/solrj/src/org/apache/solr/client/solrj/embedded/ client/java/solrj/test/org/apache/solr/client/solrj/embedded/ src/java/org/apache/solr/
do we really need the get to be synchronized (as I posted on the issue) ?
On Mon, Aug 18, 2008 at 8:38 PM, [EMAIL PROTECTED] wrote:
Author: yonik
Date: Mon Aug 18 08:08:28 2008
New Revision: 686780
URL: http://svn.apache.org/viewvc?rev=686780view=rev
Log:
SOLR-647: refcount cores
Modified:
lucene/solr/trunk/CHANGES.txt
lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
lucene/solr/trunk/client/java/solrj/test/org/apache/solr/client/solrj/embedded/LargeVolumeEmbeddedTest.java
lucene/solr/trunk/client/java/solrj/test/org/apache/solr/client/solrj/embedded/SolrExampleEmbeddedTest.java
lucene/solr/trunk/src/java/org/apache/solr/core/CoreContainer.java
lucene/solr/trunk/src/java/org/apache/solr/core/CoreDescriptor.java
lucene/solr/trunk/src/java/org/apache/solr/core/SolrCore.java
lucene/solr/trunk/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java
lucene/solr/trunk/src/java/org/apache/solr/util/TestHarness.java
lucene/solr/trunk/src/test/org/apache/solr/core/SolrCoreTest.java
lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
lucene/solr/trunk/src/webapp/web/admin/index.jsp
Modified: lucene/solr/trunk/CHANGES.txt
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=686780r1=686779r2=686780view=diff
==
--- lucene/solr/trunk/CHANGES.txt (original)
+++ lucene/solr/trunk/CHANGES.txt Mon Aug 18 08:08:28 2008
@@ -358,6 +358,9 @@
1.3 release. Speciffically, solr.xml has replaced multicore.xml, and uses
a slightly
different syntax. The solrj classes: MultiCore{Request/Response/Params}
have been
renamed: CoreAdmin{Request/Response/Params} (hossman, ryan, Henri
Biestro)
+
+ 3. SOLR-647: reference count the SolrCore uses to prevent a premature
+close while a core is still in use. (Henri Biestro, Noble Paul, yonik)
Optimizations
1. SOLR-276: improve JSON writer speed. (yonik)
Modified:
lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java?rev=686780r1=686779r2=686780view=diff
==
---
lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(original)
+++
lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
Mon Aug 18 08:08:28 2008
@@ -36,6 +36,7 @@
import org.apache.solr.common.util.NamedList;
import org.apache.solr.core.CoreContainer;
import org.apache.solr.core.SolrCore;
+import org.apache.solr.core.CoreDescriptor;
import org.apache.solr.request.BinaryResponseWriter;
import org.apache.solr.request.QueryResponseWriter;
import org.apache.solr.request.SolrQueryRequest;
@@ -54,38 +55,46 @@
*/
public class EmbeddedSolrServer extends SolrServer
{
-
- protected final CoreContainer multicore; // either cores
- protected final SolrCore core; // or single core
- protected final String coreName; // use CoreContainer registry
-
+ protected final CoreContainer coreContainer;
+ protected final String coreName;
private final SolrRequestParsers _parser;
+ /**
+ * Use the other constructor using a CoreContainer and a name.
+ * @param core
+ * @deprecated
+ */
+ @Deprecated
public EmbeddedSolrServer( SolrCore core )
{
if ( core == null ) {
throw new NullPointerException(SolrCore instance required);
}
-this.core = core;
-if (core.getCoreDescriptor() != null) {
- this.multicore = core.getCoreDescriptor().getMultiCore();
- this.coreName = core.getCoreDescriptor().getName();
-} else {
- this.multicore = null;
- this.coreName = null;
-}
+CoreDescriptor dcore = core.getCoreDescriptor();
+if (dcore == null)
+ throw new NullPointerException(CoreDescriptor required);
+
+CoreContainer cores = dcore.getCoreContainer();
+if (cores == null)
+ throw new NullPointerException(CoreContainer required);
+
+coreName = dcore.getName();
+coreContainer = cores;
_parser = new SolrRequestParsers( null );
}
- public EmbeddedSolrServer( CoreContainer multicore, String coreName )
+ /**
+ * Creates a SolrServer.
+ * @param coreContainer the core container
+ * @param coreName the core name
+ */
+ public EmbeddedSolrServer( CoreContainer coreContainer, String coreName )
{
-if ( multicore == null ) {
+if ( coreContainer == null ) {
throw new NullPointerException(CoreContainer instance required);
}
-this.core = null;
-this.multicore = multicore;
+this.coreContainer = coreContainer;
[jira] Resolved: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-647. --- Resolution: Fixed I've committed this patch. There is probably some more multicore work to be done, but they can get their own issues. Do SolrCore.close() in a refcounted way --- Key: SOLR-647 URL: https://issues.apache.org/jira/browse/SOLR-647 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Assignee: Yonik Seeley Fix For: 1.3 Attachments: refcount_example.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, SOLR-647.patch, SOLR-647.patch The method _SolrCore.close()_ directly closes the core . It can cause Exceptions for in-flight requests. The _close()_ method should just do a decrement on refcount and the actual close must happen when the last request being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Only 3 issues left
Hi Look mom, only 3 issues to go! https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12312486 Out of those, 1 is trivial (lucene jar update), 1 looks committed (the maven one), and only SOLR-646 is serious. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623385#action_12623385 ] Ryan McKinley commented on SOLR-139: to me the key is getting an interface that would allow for the existing fields to be stored a number of ways: * within the index itself * within an independent index (as you suggest) * within SQL * on the file system * ... Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: New Feature Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
DocIterator doesn't support remove(); should throw UnsupportedOperationException Key: SOLR-707 URL: https://issues.apache.org/jira/browse/SOLR-707 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial In DocSlice, DocIterator doesn't support the optional remove operation. According to the Iterator Javadocs, remove should throw an UnsupportedOperationException in this case rather than be a no-op. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Only 3 issues left
Only 3.so alienmust...add..more...issues...argh! On Mon, Aug 18, 2008 at 9:20 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: Hi Look mom, only 3 issues to go! https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12312486 Out of those, 1 is trivial (lucene jar update), 1 looks committed (the maven one), and only SOLR-646 is serious. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-707: --- Attachment: SOLR-707.patch Patch to throw UnsupportedOperationException and simple Javadoc comment saying the remove() method is not supported. DocIterator doesn't support remove(); should throw UnsupportedOperationException Key: SOLR-707 URL: https://issues.apache.org/jira/browse/SOLR-707 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Sean Timm Priority: Trivial Attachments: SOLR-707.patch In DocSlice, DocIterator doesn't support the optional remove operation. According to the Iterator Javadocs, remove should throw an UnsupportedOperationException in this case rather than be a no-op. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Only 3 issues left
such as... using Term Vectors for fast faceting on tokenized... but it is in TODOs of source files! cNET data was so small when SimpleFacets were born, only 40 docs... Quoting Shalin Shekhar Mangar [EMAIL PROTECTED]: Only 3.so alienmust...add..more...issues...argh! On Mon, Aug 18, 2008 at 9:20 PM, Otis Gospodnetic [EMAIL PROTECTED] wrote: Hi Look mom, only 3 issues to go! https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12312486 Out of those, 1 is trivial (lucene jar update), 1 looks committed (the maven one), and only SOLR-646 is serious. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch -- Regards, Shalin Shekhar Mangar.
[jira] Assigned: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic reassigned SOLR-707: - Assignee: Otis Gospodnetic DocIterator doesn't support remove(); should throw UnsupportedOperationException Key: SOLR-707 URL: https://issues.apache.org/jira/browse/SOLR-707 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Trivial Attachments: SOLR-707.patch In DocSlice, DocIterator doesn't support the optional remove operation. According to the Iterator Javadocs, remove should throw an UnsupportedOperationException in this case rather than be a no-op. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623416#action_12623416 ] Noble Paul commented on SOLR-139: - there are pros and cons w/ each approaches (am I discovering a universal truth here ;) ) Many approaches can to confuse users . I can propose something like modifiabletrue/modifiable in the manIndex . And say modificationStrategysolr.SepareteIndexStrategy/modificationStrategy or modificationStrategysolr.SameIndexStrategy/modificationStrategy (I did not mention the other two because of personal preferences ;) ) Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: New Feature Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: upgrade lucene
+1. Maybe just wait a few more days for LUCENE-1333 - it looks like Mike will commit in a few days. Otis - Original Message From: Yonik Seeley [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Monday, August 18, 2008 2:33:29 PM Subject: upgrade lucene So it looks like there have been some small bug fixes on lucene trunk since the version that Solr has. Any objections to updating to the latest? -Yonik
Re: CHANGES.txt
For the solr-ruby version, I'll take a poll on solr-user and ruby-dev as soon as I pick up options I'm thinking now. Koji Erik Hatcher wrote: On Aug 16, 2008, at 10:52 PM, Koji Sekiguchi wrote: BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when solr 1.3 is released? I don't have any strong opinion on that. Since solr-ruby will ship (it gets packaged, right?) with Solr 1.3 distribution, the version that it ships with should be considered the official one for that release. How Apache releases and rubyforge gem releases sync I'm not yet sure how we should do that. Unfortunately I haven't been doing very much Ruby lately. The active folks in solr-ruby get to make the decisions... so whatever you feel is best I'm fine with for now. :) Erik
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-646:
---
Attachment: solr-646.patch
Refactored following HossMan recommendations.
This still includes the include (was import) feature but removing it is easy
(in Config.java) will reduce modifications in ResourceLoader.java.
Added a specific test that loads a shared schema config but uses properties
to differentiate behavior (different locales, different dataDirs).
Includes a one letter fix in CoreContainer.load for aliases (get(a) instead of
get(i)).
More tests will follow (persist verification is manual) I'll try to cut the
patch in 2 (properties - include).
I might be busier in the coming days but will try not to slow down 1.3 release
if next review says this is on the right track.
Configuration properties in multicore.xml
-
Key: SOLR-646
URL: https://issues.apache.org/jira/browse/SOLR-646
Project: Solr
Issue Type: New Feature
Affects Versions: 1.3
Reporter: Henri Biestro
Assignee: Ryan McKinley
Fix For: 1.3
Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
solr-646.patch, solr-646.patch
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration schema files can use expression based on
properties defined in multicore.xml.
h3. Use cases:
Share the same schema and/or config file between multiple cores but point to
different dataDirs using a dataDir${core.datadir}/dataDir
Change the general layout between data, config schema directories.
Define 'installation' wide properties (for replication for instance) in
multicore.properties (different base/install/data directories on different
hosts).
h3. Syntax:
h4. Defining properties:
Either in the multicore.properties file (usual property format):
{code:xml}
env.value=an installation value
env.other_value=another installation value
{code}
In the multicore.xml:
{code:xml}
multicore'
property name='mp0'a value/property !-- a basic property --
property name='mp1'${env.value}/property }!-- a property whose value
is an expression --
core name='core_name'
property name='p0'some value/property
property name='p1'${mp0}-and some data/property
/core
/multicore
{code}
h4. Using properties:
Besides used defined properties, the following core descriptor properties are
automatically defined in each core context, namely:
{code}
solr.core.instanceDir
solr.core.instancePath
solr.core.name
solr.core.configName
solr.core.schemaName
{code}
All properties can be used in any attribute or text node of a solrconfig.xml
or schema.xml as in:
{code:xml}
dataDir${core.dataDir}/dataDir
{code}
h4. Technical specifications
Multicore.xml can define properties at the multicore each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore system properties.
Property definitions can use expressions to define their name value; these
expressions are evaluated in their outer scope context .
Multicore serialization keeps properties as written (ie as expressions if
they were defined so).
The core descriptor properties are automatically defined in each core
context, namely:
solr.core.instanceDir
solr.core.instancePath
solr.core.name
solr.core.configName
solr.core.schemaName
h4. Test:
The following (contrived) multicore.xml:
{code:xml}
multicore adminPath='/admin/multicore' persistent='true'
property name='revision'33/property !-- a basic property --
property name='zero'0/property !-- used to expand the core0 name --
property name='one'1/property !-- used to expand the core1 name --
property name='id_type'bogus/property !-- a bogus type that will be
overriden --
property name='updateHandler'bogus/property !-- a bogus updateHandler
that will be overriden --
core name='core${zero}' instanceDir='core0/'!-- the name is expanded
--
property name='id_type'core${zero}_id/property !-- so is a text node
--
property name='updateHandler'solr.DirectUpdateHandler2/property !--
a property can be overriden --
property name='revision'11/property
/core
core name='core${one}' instanceDir='core1/'
property name='id_type'core${one}_id/property
property name='updateHandler'solr.DirectUpdateHandler2/property
property name='revision'22/property
/core
/multicore
{code}
allows this config.xml:
{code:xml}
config
!-- use the defined update handler property --
updateHandler class=${updateHandler} /
requestDispatcher handleSelect=true
requestParsers
[jira] Updated: (SOLR-646) Configuration properties in multicore.xml
[
https://issues.apache.org/jira/browse/SOLR-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-646:
---
Assignee: (was: Ryan McKinley)
I am leaving on vacation... and will be unable to give this any attention, so i
have removed myself as the Assignee
Configuration properties in multicore.xml
-
Key: SOLR-646
URL: https://issues.apache.org/jira/browse/SOLR-646
Project: Solr
Issue Type: New Feature
Affects Versions: 1.3
Reporter: Henri Biestro
Fix For: 1.3
Attachments: solr-646.patch, solr-646.patch, solr-646.patch,
solr-646.patch, solr-646.patch
This patch refers to 'generalized configuration properties' as specified by
[HossMan|https://issues.apache.org/jira/browse/SOLR-350?focusedCommentId=12562834#action_12562834]
This means configuration schema files can use expression based on
properties defined in multicore.xml.
h3. Use cases:
Share the same schema and/or config file between multiple cores but point to
different dataDirs using a dataDir${core.datadir}/dataDir
Change the general layout between data, config schema directories.
Define 'installation' wide properties (for replication for instance) in
multicore.properties (different base/install/data directories on different
hosts).
h3. Syntax:
h4. Defining properties:
Either in the multicore.properties file (usual property format):
{code:xml}
env.value=an installation value
env.other_value=another installation value
{code}
In the multicore.xml:
{code:xml}
multicore'
property name='mp0'a value/property !-- a basic property --
property name='mp1'${env.value}/property }!-- a property whose value
is an expression --
core name='core_name'
property name='p0'some value/property
property name='p1'${mp0}-and some data/property
/core
/multicore
{code}
h4. Using properties:
Besides used defined properties, the following core descriptor properties are
automatically defined in each core context, namely:
{code}
solr.core.instanceDir
solr.core.instancePath
solr.core.name
solr.core.configName
solr.core.schemaName
{code}
All properties can be used in any attribute or text node of a solrconfig.xml
or schema.xml as in:
{code:xml}
dataDir${core.dataDir}/dataDir
{code}
h4. Technical specifications
Multicore.xml can define properties at the multicore each core level.
Properties defined in the multicore scope can override system properties.
Properties defined in a core scope can override multicore system properties.
Property definitions can use expressions to define their name value; these
expressions are evaluated in their outer scope context .
Multicore serialization keeps properties as written (ie as expressions if
they were defined so).
The core descriptor properties are automatically defined in each core
context, namely:
solr.core.instanceDir
solr.core.instancePath
solr.core.name
solr.core.configName
solr.core.schemaName
h4. Test:
The following (contrived) multicore.xml:
{code:xml}
multicore adminPath='/admin/multicore' persistent='true'
property name='revision'33/property !-- a basic property --
property name='zero'0/property !-- used to expand the core0 name --
property name='one'1/property !-- used to expand the core1 name --
property name='id_type'bogus/property !-- a bogus type that will be
overriden --
property name='updateHandler'bogus/property !-- a bogus updateHandler
that will be overriden --
core name='core${zero}' instanceDir='core0/'!-- the name is expanded
--
property name='id_type'core${zero}_id/property !-- so is a text node
--
property name='updateHandler'solr.DirectUpdateHandler2/property !--
a property can be overriden --
property name='revision'11/property
/core
core name='core${one}' instanceDir='core1/'
property name='id_type'core${one}_id/property
property name='updateHandler'solr.DirectUpdateHandler2/property
property name='revision'22/property
/core
/multicore
{code}
allows this config.xml:
{code:xml}
config
!-- use the defined update handler property --
updateHandler class=${updateHandler} /
requestDispatcher handleSelect=true
requestParsers enableRemoteStreaming=false
multipartUploadLimitInKB=2048 /
/requestDispatcher
requestHandler name=standard class=solr.StandardRequestHandler
default=true /
requestHandler name=/update class=solr.XmlUpdateRequestHandler /
requestHandler name=/admin/luke
class=org.apache.solr.handler.admin.LukeRequestHandler /
!-- config for the admin interface --
admin
defaultQuerysolr/defaultQuery
gettableFilessolrconfig.xml schema.xml admin-extra.html/gettableFiles
pingQuery
qt=standardamp;q=solrpingquery
/pingQuery
/admin
1.3 release and SOLR-646
I'm leaving for vacation tomorrow and will have little or no internet access until sept 1 -- from the 1st to the 7th, I will have limited access. The one remaining issue that I am concerned about for 1.3 is how to set the dataDir for various cores in a multicore environment -- SOLR-646 aims to solve this issue. For more background: The original multicore patch included a dataDir=path attribute in the multicore.xml file. Hoss found this problematic since there would be multiple places to set the dataDir -- it is already set in solrconfig.xml -- after some discussion, we agreed a good approach would be to let you set system properties that are valid within the scope of each core from the multicore.xml (now solr.xml) file. If SOLR-646 proves to be too complicated to get into 1.3, I would suggest adding the dataDir attribute back to the core specification and adding documentation explaining the potential pitfalls. ryan
[jira] Commented: (SOLR-697) Update Lucene jar before 1.3 release (was: Lucene TimeLimitCollector)
[
https://issues.apache.org/jira/browse/SOLR-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623522#action_12623522
]
Lars Kotthoff commented on SOLR-697:
Can we update the jars rather sooner than later (i.e. now) so that people get a
chance to test everything before the 1.3 release?
Update Lucene jar before 1.3 release (was: Lucene TimeLimitCollector)
-
Key: SOLR-697
URL: https://issues.apache.org/jira/browse/SOLR-697
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.3
Reporter: Wayne Graham
Fix For: 1.3
When instantiating a SolrCore using the Solr API, a Lucene exception is thrown
{{
org.apache.solr.core.SolrResourceLoader createClassLoader
INFO: Reusing parent classloader
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/lucene/search/TimeLimitedCollector$TimeExceededException
at org.apache.solr.core.SolrConfig.init(SolrConfig.java:132)
at org.apache.solr.core.SolrConfig.init(SolrConfig.java:101)
...
}}
Updating the lucene-core-2.4-dev.jar that is included in the nightly to a
more current snapshot resolves the problem (tested with Lucene r685576).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-708) CoreAdminHandler improvements
CoreAdminHandler improvements - Key: SOLR-708 URL: https://issues.apache.org/jira/browse/SOLR-708 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley CoreAdminHandler unload, rename, alias -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-708) CoreAdminHandler improvements
[ https://issues.apache.org/jira/browse/SOLR-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-708: -- Attachment: SOLR-708.patch Patch implementing unload, reload and alias in the CoreAdminHandler Also standardizes on other for the other core or other name. I filled in the Solrj CoreAdminRequest a bit, but it's obviously incomplete (something I didn't realize when I started). No tests for this yet (am I missing existing CoreAdminHandler unit tests somehwere, or do they not exist yet?) CoreAdminHandler improvements - Key: SOLR-708 URL: https://issues.apache.org/jira/browse/SOLR-708 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Attachments: SOLR-708.patch CoreAdminHandler unload, rename, alias -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
