date:20080721

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

Noble Paul updated SOLR-561:

Attachment: SOLR-561.patch

This patch is to
* sync with the trunk (SOLR-638 changes)
* uses java1.4 _ScheduledExcecutorService_ instead of timer
* _SolrCore.close()_ is done in a refcounted way

Solr replication by Solr (for windows also)
---

Key: SOLR-561
URL: https://issues.apache.org/jira/browse/SOLR-561
Project: Solr
Issue Type: New Feature
Components: replication
Affects Versions: 1.3
Environment: All
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Attachments: deletion_policy.patch, SOLR-561-core.patch,
SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch

The current replication strategy in solr involves shell scripts . The
following are the drawbacks with the approach
* It does not work with windows
* Replication works as a separate piece not integrated with solr.
* Cannot control replication from solr admin/JMX
* Each operation requires manual telnet to the host
Doing the replication in java has the following advantages
* Platform independence
* Manual steps can be completely eliminated. Everything can be driven from
solrconfig.xml .
** Adding the url of the master in the slaves should be good enough to enable
replication. Other things like frequency of
snapshoot/snappull can also be configured . All other information can be
automatically obtained.
* Start/stop can be triggered from solr/admin or JMX
* Can get the status/progress while replication is going on. It can also
abort an ongoing replication
* No need to have a login into the machine
This issue can track the implementation of solr replication in java

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

Re: solr admin look

2008-07-21 Thread Mark Miller


Andrew Savory wrote:

Hi,

2008/7/20 Shalin Shekhar Mangar [EMAIL PROTECTED]:

  

+1 for a new logo. It's a new release, let's have a new logo too! First step
is to decide which one of these is more Solr-ish.



There was extensive discussion and opinions expressed last time the
logo issue came up, but no firm decision made. Can I suggest a quick
vote, based on those currently in JIRA, with the one taking a simple
majority of votes winning? Otherwise, I suspect it'll never change.
  
Might be a good idea to do just do majority instead. I was hoping to do 
a 1-5 rating for each, because that way you can influence with more than 
just your top vote - that may have been hoping there is more interest in 
this than there really is though.

Or, someone with commit access just scratch that itch do-ocracy style,
and whoever commits the new logo gets to decide? ;-)
  
If this is the route to go, unofficially, based on a few people I talked 
to, people seem to think the ones with the thin black lines for 'solr' 
and the gradient suns in the middle look the most professional.

[jira] Updated: (SOLR-486) Support binary formats for QueryresponseWriter


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

Noble Paul updated SOLR-486:


Attachment: (was: SOLR-486-iterator.patch)

 Support binary formats for QueryresponseWriter
 --

 Key: SOLR-486
 URL: https://issues.apache.org/jira/browse/SOLR-486
 Project: Solr
  Issue Type: Improvement
  Components: clients - java, search
Reporter: Noble Paul
Assignee: Yonik Seeley
 Fix For: 1.3

 Attachments: SOLR-486-iterator.patch, SOLR-486-iterator.patch, 
 SOLR-486.patch, solr-486.patch, SOLR-486.patch, SOLR-486.patch, 
 SOLR-486.patch, SOLR-486.patch, SOLR-486.patch, SOLR-486.patch, 
 SOLR-486.patch, SOLR-486.patch


 QueryResponse writer only allows text data to be written.
 So it is not possible to implement a binary protocol . Create another 
 interface which has a method 
 write(OutputStream os, SolrQueryRequest request, SolrQueryResponse response)

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

[jira] Updated: (SOLR-486) Support binary formats for QueryresponseWriter


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

Noble Paul updated SOLR-486:


Attachment: SOLR-486-iterator.patch

name in namedlist written as extern string

 Support binary formats for QueryresponseWriter
 --

 Key: SOLR-486
 URL: https://issues.apache.org/jira/browse/SOLR-486
 Project: Solr
  Issue Type: Improvement
  Components: clients - java, search
Reporter: Noble Paul
Assignee: Yonik Seeley
 Fix For: 1.3

 Attachments: SOLR-486-iterator.patch, SOLR-486-iterator.patch, 
 SOLR-486.patch, solr-486.patch, SOLR-486.patch, SOLR-486.patch, 
 SOLR-486.patch, SOLR-486.patch, SOLR-486.patch, SOLR-486.patch, 
 SOLR-486.patch, SOLR-486.patch


 QueryResponse writer only allows text data to be written.
 So it is not possible to implement a binary protocol . Create another 
 interface which has a method 
 write(OutputStream os, SolrQueryRequest request, SolrQueryResponse response)

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

[jira] Commented: (SOLR-561) Solr replication by Solr (for windows also)

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

Yonik Seeley commented on SOLR-561:
---

I haven't had a chance to check out the latest patch, but it sounds like
SolrCore.close() is done in a refcounted way is a generic multi-core change
that is potentially sticky enough that it deserves it's own JIRA issue.

Solr replication by Solr (for windows also)
---

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

[jira] Resolved: (SOLR-593) Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data directory


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

Yonik Seeley resolved SOLR-593.
---

Resolution: Fixed

committed.

 Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data 
 directory
 --

 Key: SOLR-593
 URL: https://issues.apache.org/jira/browse/SOLR-593
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: Koji Sekiguchi
 Fix For: 1.3

 Attachments: SOLR-593.patch


 The thread dump is:
 main prio=6 tid=0x003f81d8 nid=0x10e4 in Object.wait() 
 [0x0006f000..0x0006fc20]
 at java.lang.Object.wait(Native Method)
 - waiting on 0x23dd0188 (a java.lang.Object)
 at java.lang.Object.wait(Object.java:474)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:685)
 - locked 0x23dd0188 (a java.lang.Object)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:624)
 at 
 org.apache.solr.handler.component.QueryElevationComponent.inform(QueryElevationComponent.java:185)
 - locked 0x23e51ee0 (a java.util.WeakHashMap)
 at 
 org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:264)
 at org.apache.solr.core.SolrCore.init(SolrCore.java:396)
 - locked 0x27b44b60 (a java.lang.Class)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:90)
 at 
 org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
 at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
 at 
 org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594)
 at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
 at 
 org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218)
 at 
 org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500)
 at 
 org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
 at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
 at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161)
 at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
 at 
 org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
 at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
 at org.mortbay.jetty.Server.doStart(Server.java:210)
 at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
 at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.mortbay.start.Main.invokeMain(Main.java:183)
 at org.mortbay.start.Main.start(Main.java:497)
 at org.mortbay.start.Main.main(Main.java:115)
 The cause is that accessing reader during SolrCoreAware.inform(). Shalin 
 pointed out same thing at:
 http://www.nabble.com/Accessing-IndexReader-during-core-initialization-hangs-init-td17259235.html#a17259235

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

