[jira] Resolved: (SOLR-268) SimplePostTool should show Solr error, not just HTTP code
[ https://issues.apache.org/jira/browse/SOLR-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-268. --- Resolution: Fixed looks fine to me ... i tweaked it so it's fatal instead of a warning and left the old fatal message in (if it makes it to that point the error was probably related to getting a connection in the first place, and the reminder that solr needs to be running is handy) Committed revision 550010. > SimplePostTool should show Solr error, not just HTTP code > - > > Key: SOLR-268 > URL: https://issues.apache.org/jira/browse/SOLR-268 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Trivial > Fix For: 1.3 > > Attachments: post.jar.error.patch > > > Tiny fix to have post.jar show the solr error message, not just a fatal error > when it gets a 400 HTTP code. There is probably a better way to do this but > this is how I did it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)
On 22-Jun-07, at 6:53 AM, Henri Biestro (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-255? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12507326 ] Henri Biestro commented on SOLR-255: Toru, I've been looking quickly at your patch and kinda understands why Otis is pushing for a merge. :-) I dont know how this is usually done; should we merge the 2 issues and merge our patches? I can try & see how this goes if you want. One thing that worries me though is the Lucene patch dependency; any way to only have a Solr patch? I would suspect that Lucene committers are as busy as Solr 's so the review process might take sometime. Although from far, it does look like pretty harmless changes so there is hope... As a side note, I was wondering if we could extend you patch's functionality and get read/write capability per index (as in http:// hellonline.com/blog/?p=55 ,document indexing load balancing could be performed on hashing unique key % number of indexes for instance or by some configurable class). The current functionality would be retained by specificying 'read-only' versus 'read-write' for each index. I just wanted to note (in midst of all this talk of merging patches and adding functionality), that the larger a patch becomes, the harder it is to evaluate and maintain. It might be better to split it up in terms of dependencies: one patch depends on the other. Or, if the core infrastructure is similar/highly dependent, split it up into a core patch and outward-facing-feature patch. -Mike
[jira] Updated: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
new patch to promote responseHeader from a defacto standard to an api standard
in SolrQueryResponse. this enables the SolrCore.execute() method to simply
print out it's contents containing any info people want logged. the format now
is:
Jun 22, 2007 10:37:25 AM org.apache.solr.core.SolrCore execute
INFO: webapp=/solr path=/select/ hits=0 status=0 QTime=0
params={indent=on,start=0,q=solr,version=2.2,rows=10}
which is fully labeled but i think mkaes things much easier to read/parse as
you can look for labels instead of positions which may or may not change.
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-215) Multiple Solr Cores
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507344
]
Henri Biestro commented on SOLR-215:
About solr-255, I've posted a small comment to Toru.
Seems to me that solr-255/solr-215 features are mostly orthogonal; solr-255
allows one core to use mutliple indexes, solr-255 allows multiple cores in one
instance.
But I like the idea of federated search (and federated indexing!).
I'm a bit worried though that adding a Lucene patch dependency & merging
solr-215/solr-255 will make the commit occur even later...
But I'll follow your lead; I'll try & see if I can merge.
> Multiple Solr Cores
> ---
>
> Key: SOLR-215
> URL: https://issues.apache.org/jira/browse/SOLR-215
> Project: Solr
> Issue Type: Improvement
>Reporter: Henri Biestro
>Priority: Minor
> Attachments: solr-215.patch, solr-215.patch, solr-215.patch,
> solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch,
> solr-trunk-542847.patch, solr-trunk-src.patch
>
>
> WHAT:
> As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index.
> This patch is intended to allow multiple cores in Solr which also brings
> multiple indexes capability.
> WHY:
> The current Solr practical wisdom is that one schema - thus one index - is
> most likely to accomodate your indexing needs, using a filter to segregate
> documents if needed. If you really need multiple indexes, deploy multiple web
> applications.
> There are a some use cases however where having multiple indexes or multiple
> cores through Solr itself may make sense.
> Multiple cores:
> Deployment issues within some organizations where IT will resist deploying
> multiple web applications.
> Seamless schema update where you can create a new core and switch to it
> without starting/stopping servers.
> Embedding Solr in your own application (instead of 'raw' Lucene) and
> functionally need to segregate schemas & collections.
> Multiple indexes:
> Multiple language collections where each document exists in different
> languages, analysis being language dependant.
> Having document types that have nothing (or very little) in common with
> respect to their schema, their lifetime/update frequencies or even collection
> sizes.
> HOW:
> The best analogy is to consider that instead of deploying multiple
> web-application, you can have one web-application that hosts more than one
> Solr core. The patch does not change any of the core logic (nor the core
> code); each core is configured & behaves exactly as the one core in 1.2; the
> various caches are per-core & so is the info-bean-registry.
> What the patch does is replace the SolrCore singleton by a collection of
> cores; all the code modifications are driven by the removal of the different
> singletons (the config, the schema & the core).
> Each core is 'named' and a static map (keyed by name) allows to easily manage
> them.
> You declare one servlet filter mapping per core you want to expose in the
> web.xml; this allows easy to access each core through a different url.
> USAGE (example web deployment, patch installed):
> Step0
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml
> monitor.ml
> Will index the 2 documents in solr.xml & monitor.xml
> Step1:
> http://localhost:8983/solr/core0/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core0 index; 2
> documents
> Step2:
> http://localhost:8983/solr/core1/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core1 index; no
> documents
> Step3:
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml
> java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml
> Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1;
> running queries from the admin interface, you can verify indexes have
> different content.
> USAGE (Java code):
> //create a configuration
> SolrConfig config = new SolrConfig("solrconfig.xml");
> //create a schema
> IndexSchema schema = new IndexSchema(config, "schema0.xml");
> //create a core from the 2 other.
> SolrCore core = new SolrCore("core0", "/path/to/index", config, schema);
> //Accessing a core:
> SolrCore core = SolrCore.getCore("core0");
> PATCH MODIFICATIONS DETAILS (per package):
> org.apache.solr.core:
> The heaviest modifications are in SolrCore & SolrConfig.
> SolrCore is the most obvious modification; instead of a singleton, there is a
> static map of cores keyed by names and assorted methods. To retain some
> compatibility, the 'null' named core replaces the singleton for the relevant
> methods, for instance SolrCore.getCore(). One small constraint on the core
> name is they can't contain '/' or '\' avoiding potential url & file path
> problems.
> SolrC
[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)
[
https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507326
]
Henri Biestro commented on SOLR-255:
Toru,
I've been looking quickly at your patch and kinda understands why Otis is
pushing for a merge. :-)
I dont know how this is usually done; should we merge the 2 issues and merge
our patches?
I can try & see how this goes if you want.
One thing that worries me though is the Lucene patch dependency; any way to
only have a Solr patch?
I would suspect that Lucene committers are as busy as Solr 's so the review
process might take sometime.
Although from far, it does look like pretty harmless changes so there is hope...
As a side note, I was wondering if we could extend you patch's functionality
and get read/write capability per index (as in http://hellonline.com/blog/?p=55
,document indexing load balancing could be performed on hashing unique key %
number of indexes for instance or by some configurable class). The current
functionality would be retained by specificying 'read-only' versus 'read-write'
for each index.
Nice job btw.
Henri
> RemoteSearchable for Solr(use RMI)
> --
>
> Key: SOLR-255
> URL: https://issues.apache.org/jira/browse/SOLR-255
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Toru Matsuzawa
> Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a tag.
>
> E:\sample\data1
> E:\sample\data2
> rmi://localhost
>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the is
> updated,
> that document data in the index will be deleted and data of the updated
> document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from
> SolrCore
> by specifying "< remoteSearcher>true" in solrconfig.xml.(It
> is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
> What should be done?
> - Are there any other considerations about this issue, which I have
> overlooked?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507312
]
Will Johnson commented on SOLR-267:
---
One thing that comes to mind is making the response header a standard
part of the SolrQueryResponse object with get/set/add methods then the
log message can just print out what ever is in the response header. With
trunk, it already contains much of the same data (status, qtime,
params). The only issue is that in order to keep things 'clean' the
output would change to being fully labeled:
webapp=/solr path=/select/ status=0 QTime=63
params={indent=on,start=0,q=*:*,version=2.2,rows=10} myotherheader=foo
In general I think this makes things much cleaner and easier to read but
it does break backwards compatibility for log parsing purposes. Any
other ideas?
- will
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-215) Multiple Solr Cores
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507207
]
Otis Gospodnetic commented on SOLR-215:
---
Excellent. I'll assume you'll add something like this to your patch, then.
Any thoughs on SOLR-255 and ensuring you and Toru don't step on each other's
toes?
> Multiple Solr Cores
> ---
>
> Key: SOLR-215
> URL: https://issues.apache.org/jira/browse/SOLR-215
> Project: Solr
> Issue Type: Improvement
>Reporter: Henri Biestro
>Priority: Minor
> Attachments: solr-215.patch, solr-215.patch, solr-215.patch,
> solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch,
> solr-trunk-542847.patch, solr-trunk-src.patch
>
>
> WHAT:
> As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index.
> This patch is intended to allow multiple cores in Solr which also brings
> multiple indexes capability.
> WHY:
> The current Solr practical wisdom is that one schema - thus one index - is
> most likely to accomodate your indexing needs, using a filter to segregate
> documents if needed. If you really need multiple indexes, deploy multiple web
> applications.
> There are a some use cases however where having multiple indexes or multiple
> cores through Solr itself may make sense.
> Multiple cores:
> Deployment issues within some organizations where IT will resist deploying
> multiple web applications.
> Seamless schema update where you can create a new core and switch to it
> without starting/stopping servers.
> Embedding Solr in your own application (instead of 'raw' Lucene) and
> functionally need to segregate schemas & collections.
> Multiple indexes:
> Multiple language collections where each document exists in different
> languages, analysis being language dependant.
> Having document types that have nothing (or very little) in common with
> respect to their schema, their lifetime/update frequencies or even collection
> sizes.
> HOW:
> The best analogy is to consider that instead of deploying multiple
> web-application, you can have one web-application that hosts more than one
> Solr core. The patch does not change any of the core logic (nor the core
> code); each core is configured & behaves exactly as the one core in 1.2; the
> various caches are per-core & so is the info-bean-registry.
> What the patch does is replace the SolrCore singleton by a collection of
> cores; all the code modifications are driven by the removal of the different
> singletons (the config, the schema & the core).
> Each core is 'named' and a static map (keyed by name) allows to easily manage
> them.
> You declare one servlet filter mapping per core you want to expose in the
> web.xml; this allows easy to access each core through a different url.
> USAGE (example web deployment, patch installed):
> Step0
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml
> monitor.ml
> Will index the 2 documents in solr.xml & monitor.xml
> Step1:
> http://localhost:8983/solr/core0/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core0 index; 2
> documents
> Step2:
> http://localhost:8983/solr/core1/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core1 index; no
> documents
> Step3:
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml
> java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml
> Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1;
> running queries from the admin interface, you can verify indexes have
> different content.
> USAGE (Java code):
> //create a configuration
> SolrConfig config = new SolrConfig("solrconfig.xml");
> //create a schema
> IndexSchema schema = new IndexSchema(config, "schema0.xml");
> //create a core from the 2 other.
> SolrCore core = new SolrCore("core0", "/path/to/index", config, schema);
> //Accessing a core:
> SolrCore core = SolrCore.getCore("core0");
> PATCH MODIFICATIONS DETAILS (per package):
> org.apache.solr.core:
> The heaviest modifications are in SolrCore & SolrConfig.
> SolrCore is the most obvious modification; instead of a singleton, there is a
> static map of cores keyed by names and assorted methods. To retain some
> compatibility, the 'null' named core replaces the singleton for the relevant
> methods, for instance SolrCore.getCore(). One small constraint on the core
> name is they can't contain '/' or '\' avoiding potential url & file path
> problems.
> SolrConfig (& SolrIndexConfig) are now used to persist all configuration
> options that need to be quickly accessible to the various components. Most of
> these variables were static like those found in SolrIndexSearcher. Mimicking
> the intent of these static variables, SolrConfig & SolrIndexConfig use public
[jira] Commented: (SOLR-215) Multiple Solr Cores
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507189
]
Henri Biestro commented on SOLR-215:
I like the suggestion. Thanks Otis.
The specific admin handler is definitely a good idea to handle cores (no need
to modify the servlet dispatch filter).
Could definitely use a naming convention and/or specify schema & config as
parameters as in:
/admin/coremanager?cmd=add&name=foo&schema=foo-schema.xml&config=foo-config.xml
It does not preclude being able to upload the schema & config files (so the
files dont have to be there before).
> Multiple Solr Cores
> ---
>
> Key: SOLR-215
> URL: https://issues.apache.org/jira/browse/SOLR-215
> Project: Solr
> Issue Type: Improvement
>Reporter: Henri Biestro
>Priority: Minor
> Attachments: solr-215.patch, solr-215.patch, solr-215.patch,
> solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch,
> solr-trunk-542847.patch, solr-trunk-src.patch
>
>
> WHAT:
> As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index.
> This patch is intended to allow multiple cores in Solr which also brings
> multiple indexes capability.
> WHY:
> The current Solr practical wisdom is that one schema - thus one index - is
> most likely to accomodate your indexing needs, using a filter to segregate
> documents if needed. If you really need multiple indexes, deploy multiple web
> applications.
> There are a some use cases however where having multiple indexes or multiple
> cores through Solr itself may make sense.
> Multiple cores:
> Deployment issues within some organizations where IT will resist deploying
> multiple web applications.
> Seamless schema update where you can create a new core and switch to it
> without starting/stopping servers.
> Embedding Solr in your own application (instead of 'raw' Lucene) and
> functionally need to segregate schemas & collections.
> Multiple indexes:
> Multiple language collections where each document exists in different
> languages, analysis being language dependant.
> Having document types that have nothing (or very little) in common with
> respect to their schema, their lifetime/update frequencies or even collection
> sizes.
> HOW:
> The best analogy is to consider that instead of deploying multiple
> web-application, you can have one web-application that hosts more than one
> Solr core. The patch does not change any of the core logic (nor the core
> code); each core is configured & behaves exactly as the one core in 1.2; the
> various caches are per-core & so is the info-bean-registry.
> What the patch does is replace the SolrCore singleton by a collection of
> cores; all the code modifications are driven by the removal of the different
> singletons (the config, the schema & the core).
> Each core is 'named' and a static map (keyed by name) allows to easily manage
> them.
> You declare one servlet filter mapping per core you want to expose in the
> web.xml; this allows easy to access each core through a different url.
> USAGE (example web deployment, patch installed):
> Step0
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml
> monitor.ml
> Will index the 2 documents in solr.xml & monitor.xml
> Step1:
> http://localhost:8983/solr/core0/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core0 index; 2
> documents
> Step2:
> http://localhost:8983/solr/core1/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core1 index; no
> documents
> Step3:
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml
> java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml
> Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1;
> running queries from the admin interface, you can verify indexes have
> different content.
> USAGE (Java code):
> //create a configuration
> SolrConfig config = new SolrConfig("solrconfig.xml");
> //create a schema
> IndexSchema schema = new IndexSchema(config, "schema0.xml");
> //create a core from the 2 other.
> SolrCore core = new SolrCore("core0", "/path/to/index", config, schema);
> //Accessing a core:
> SolrCore core = SolrCore.getCore("core0");
> PATCH MODIFICATIONS DETAILS (per package):
> org.apache.solr.core:
> The heaviest modifications are in SolrCore & SolrConfig.
> SolrCore is the most obvious modification; instead of a singleton, there is a
> static map of cores keyed by names and assorted methods. To retain some
> compatibility, the 'null' named core replaces the singleton for the relevant
> methods, for instance SolrCore.getCore(). One small constraint on the core
> name is they can't contain '/' or '\' avoiding potential url & file path
> problems.
> SolrConfig (& SolrIndexConfig) are now
Hudson build is back to normal: Solr-Nightly #120
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/120/changes
[jira] Commented: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507148
]
Hoss Man commented on SOLR-267:
---
I'm really not a fan of this approach to logging the number of hits via
SolrCore.execute ... this is request handler specific information, it should be
logged by the request handler.
if people really want this type of stuff to be logged by SolrCore execute so
that there's only one log message with the timing info and status and such,
then let's come up with a way for the RequestHandler to explicitly specify in
the SolrQueryResponse the key-val pairs it wants logged (either via new methods
on SOlrQueryResponse, or via apecific name at the top level of the response)
and modify the out-of-the-box request handlers to take advantage of this
instead of...
+String resultLog = " -";
+if (rsp.getValues().size()>1 && rsp.getValues().getVal(1) instanceof
DocList) {
+ int hits = ((DocList) rsp.getValues().getVal(1)).size();
+resultLog = " hits=" + hits;
+}
...something like...
StringBuffer resultLog = new StringBuffer(" -");
Map logables = rsp.getValues().get("loginfo");
for (String k : logables.keySet()) {
resultLog.append(" " + k + "=" + logables.get(k));
}
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
