[jira] Created: (SOLR-1260) support all DocSet operations in DocSlice

2009-07-03 Thread Yonik Seeley (JIRA)
support all DocSet operations in DocSlice
-

 Key: SOLR-1260
 URL: https://issues.apache.org/jira/browse/SOLR-1260
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
Priority: Minor
 Fix For: 1.4


Although Solr does not use Set operations on DocLists, others may try to do so 
since DocList extends DocSet.  We should have tests for this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr

2009-07-03 Thread Chris Male (JIRA)

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

Chris Male updated SOLR-773:


Attachment: SOLR-773-spatial_solr.patch
lucene-spatial-2.9-dev.jar

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SOLR-1260) support all DocSet operations in DocSlice

2009-07-03 Thread Yonik Seeley (JIRA)

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

Yonik Seeley resolved SOLR-1260.


Resolution: Fixed

committed.  (along with a HashDocSet construction bug that could have bitten 
custom code w/ non zero offsets)

 support all DocSet operations in DocSlice
 -

 Key: SOLR-1260
 URL: https://issues.apache.org/jira/browse/SOLR-1260
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
Priority: Minor
 Fix For: 1.4


 Although Solr does not use Set operations on DocLists, others may try to do 
 so since DocList extends DocSet.  We should have tests for this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

2009-07-03 Thread Chris Male (JIRA)

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

Chris Male commented on SOLR-773:
-

I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732.  The performance improvements made by 
the multi-threaded search reduces the time taken to filter 1.2 million 
documents from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.


 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (SOLR-773) Incorporate Local Lucene/Solr

2009-07-03 Thread Chris Male (JIRA)

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

Chris Male edited comment on SOLR-773 at 7/3/09 8:28 AM:
-

I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732 (Note, I have attached the jar built 
using the code in the Lucene issue).  The performance improvements made by the 
multi-threaded search reduces the time taken to filter 1.2 million documents 
from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.


  was (Author: cmale):
I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732.  The performance improvements made by 
the multi-threaded search reduces the time taken to filter 1.2 million 
documents from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.

  
 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 

[jira] Commented: (SOLR-1258) health check file assumed to be in the place where application is started

2009-07-03 Thread Jay (JIRA)

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

Jay commented on SOLR-1258:
---

This is actually not a big issue as you can always use system property to 
specify the directory where you put the file.

 health check file assumed to be in the place where application is started
 -

 Key: SOLR-1258
 URL: https://issues.apache.org/jira/browse/SOLR-1258
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.4
 Environment: Mac
Reporter: Jay
Priority: Minor
 Fix For: 1.4

   Original Estimate: 5h
  Remaining Estimate: 5h

 The following element gives admin the ability to enable/disable a solr 
 instance without taking it down
   admin
 defaultQuerysolr/defaultQuery
 !-- configure a healthcheck file for servers behind a loadbalancer
 --
 healthcheck type=fileserver-enabled/healthcheck
   /admin
 There is a problem with where the file 'server-enabled' is placed. Currently 
 it appears that file is relative to the place where the server is stared. 
 This causes trouble to deployment since theoretically the server could be 
 started anywhere. My suggestion is to have the file relative to solr home so 
 that it does not dependent on where the server is started.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SOLR-1257) action.jsp does not compile

2009-07-03 Thread Jay (JIRA)

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

Jay updated SOLR-1257:
--

Description: 
action.jsp failed to compile because of imcompatible class Logger used in 
action.jsp and SolrConfig.java. This can be produced in the following steps:

1. in configuration file solrconfig.xml, uncomment the following element (at 
the end of the file)
 !-- configure a healthcheck file for servers behind a loadbalancer
--
healthcheck type=fileserver-enabled/healthcheck
2. start solr
3. go to 
 http://localhost:8983/solr/admin
4. click on the link tagged Enable, which essential make this request
http://localhost:8983/solr/admin/action.jsp?action=Enable

you will see this error page:

HTTP ERROR: 500

PWC6033: Unable to compile class for JSP

PWC6197: An error occurred at line: 28 in the jsp file: /admin/action.jsp
PWC6199: Generated servlet error:
Type mismatch: cannot convert from Logger to Logger

PWC6197: An error occurred at line: 28 in the jsp file: /admin/action.jsp
PWC6199: Generated servlet error:
The method log(Level, String) is undefined for the type Logger



org.apache.jasper.JasperException: PWC6033: Unable to compile class for JSP

PWC6197: An error occurred at line: 28 in the jsp file: /admin/action.jsp
PWC6199: Generated servlet error:
Type mismatch: cannot convert from Logger to Logger

PWC6197: An error occurred at line: 28 in the jsp file: /admin/action.jsp
PWC6199: Generated servlet error:
The method log(Level, String) is undefined for the type Logger


at 
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:94)
at 
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:267)
at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:332)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:389)
at 
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:579)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:464)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:358)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:273)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:295)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
RequestURI=/solr/admin/action.jsp

Powered by Jetty://



tried it with the latest nightly build and got the same result.



  was:
action.jsp failed to compile because of imcompatible class Logger used in 
action.jsp and SolrConfig.java. This can be produced in the following steps:

1. in configuration file solrconfig.xml, uncomment the following element (at 
the end of the file)
 !-- configure a healthcheck 

[jira] Assigned: (SOLR-1256) show CharFilters in analysis.jsp

2009-07-03 Thread Koji Sekiguchi (JIRA)

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

Koji Sekiguchi reassigned SOLR-1256:


Assignee: Koji Sekiguchi

 show CharFilters in analysis.jsp
 

 Key: SOLR-1256
 URL: https://issues.apache.org/jira/browse/SOLR-1256
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
Assignee: Koji Sekiguchi

 CharFilters aren't currently shown in analysis.jsp output

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.