[jira] Commented: (SOLR-561) Solr replication by Solr (for windows also)

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

Noble Paul commented on SOLR-561:
-

Yes , we may need another issue to track it. Directly calling _Solr.close()_
can cause exceptions on in-flight requests

Solr replication by Solr (for windows also)
---

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

[jira] Created: (SOLR-640) spellcheck reference leaks

spellcheck reference leaks
--

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


The spellcheck component doesn't decref it's searcher when it builds the index, 
and it will hang around forever.

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

[jira] Assigned: (SOLR-640) spellcheck reference leaks


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

Yonik Seeley reassigned SOLR-640:
-

Assignee: Yonik Seeley

 spellcheck reference leaks
 --

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

 The spellcheck component doesn't decref it's searcher when it builds the 
 index, and it will hang around forever.

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

[jira] Updated: (SOLR-640) spellcheck reference leaks

2008-07-21 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-640:
---

Attachment: SOLR-640.patch

IndexBasedSpellChecker decrefs searcher in a finally block.

 spellcheck reference leaks
 --

 Key: SOLR-640
 URL: https://issues.apache.org/jira/browse/SOLR-640
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Attachments: SOLR-640.patch


 The spellcheck component doesn't decref it's searcher when it builds the 
 index, and it will hang around forever.

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

Re: Too many open files with DirectUpdateHandlerOptimizeTest

2008-07-21 Thread Shalin Shekhar Mangar

Yes, it happens on a fresh checkout too.

cat /proc/sys/fs/file-max gives 204979 on my box. The test which fails is
testOptimize.

I increased the file handle limit to 4096 but it still fails. Then I
increased it to 16384 and the test passed.

On Mon, Jul 21, 2008 at 2:58 AM, Yonik Seeley [EMAIL PROTECTED] wrote:

 Does it happen on a fresh checkout?
 I use windows (and cygwin for the familiar command line interface),
 which has higher limits.

 Also watch out for the system-wide limit:
 http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

 If it happens with a fresh checkout, perhaps we could lower the merge
 factor for that test.

 -Yonik

 On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
 [EMAIL PROTECTED] wrote:
  Hi,
 
  The DirectUpdateHandlerOptimizeTest fails on my local box due to too many
  open files. The nightly build does not fail so I'm assuming it must be
  something specific to my setup. Has anyone else seen this problem on
 their
  local environment?
 
  ulimit -n gives 1024 on my Ubuntu Hardy Heron.
 
  testcase
 classname=org.apache.solr.update.DirectUpdateHandlerOptimizeTest
  name=testOptimize time=5.687
 error message=java.io.FileNotFoundException:
 
 /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
  (Too many open files)
  type=java.lang.RuntimeExceptionjava.lang.RuntimeException:
  java.io.FileNotFoundException:
 
 /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
  (Too many open files)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
 at
 
 org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
 at
 
 org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
  Caused by: java.io.FileNotFoundException:
 
 /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
  (Too many open files)
 at java.io.RandomAccessFile.open(Native Method)
 at
 java.io.RandomAccessFile.lt;initgt;(RandomAccessFile.java:212)
 at
 
 org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.lt;initgt;(FSDirectory.java:539)
 at
 
 org.apache.lucene.store.FSDirectory$FSIndexInput.lt;initgt;(FSDirectory.java:569)
 at
  org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
 at
 
 org.apache.lucene.index.TermInfosReader.lt;initgt;(TermInfosReader.java:80)
 at
  org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
 at
 org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
 at
 org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
 at
 
 org.apache.lucene.index.MultiSegmentReader.lt;initgt;(MultiSegmentReader.java:55)
 at
 
 org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
 at
 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
 at
 
 org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
 at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
 at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
 at
 
 org.apache.solr.search.SolrIndexSearcher.lt;initgt;(SolrIndexSearcher.java:93)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
  /error
   /testcase
 
 
  --
  Regards,
  Shalin Shekhar Mangar.
 




-- 
Regards,
Shalin Shekhar Mangar.

[jira] Updated: (SOLR-640) spellcheck reference leaks


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

Yonik Seeley updated SOLR-640:
--

Attachment: SOLR-640.patch

This patch passes in a SolrIndexSearcher to build() rather than obtaining one 
from the core.  In the context of a request, the searcher should always be 
obtained from that request (it may be a specially constructed one for warming, 
etc).

 spellcheck reference leaks
 --

 Key: SOLR-640
 URL: https://issues.apache.org/jira/browse/SOLR-640
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Attachments: SOLR-640.patch, SOLR-640.patch


 The spellcheck component doesn't decref it's searcher when it builds the 
 index, and it will hang around forever.

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

[jira] Updated: (SOLR-350) Manage Multiple SolrCores

2008-07-21 Thread Henri Biestro (JIRA)

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

Henri Biestro updated SOLR-350:
---

Attachment: solr-350-properties.patch

This patch (solr-350-properties.patch) implements '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.

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

The code itself refactored some of DOMUtil (the ant based property
substitution) into one added class (PropertyMap PropertyMap.Evaluator).
The PropertyMap are chained (one link chain between core to multicore map);
those maps are owned by each core's ResourceLoader.
Config is modified a little to accomodate delaying specializing property
expansions.

Reviews comments more than welcome.
PS: Should we open a new issue or re-open this one to track progress ?

Manage Multiple SolrCores
-

Key: SOLR-350
URL: https://issues.apache.org/jira/browse/SOLR-350
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 1.3

Attachments: SOLR-350-jsp-fixes.patch, SOLR-350-jsp-fixes.patch,
SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch,
SOLR-350-Naming.patch, SOLR-350-Naming.patch, solr-350-properties.patch,
SOLR-350-RemoveStatic.patch, solr-350.patch, solr-350.patch, solr-350.patch,
solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch,
solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch,
solr-350.patch, solr-350.patch, solr-350.patch

In SOLR-215, we enabled support for more then one SolrCore - but there is no
way to use them yet.
We need to make some interface to manage, register, modify avaliable SolrCores

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

[jira] Created: (SOLR-642) ShardResponse IllegalAccessError

2008-07-21 Thread Georgios Stamatis (JIRA)

ShardResponse IllegalAccessError


 Key: SOLR-642
 URL: https://issues.apache.org/jira/browse/SOLR-642
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: Georgios Stamatis
 Fix For: 1.3


As ShardResponse is package protected, any class that makes extention 
of a search component has access issues due to different classloaders.

java.lang.IllegalAccessError: tried to access class
org.apache.solr.handler.component.ShardResponse from class
org.apache.solr.handler.component.MyComponent

The proposed solution (see Yonik answer on solr-dev) :
 1. A public scope for the ShardResponse (a class of it's own)
 2. Switch public members to private and use getters for the search components

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

[jira] Updated: (SOLR-642) ShardResponse IllegalAccessError

2008-07-21 Thread Georgios Stamatis (JIRA)


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

Georgios Stamatis updated SOLR-642:
---

Attachment: ShardResponse.patch

Should fix this issue

 ShardResponse IllegalAccessError
 

 Key: SOLR-642
 URL: https://issues.apache.org/jira/browse/SOLR-642
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: Georgios Stamatis
 Fix For: 1.3

 Attachments: ShardResponse.patch


 As ShardResponse is package protected, any class that makes extention 
 of a search component has access issues due to different classloaders.
 java.lang.IllegalAccessError: tried to access class
 org.apache.solr.handler.component.ShardResponse from class
 org.apache.solr.handler.component.MyComponent
 The proposed solution (see Yonik answer on solr-dev) :
  1. A public scope for the ShardResponse (a class of it's own)
  2. Switch public members to private and use getters for the search components

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

Re: ShardResponse IllegalAccessError

2008-07-21 Thread Georgios Stamatis


Yonik Seeley wrote:

On Thu, Jul 17, 2008 at 8:45 AM, Georgios Stamatis
[EMAIL PROTECTED] wrote:
  

Exact, ShardResponse is package protected. By passing it to public will
solve
my problem (create a Search Components in an external jar file in the ./lib
directory).
If you want to use getters (the solution most appropriate in my opinion)
there will be many Solr components (ex. DebugComponent) that will
be impacted, because they make access to ShardResponse class public members.
Shall I propose a patch through JIRA that fixes the whole problem public
access and
the getters in the Solr Search Components?



Yes, please do.

-Yonik

  

O.K.

I opened SOLR-642 with patch file attached

I changed SharedResponse scope to public with private members (search 
components use getters)


Thanks,

Georgios Stamatis

[jira] Updated: (SOLR-641) expose EmbeddedSolrServer response parsing


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

Ryan McKinley updated SOLR-641:
---

Attachment: SOLR-641-embedded-parsing.patch

this patch switches from using the XML parser to the BinaryResponseParser in 
embedded solr.
It also moves all the logic to a function that can be easily upgraded in the 
future:
{code:java}
 NamedListObject getParsedResponse( SolrQueryRequest req, SolrQueryResponse 
rsp )
{code}

 expose EmbeddedSolrServer response parsing
 --

 Key: SOLR-641
 URL: https://issues.apache.org/jira/browse/SOLR-641
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.3
Reporter: Ryan McKinley
Priority: Minor
 Attachments: SOLR-641-embedded-parsing.patch


 Currently the EmbeddedSolrServer writes the response to XML (a string) then 
 parses it so that it has an equivolent response to if it were passed around 
 via HTTP.  We should:
 * make this more efficient, or at least refactor so it is easy to make it 
 more efficient in the future
 * expose the parsing functions, so other components could use it directly.

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

[jira] Assigned: (SOLR-641) expose EmbeddedSolrServer response parsing


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

Ryan McKinley reassigned SOLR-641:
--

Assignee: Ryan McKinley

 expose EmbeddedSolrServer response parsing
 --

 Key: SOLR-641
 URL: https://issues.apache.org/jira/browse/SOLR-641
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-641-embedded-parsing.patch


 Currently the EmbeddedSolrServer writes the response to XML (a string) then 
 parses it so that it has an equivolent response to if it were passed around 
 via HTTP.  We should:
 * make this more efficient, or at least refactor so it is easy to make it 
 more efficient in the future
 * expose the parsing functions, so other components could use it directly.

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

[jira] Commented: (SOLR-620) Velocity Response Writer


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

Ryan McKinley commented on SOLR-620:


Looking at a recent version of this, it seems best if we can reuse the 
NamedListObject parsing from solrj rather then have the velocity writer add 
helper functions to access parts of the response.

I just posted SOLR-641 to expose this parsing form EmbeddedSolrServer

 Velocity Response Writer
 

 Key: SOLR-620
 URL: https://issues.apache.org/jira/browse/SOLR-620
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch


 Add a Velocity - http://velocity.apache.org - response writer, making it 
 possible to generate a decent search UI straight from Solr itself.  Designed 
 to work standalone or in conjunction with the JSON response writer (or 
 SolrJS) for Ajaxy things.

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

Defining properties/using expressions in {multicore, config, schema} files

2008-07-21 Thread Henrib


I posted a new patch in solr-350 (solr-350-properties.patch) that allows
defining properties in multicore.xml and using them in expressions in config
 schema files. This brings a lot of flexibility to configuration.

I apologize for doubling the JIRA post; Solr-350 being closed, I just wanted
to ensure anyone interested in the feature could try/comment/review/etc.

-- 
View this message in context: 
http://www.nabble.com/Defining-properties-using-expressions-in-%7Bmulticore%2C-config%2C-schema%7D-files-tp18573791p18573791.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Defining properties/using expressions in {multicore, config, schema} files

2008-07-21 Thread Mike Klaas



On 21-Jul-08, at 10:48 AM, Henrib wrote:



I posted a new patch in solr-350 (solr-350-properties.patch) that  
allows
defining properties in multicore.xml and using them in expressions  
in config

 schema files. This brings a lot of flexibility to configuration.

I apologize for doubling the JIRA post; Solr-350 being closed, I  
just wanted
to ensure anyone interested in the feature could try/comment/review/ 
etc.


Perhaps opening a new issue would be best?

cheers,
-Mike

[jira] Updated: (SOLR-84) New Solr logo?

2008-07-21 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  updated SOLR-84:
--

Attachment: solr.svg

Some ideas for a black  white version of the logo

 New Solr logo?
 --

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, 
 logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-f.jpg, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-nick.gif, solr.jpg, solr.svg, sslogo-solr-flare.jpg, sslogo-solr.jpg, 
 sslogo-solr2-flare.jpg, sslogo-solr2.jpg, sslogo-solr3.jpg


 Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) 
 sarraux-dessous.ch) has reworked his logo proposal to be more solar.
 This can either be the start of a logo contest, or if people like it we could 
 adopt it. The gradients can make it a bit hard to integrate, not sure if this 
 is really a problem.
 WDYT?

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

Re: solr admin look

2008-07-21 Thread Andrzej Bialecki


Mark Miller wrote:

Andrew Savory wrote:

Hi,

2008/7/20 Shalin Shekhar Mangar [EMAIL PROTECTED]:

 
+1 for a new logo. It's a new release, let's have a new logo too! 
First step

is to decide which one of these is more Solr-ish.



There was extensive discussion and opinions expressed last time the
logo issue came up, but no firm decision made. Can I suggest a quick
vote, based on those currently in JIRA, with the one taking a simple
majority of votes winning? Otherwise, I suspect it'll never change.
  
Might be a good idea to do just do majority instead. I was hoping to do 
a 1-5 rating for each, because that way you can influence with more than 
just your top vote - that may have been hoping there is more interest in 
this than there really is though.

Or, someone with commit access just scratch that itch do-ocracy style,
and whoever commits the new logo gets to decide? ;-)
  
If this is the route to go, unofficially, based on a few people I talked 
to, people seem to think the ones with the thin black lines for 'solr' 
and the gradient suns in the middle look the most professional.


Let me quote what I wrote some time ago during the same discussion on 
Mahout logo:



I recall some of the discussions I had with a graphical designer on
my team ... His points regarding a logo design (those that I can
still remember!):

* it should convey one or few concepts, and do it well - i.e. don't
try to communicate too many messages

* it should be meaningful and acceptable for the target audience, or
abstract enough that it doesn't matter. I'm not sure how the IBM-type
suits would react to the beach-ball if it were to appear in the
documentation of their product ;)

* it should be easy to reduce to black  white (or a fixed number of
colors) without the loss of meaning. It should be readable when
printed in reverse.

* elements should be readable at various magnifications, or it should
be possible to remove some elements (simplify) and still preserve the
distinguishing features. Think of the logo at a poster size, and at a
favicon.ico size. There could be two versions of the logo for
different sizes, where the focus is on different logo element - for
example, the elephant, or the rubik cube with a stylized M.

... etc, etc, he could go on for hours .. ;)



Based on this:

* IMHO the simpler the better, overloaded logos don't look professional 
IMHO.


* I would prefer the designs based on simple straight lines[1] e.g. 
logo-grid.jpg, with a blackwhite option that replaces the gradient with 
two-three concentric circles of varying width. I attached an SVG 
rendering of this idea to the JIRA.


* a simple symbol for Solr inside, e.g. the stylized sun with spokes, 
or the black  white version of it. This could be put in places where it 
needs to be used often, or as a pure symbol, and it would use too much 
space with text.


[1] Off-topic, but funny: just today I told my wife that I somehow 
dislike driving through a particular district of Warsaw, and she said 
it's probably because streets there don't follow a grid pattern - and I 
had to admit she was right :)


--
Best regards,
Andrzej Bialecki 
 ___. ___ ___ ___ _ _   __
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com

SolrDocument serializable?

2008-07-21 Thread Ryan McKinley

How do you all feel about forcing the fields in SolrDocument to be  
Serializable?

from
  private MapString,Object _fields = null;
to:
  private MapString,Serializable _fields = null;

likewise with SolrInputField?
from:
  Object value = null;
to
  Serializable value = null;

Everything we are pumping into these fields is serializable.  The only  
catch is that List/Map are not Serializable, but the implementations  
we use are.


thoughts?

[jira] Created: (SOLR-643) Improve the look of the solr admin pages

2008-07-21 Thread Mark Miller (JIRA)

Improve the look of the solr admin pages


 Key: SOLR-643
 URL: https://issues.apache.org/jira/browse/SOLR-643
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Mark Miller
Priority: Minor
 Attachments: solr-admin.css, SolrAdmin.jpg

My recent poll of solr users shows that people are ready for a solr face lift. 
The majority of of those who answered were looking for an improvement, while a 
slightly lesser number voted for a complete redesign. Lets not shoot for the 
moon though- lets see if we can't at least just improve things a bit to start.

I am not a graphics design dude - but to get things started, here is a new 
solr-admin.css file that I think is at least an improvement to what we have. My 
hope is that some talented people out there will show up my lowly skills, but 
if those people can not be found, I think even a slow move in a better 
direction is worthwhile.

Comments, criticisms, discussion - please! I am willing to pitch in in whatever 
way I can to help to improve this UI, so speak up if you have any ideas.

- Mark

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

[jira] Updated: (SOLR-643) Improve the look of the solr admin pages

2008-07-21 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-643:
-

Attachment: SolrAdmin.jpg

 Improve the look of the solr admin pages
 

 Key: SOLR-643
 URL: https://issues.apache.org/jira/browse/SOLR-643
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Mark Miller
Priority: Minor
 Attachments: solr-admin.css, SolrAdmin.jpg


 My recent poll of solr users shows that people are ready for a solr face 
 lift. The majority of of those who answered were looking for an improvement, 
 while a slightly lesser number voted for a complete redesign. Lets not shoot 
 for the moon though- lets see if we can't at least just improve things a bit 
 to start.
 I am not a graphics design dude - but to get things started, here is a new 
 solr-admin.css file that I think is at least an improvement to what we have. 
 My hope is that some talented people out there will show up my lowly skills, 
 but if those people can not be found, I think even a slow move in a better 
 direction is worthwhile.
 Comments, criticisms, discussion - please! I am willing to pitch in in 
 whatever way I can to help to improve this UI, so speak up if you have any 
 ideas.
 - Mark

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

[jira] Resolved: (SOLR-612) solrj should (optionally?) use POST for queries


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

Yonik Seeley resolved SOLR-612.
---

Resolution: Fixed

Lars, I've committed your version.
Thanks guys!

 solrj should (optionally?) use POST for queries
 ---

 Key: SOLR-612
 URL: https://issues.apache.org/jira/browse/SOLR-612
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.3
 Environment: all
Reporter: Brian Whitman
 Fix For: 1.3

 Attachments: SOLR-612.patch, solrj-post.diff


 Can we make solrj always send post queries (or have it be an init-able 
 option)? 
 Jetty has some problems (in quotes because I don't know if it's really a 
 problem) with long queries over GET:
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg09457.html
 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200804.mbox/[EMAIL 
 PROTECTED]
 Tiny patch attached that changes it and doesn't cause an exception on long 
 queries in Jetty w/ solrj.

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

[jira] Resolved: (SOLR-303) Distributed Search over HTTP


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

Yonik Seeley resolved SOLR-303.
---

Resolution: Fixed

Closing this issue (finally!).  Specific bugs or improvements can get their own 
new issues.
Thanks to everyone who contributed to this!

 Distributed Search over HTTP
 

 Key: SOLR-303
 URL: https://issues.apache.org/jira/browse/SOLR-303
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Sharad Agarwal
Assignee: Yonik Seeley
 Fix For: 1.3

 Attachments: distributed.patch, distributed.patch, distributed.patch, 
 distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
 distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
 distributed.patch, distributed_add_tests_for_intended_behavior.patch, 
 distributed_facet_count_bugfix.patch, distributed_pjaol.patch, 
 fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, 
 fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, 
 fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, 
 solr-dist-faceting-non-ascii-all.patch


 Searching over multiple shards and aggregating results.
 Motivated by http://wiki.apache.org/solr/DistributedSearch

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

[jira] Updated: (SOLR-643) Improve the look of the solr admin pages

2008-07-21 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-643:
-

Attachment: orig-solr-admin-page.jpg

 Improve the look of the solr admin pages
 

 Key: SOLR-643
 URL: https://issues.apache.org/jira/browse/SOLR-643
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Mark Miller
Priority: Minor
 Attachments: orig-solr-admin-page.jpg, solr-admin.css, SolrAdmin.jpg


 My recent poll of solr users shows that people are ready for a solr face 
 lift. The majority of of those who answered were looking for an improvement, 
 while a slightly lesser number voted for a complete redesign. Lets not shoot 
 for the moon though- lets see if we can't at least just improve things a bit 
 to start.
 I am not a graphics design dude - but to get things started, here is a new 
 solr-admin.css file that I think is at least an improvement to what we have. 
 My hope is that some talented people out there will show up my lowly skills, 
 but if those people can not be found, I think even a slow move in a better 
 direction is worthwhile.
 Comments, criticisms, discussion - please! I am willing to pitch in in 
 whatever way I can to help to improve this UI, so speak up if you have any 
 ideas.
 - Mark

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

[jira] Resolved: (SOLR-642) ShardResponse IllegalAccessError


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

Yonik Seeley resolved SOLR-642.
---

Resolution: Fixed

I just committed this.  Thanks!

 ShardResponse IllegalAccessError
 

 Key: SOLR-642
 URL: https://issues.apache.org/jira/browse/SOLR-642
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: Georgios Stamatis
 Fix For: 1.3

 Attachments: ShardResponse.patch


 As ShardResponse is package protected, any class that makes extention 
 of a search component has access issues due to different classloaders.
 java.lang.IllegalAccessError: tried to access class
 org.apache.solr.handler.component.ShardResponse from class
 org.apache.solr.handler.component.MyComponent
 The proposed solution (see Yonik answer on solr-dev) :
  1. A public scope for the ShardResponse (a class of it's own)
  2. Switch public members to private and use getters for the search components

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

[jira] Updated: (SOLR-644) Increase maximum POST size in example Jetty configuration


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

Lars Kotthoff updated SOLR-644:
---

Attachment: SOLR-644.patch

Patch changing the maximum POST size to 100 bytes. Tested with the bundled 
Jetty version 6.1.3.

 Increase maximum POST size in example Jetty configuration
 -

 Key: SOLR-644
 URL: https://issues.apache.org/jira/browse/SOLR-644
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: Jetty 6.1.3
Reporter: Lars Kotthoff
Priority: Minor
 Attachments: SOLR-644.patch


 The default maximum POST size for Jetty is 200 KB, which might be 
 insufficient when dealing with shards and sorting/faceting (cf. 
 https://issues.apache.org/jira/browse/SOLR-303?focusedCommentId=12614708#action_12614708).
  The example Jetty configuration should increase the maximum POST size to 
 make this problem less likely to occur.

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

[jira] Resolved: (SOLR-623) snapcleaner fails on osx for -D


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

Yonik Seeley resolved SOLR-623.
---

Resolution: Fixed

Committed.  Thanks Trey!

 snapcleaner fails on osx for -D
 ---

 Key: SOLR-623
 URL: https://issues.apache.org/jira/browse/SOLR-623
 Project: Solr
  Issue Type: Bug
  Components: replication
Affects Versions: 1.2, 1.3
 Environment:  9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53 
 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 i386
Reporter: Richard Trey Hyde
Priority: Critical
 Fix For: 1.3


 {quote}
 removing snapshot /Users/trey/solr.home/data/snapshot.20080701175730
 ps: illegal option -- f
 usage: ps [-AaCcEefhjlMmrSTvwXx] [-O fmt | -o fmt] [-G gid[,gid...]]
   [-u]
   [-p pid[,pid...]] [-t tty[,tty...]] [-U user[,user...]]
ps [-L]
 {quote}
 MacOSX does not support the -f option to show all the command line arguments. 
  This is the default behavior for ps (on OSX, but can be supressed with -c).
 It also doesn't much like -wwwu $user.  Wants -www -U $user. 

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

[jira] Commented: (SOLR-644) Increase maximum POST size in example Jetty configuration

2008-07-21 Thread Noble Paul നോബിള്‍ नोब्ळ्


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

Yonik Seeley commented on SOLR-644:
---

Are there any downsides to this configuration that anyone is aware of?
Does it in any way affect the resources needed to handle a small POST?

 Increase maximum POST size in example Jetty configuration
 -

 Key: SOLR-644
 URL: https://issues.apache.org/jira/browse/SOLR-644
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: Jetty 6.1.3
Reporter: Lars Kotthoff
Priority: Minor
 Attachments: SOLR-644.patch


 The default maximum POST size for Jetty is 200 KB, which might be 
 insufficient when dealing with shards and sorting/faceting (cf. 
 https://issues.apache.org/jira/browse/SOLR-303?focusedCommentId=12614708#action_12614708).
  The example Jetty configuration should increase the maximum POST size to 
 make this problem less likely to occur.

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

Re: svn commit: r678624 - /lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java

why do we need a serialize/deserialize for EmbeddedSolrServer? Why
can't we just return the Namedlist directly?

On Tue, Jul 22, 2008 at 8:47 AM,  [EMAIL PROTECTED] wrote:
 Author: ryan
 Date: Mon Jul 21 20:17:13 2008
 New Revision: 678624

 URL: http://svn.apache.org/viewvc?rev=678624view=rev
 Log:
 SOLR-641 -- use the binary parser for embeded solr server

 Modified:

 lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java

 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=678624r1=678623r2=678624view=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 Jul 21 20:17:13 2008
 @@ -17,6 +17,8 @@

  package org.apache.solr.client.solrj.embedded;

 +import java.io.ByteArrayInputStream;
 +import java.io.ByteArrayOutputStream;
  import java.io.IOException;
  import java.io.StringReader;
  import java.io.StringWriter;
 @@ -25,15 +27,16 @@
  import org.apache.solr.client.solrj.SolrRequest;
  import org.apache.solr.client.solrj.SolrServer;
  import org.apache.solr.client.solrj.SolrServerException;
 +import org.apache.solr.client.solrj.impl.BinaryResponseParser;
  import org.apache.solr.client.solrj.impl.XMLResponseParser;
  import org.apache.solr.common.SolrException;
  import org.apache.solr.common.params.CommonParams;
 -import org.apache.solr.common.params.DefaultSolrParams;
  import org.apache.solr.common.params.ModifiableSolrParams;
  import org.apache.solr.common.params.SolrParams;
  import org.apache.solr.common.util.NamedList;
  import org.apache.solr.core.MultiCore;
  import org.apache.solr.core.SolrCore;
 +import org.apache.solr.request.BinaryResponseWriter;
  import org.apache.solr.request.QueryResponseWriter;
  import org.apache.solr.request.SolrQueryRequest;
  import org.apache.solr.request.SolrQueryResponse;
 @@ -51,13 +54,12 @@
  */
  public class EmbeddedSolrServer extends SolrServer
  {
 -  protected ModifiableSolrParams _invariantParams;
 -  protected ResponseParser _processor;

   protected final MultiCore multicore; // either multicore
   protected final SolrCore core; // or single core
 -  protected final SolrRequestParsers parser;
   protected final String coreName;  // use MultiCore registry
 +
 +  private final SolrRequestParsers _parser;

   public EmbeddedSolrServer( SolrCore core )
   {
 @@ -67,7 +69,8 @@
 this.core = core;
 this.multicore = null;
 this.coreName = null;
 -this.parser = init();
 +
 +_parser = new SolrRequestParsers( null );
   }

   public EmbeddedSolrServer(  MultiCore multicore, String coreName )
 @@ -82,20 +85,10 @@
 if( c == null ) {
   throw new RuntimeException( Unknown core: +coreName );
 }
 -this.parser = init();
 -  }
 -
 -  private SolrRequestParsers init()
 -  {
 -_processor = new XMLResponseParser();

 -_invariantParams = new ModifiableSolrParams();
 -_invariantParams.set( CommonParams.WT, _processor.getWriterType() );
 -_invariantParams.set( CommonParams.VERSION, 2.2 );
 -
 -return new SolrRequestParsers( null );
 +_parser = new SolrRequestParsers( null );
   }
 -
 +
   @Override
   public NamedListObject request(SolrRequest request) throws 
 SolrServerException, IOException
   {
 @@ -118,9 +111,6 @@
 if( params == null ) {
   params = new ModifiableSolrParams();
 }
 -if( _invariantParams != null ) {
 -  params = new DefaultSolrParams( _invariantParams, params );
 -}

 // Extract the handler from the path or params
 SolrRequestHandler handler = core.getRequestHandler( path );
 @@ -145,7 +135,7 @@
 }

 try {
 -  SolrQueryRequest req = parser.buildRequestFrom( core, params, 
 request.getContentStreams() );
 +  SolrQueryRequest req = _parser.buildRequestFrom( core, params, 
 request.getContentStreams() );
   req.getContext().put( path, path );
   SolrQueryResponse rsp = new SolrQueryResponse();
   core.execute( handler, req, rsp );
 @@ -154,13 +144,9 @@
   }

   // Now write it out
 -  QueryResponseWriter responseWriter = core.getQueryResponseWriter(req);
 -  StringWriter out = new StringWriter();
 -  responseWriter.write(out, req, rsp);
 -  // TODO: writers might be able to output binary someday
 -
 +  NamedListObject normalized = getParsedResponse(req, rsp);
   req.close();
 -  return _processor.processResponse( new StringReader( out.toString() ) 
 );
 +  return normalized;
 }
 catch( IOException iox ) {
   throw iox;
 @@ -169,4 +155,27 @@
   throw new

Re: svn commit: r678624 - /lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java

2008-07-21 Thread Ryan McKinley


Ideally we don't need to.

However, we do need to convert things like DocList to  
SolrDocumentList, also the Map/List representation should match what  
happens *if* it did go via HTTP.  That is, if a handler adds a  
LinkedHashSet to the response, the client does not know that -- it  
just behaves as a collection.


We need to make sure the behavior of Embedded vs Http is identical.

Writing this conversion has been on my TODO list for a while, but I  
don't see it happening anytime soon.  This patch abstracts things out  
so there is an easy place to put in this optimization when someone has  
the need/time.


ryan


On Jul 22, 2008, at 12:21 AM, Noble Paul നോബിള്‍  
नोब्ळ् wrote:



why do we need a serialize/deserialize for EmbeddedSolrServer? Why
can't we just return the Namedlist directly?

On Tue, Jul 22, 2008 at 8:47 AM,  [EMAIL PROTECTED] wrote:

Author: ryan
Date: Mon Jul 21 20:17:13 2008
New Revision: 678624

URL: http://svn.apache.org/viewvc?rev=678624view=rev
Log:
SOLR-641 -- use the binary parser for embeded solr server

Modified:
  lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/embedded/EmbeddedSolrServer.java


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=678624r1=678623r2=678624view=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 Jul 21 20:17:13 2008

@@ -17,6 +17,8 @@

package org.apache.solr.client.solrj.embedded;

+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.StringReader;
import java.io.StringWriter;
@@ -25,15 +27,16 @@
import org.apache.solr.client.solrj.SolrRequest;
import org.apache.solr.client.solrj.SolrServer;
import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.impl.BinaryResponseParser;
import org.apache.solr.client.solrj.impl.XMLResponseParser;
import org.apache.solr.common.SolrException;
import org.apache.solr.common.params.CommonParams;
-import org.apache.solr.common.params.DefaultSolrParams;
import org.apache.solr.common.params.ModifiableSolrParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.core.MultiCore;
import org.apache.solr.core.SolrCore;
+import org.apache.solr.request.BinaryResponseWriter;
import org.apache.solr.request.QueryResponseWriter;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.request.SolrQueryResponse;
@@ -51,13 +54,12 @@
*/
public class EmbeddedSolrServer extends SolrServer
{
-  protected ModifiableSolrParams _invariantParams;
-  protected ResponseParser _processor;

 protected final MultiCore multicore; // either multicore
 protected final SolrCore core; // or single core
-  protected final SolrRequestParsers parser;
 protected final String coreName;  // use MultiCore registry
+
+  private final SolrRequestParsers _parser;

 public EmbeddedSolrServer( SolrCore core )
 {
@@ -67,7 +69,8 @@
   this.core = core;
   this.multicore = null;
   this.coreName = null;
-this.parser = init();
+
+_parser = new SolrRequestParsers( null );
 }

 public EmbeddedSolrServer(  MultiCore multicore, String coreName )
@@ -82,20 +85,10 @@
   if( c == null ) {
 throw new RuntimeException( Unknown core: +coreName );
   }
-this.parser = init();
-  }
-
-  private SolrRequestParsers init()
-  {
-_processor = new XMLResponseParser();

-_invariantParams = new ModifiableSolrParams();
-_invariantParams.set( CommonParams.WT,  
_processor.getWriterType() );

-_invariantParams.set( CommonParams.VERSION, 2.2 );
-
-return new SolrRequestParsers( null );
+_parser = new SolrRequestParsers( null );
 }
-
+
 @Override
 public NamedListObject request(SolrRequest request) throws  
SolrServerException, IOException

 {
@@ -118,9 +111,6 @@
   if( params == null ) {
 params = new ModifiableSolrParams();
   }
-if( _invariantParams != null ) {
-  params = new DefaultSolrParams( _invariantParams, params );
-}

   // Extract the handler from the path or params
   SolrRequestHandler handler = core.getRequestHandler( path );
@@ -145,7 +135,7 @@
   }

   try {
-  SolrQueryRequest req = parser.buildRequestFrom( core,  
params, request.getContentStreams() );
+  SolrQueryRequest req = _parser.buildRequestFrom( core,  
params, request.getContentStreams() );

 req.getContext().put( path, path );
 SolrQueryResponse rsp = new SolrQueryResponse();
 core.execute( handler, req, rsp );
@@ -154,13 +144,9 @@
 }

 //

[jira] Commented: (SOLR-644) Increase maximum POST size in example Jetty configuration


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

Lars Kotthoff commented on SOLR-644:


I've had a quick look at the source code; the only place where this parameter 
is used is when checking the size of the uploaded content and throwing an 
IllegalStateException when it's too large. It shouldn't affect the required 
resources at all.

 Increase maximum POST size in example Jetty configuration
 -

 Key: SOLR-644
 URL: https://issues.apache.org/jira/browse/SOLR-644
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: Jetty 6.1.3
Reporter: Lars Kotthoff
Priority: Minor
 Attachments: SOLR-644.patch


 The default maximum POST size for Jetty is 200 KB, which might be 
 insufficient when dealing with shards and sorting/faceting (cf. 
 https://issues.apache.org/jira/browse/SOLR-303?focusedCommentId=12614708#action_12614708).
  The example Jetty configuration should increase the maximum POST size to 
 make this problem less likely to occur.

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

[jira] Resolved: (SOLR-644) Increase maximum POST size in example Jetty configuration


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

Yonik Seeley resolved SOLR-644.
---

   Resolution: Fixed
Fix Version/s: 1.3

Great, thanks for looking into that.  Committed.

 Increase maximum POST size in example Jetty configuration
 -

 Key: SOLR-644
 URL: https://issues.apache.org/jira/browse/SOLR-644
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.3
 Environment: Jetty 6.1.3
Reporter: Lars Kotthoff
Priority: Minor
 Fix For: 1.3

 Attachments: SOLR-644.patch


 The default maximum POST size for Jetty is 200 KB, which might be 
 insufficient when dealing with shards and sorting/faceting (cf. 
 https://issues.apache.org/jira/browse/SOLR-303?focusedCommentId=12614708#action_12614708).
  The example Jetty configuration should increase the maximum POST size to 
 make this problem less likely to occur.

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

[jira] Resolved: (SOLR-641) expose EmbeddedSolrServer response parsing


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

Ryan McKinley resolved SOLR-641.


   Resolution: Fixed
Fix Version/s: 1.3

 expose EmbeddedSolrServer response parsing
 --

 Key: SOLR-641
 URL: https://issues.apache.org/jira/browse/SOLR-641
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.3

 Attachments: SOLR-641-embedded-parsing.patch


 Currently the EmbeddedSolrServer writes the response to XML (a string) then 
 parses it so that it has an equivolent response to if it were passed around 
 via HTTP.  We should:
 * make this more efficient, or at least refactor so it is easy to make it 
 more efficient in the future
 * expose the parsing functions, so other components could use it directly.

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

[jira] Created: (SOLR-645) Move facet tests into own class

Move facet tests into own class
---

 Key: SOLR-645
 URL: https://issues.apache.org/jira/browse/SOLR-645
 Project: Solr
  Issue Type: Task
Affects Versions: 1.3
Reporter: Lars Kotthoff
Priority: Minor


The tests for faceting currently reside in BasicFunctionalityTest (line count 
1339). They should be moved to their own class in o.a.s.request to make them 
easier to find and to reduce the size of BasicFunctionalityTest.

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

[jira] Updated: (SOLR-469) Data Import RequestHandler


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

Noble Paul updated SOLR-469:


Attachment: SOLR-469-contrib.patch

* Added a method _destroy()_ to _EntityProcessor_ . This coupled with init() 
can be used for pre/post actions
* _JdbcDataSource_ uses _Statement#execute()_  instead of 
_Statement#executeQuery()_ . So users can execute DDL/DML using _JdbcDataSource_

 Data Import RequestHandler
 --

 Key: SOLR-469
 URL: https://issues.apache.org/jira/browse/SOLR-469
 Project: Solr
  Issue Type: New Feature
  Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
 Fix For: 1.3

 Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch


 We need a RequestHandler Which can import data from a DB or other dataSources 
 into the Solr index .Think of it as an advanced form of SqlUpload Plugin 
 (SOLR-103).
 The way it works is as follows.
 * Provide a configuration file (xml) to the Handler which takes in the 
 necessary SQL queries and mappings to a solr schema
   - It also takes in a properties file for the data source 
 configuraution
 * Given the configuration it can also generate the solr schema.xml
 * It is registered as a RequestHandler which can take two commands 
 do-full-import, do-delta-import
   -  do-full-import - dumps all the data from the Database into the 
 index (based on the SQL query in configuration)
   - do-delta-import - dumps all the data that has changed since last 
 import. (We assume a modified-timestamp column in tables)
 * It provides a admin page
   - where we can schedule it to be run automatically at regular 
 intervals
   - It shows the status of the Handler (idle, full-import, 
 delta-import)

-- 
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-469) Data Import RequestHandler


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

noble.paul edited comment on SOLR-469 at 7/21/08 10:14 PM:
---

* Added a method _destroy()_ to _EntityProcessor_ . This coupled with _init()_ 
can be used for pre/post actions
* _JdbcDataSource_ uses _Statement#execute()_  instead of 
_Statement#executeQuery()_ . So users can execute DDL/DML using _JdbcDataSource_
* _Context_ has a new method _getSolrCore()_ which returns the _SolrCore_ 
instance

  was (Author: noble.paul):
* Added a method _destroy()_ to _EntityProcessor_ . This coupled with 
init() can be used for pre/post actions
* _JdbcDataSource_ uses _Statement#execute()_  instead of 
_Statement#executeQuery()_ . So users can execute DDL/DML using _JdbcDataSource_
  
 Data Import RequestHandler
 --

 Key: SOLR-469
 URL: https://issues.apache.org/jira/browse/SOLR-469
 Project: Solr
  Issue Type: New Feature
  Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
 Fix For: 1.3

 Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch


 We need a RequestHandler Which can import data from a DB or other dataSources 
 into the Solr index .Think of it as an advanced form of SqlUpload Plugin 
 (SOLR-103).
 The way it works is as follows.
 * Provide a configuration file (xml) to the Handler which takes in the 
 necessary SQL queries and mappings to a solr schema
   - It also takes in a properties file for the data source 
 configuraution
 * Given the configuration it can also generate the solr schema.xml
 * It is registered as a RequestHandler which can take two commands 
 do-full-import, do-delta-import
   -  do-full-import - dumps all the data from the Database into the 
 index (based on the SQL query in configuration)
   - do-delta-import - dumps all the data that has changed since last 
 import. (We assume a modified-timestamp column in tables)
 * It provides a admin page
   - where we can schedule it to be run automatically at regular 
 intervals
   - It shows the status of the Handler (idle, full-import, 
 delta-import)

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

[jira] Updated: (SOLR-469) Data Import RequestHandler


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

Noble Paul updated SOLR-469:


Attachment: SOLR-469-contrib.patch

it was a bad patch 

 Data Import RequestHandler
 --

 Key: SOLR-469
 URL: https://issues.apache.org/jira/browse/SOLR-469
 Project: Solr
  Issue Type: New Feature
  Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
 Fix For: 1.3

 Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch


 We need a RequestHandler Which can import data from a DB or other dataSources 
 into the Solr index .Think of it as an advanced form of SqlUpload Plugin 
 (SOLR-103).
 The way it works is as follows.
 * Provide a configuration file (xml) to the Handler which takes in the 
 necessary SQL queries and mappings to a solr schema
   - It also takes in a properties file for the data source 
 configuraution
 * Given the configuration it can also generate the solr schema.xml
 * It is registered as a RequestHandler which can take two commands 
 do-full-import, do-delta-import
   -  do-full-import - dumps all the data from the Database into the 
 index (based on the SQL query in configuration)
   - do-delta-import - dumps all the data that has changed since last 
 import. (We assume a modified-timestamp column in tables)
 * It provides a admin page
   - where we can schedule it to be run automatically at regular 
 intervals
   - It shows the status of the Handler (idle, full-import, 
 delta-import)

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

[jira] Updated: (SOLR-469) Data Import RequestHandler


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

Noble Paul updated SOLR-469:


Attachment: (was: SOLR-469-contrib.patch)

 Data Import RequestHandler
 --

 Key: SOLR-469
 URL: https://issues.apache.org/jira/browse/SOLR-469
 Project: Solr
  Issue Type: New Feature
  Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
 Fix For: 1.3

 Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469-contrib.patch, SOLR-469-contrib.patch, SOLR-469-contrib.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, 
 SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch


 We need a RequestHandler Which can import data from a DB or other dataSources 
 into the Solr index .Think of it as an advanced form of SqlUpload Plugin 
 (SOLR-103).
 The way it works is as follows.
 * Provide a configuration file (xml) to the Handler which takes in the 
 necessary SQL queries and mappings to a solr schema
   - It also takes in a properties file for the data source 
 configuraution
 * Given the configuration it can also generate the solr schema.xml
 * It is registered as a RequestHandler which can take two commands 
 do-full-import, do-delta-import
   -  do-full-import - dumps all the data from the Database into the 
 index (based on the SQL query in configuration)
   - do-delta-import - dumps all the data that has changed since last 
 import. (We assume a modified-timestamp column in tables)
 * It provides a admin page
   - where we can schedule it to be run automatically at regular 
 intervals
   - It shows the status of the Handler (idle, full-import, 
 delta-import)

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

[jira] Updated: (SOLR-540) Add support for hl.fl=*