[jira] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-127: -- Attachment: HTTPCaching.patch Added the request parameter httpnocache (can be true or false - defaults to false) to emit no-cache Cache-Control headers for requests you do not want to be cached by shared caches. Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.3 Attachments: HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553922 ] Henri Biestro commented on SOLR-350: RequestHandlers do not today know the path that requested them;I was merely proposing a possible functional extension through usage of aliases. As for core names, being able to carry which version/revision of the config/schema is in use is imho not complex and useful to many (using svn/cvs/webdav to store config/schema) Anyway, the 'aliases' idea is definitely not something you did find useful enough from the beginning and I'm obviously failing to make the case for it. Alas. 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 Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.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] Updated: (SOLR-127) Make Solr more friendly to external HTTP caches
[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-127: -- Attachment: HTTPCaching.patch Updated. Even more aggressive no-cache header get emitted when httpnocache=true. Make Solr more friendly to external HTTP caches --- Key: SOLR-127 URL: https://issues.apache.org/jira/browse/SOLR-127 Project: Solr Issue Type: Wish Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.3 Attachments: HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch an offhand comment I saw recently reminded me of something that really bugged me about the serach solution i used *before* Solr -- it didn't play nicely with HTTP caches that might be sitting in front of it. at the moment, Solr doesn't put in particularly usefull info in the HTTP Response headers to aid in caching (ie: Last-Modified), responds to all HEAD requests with a 400, and doesn't do anything special with If-Modified-Since. t the very least, we can set a Last-Modified based on when the current IndexReder was open (if not the Date on the IndexReader) and use the same info to determing how to respond to If-Modified-Since requests. (for the record, i think the reason this hasn't occured to me in the 2+ years i've been using Solr, is because with the internal caching, i've yet to need to put a proxy cache in front of Solr) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553983 ] Ryan McKinley commented on SOLR-350: RequestHandlers do not today know the path that requested them; aaah -- so if we need it later, we could add aliasing then? is imho not complex and useful to many (using svn/cvs/webdav to store config/schema) How does aliasing change this. What can you do that you could not do without it? I store my config/schema in svn and don't have any problems. Anyway, the 'aliases' idea is definitely not something you did find useful enough from the beginning If I understood what you gain, I could be convinced. Right now I just see it as the need to manage and maintain multiple names+one immutable name without any reason. Perhaps we can move forward without aliasing, and add it later if we find (and implement) a solid use case for it. 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 Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.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-443) POST queries don't declare its charset
POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Schurman updated SOLR-443: - Attachment: solr-443.patch Simple fix that will fix the issue for this case. I don't believe it will cause issues elsewhere within the java client. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554005 ] Andrew Schurman commented on SOLR-443: -- Haven't had a chance to test that, but I believe that would work also since we are only sending non-multipart POSTs anyways. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch, solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-443: --- Attachment: solr-443.patch Andrew, does this patch work for you? rather then specify the contentType for all POST request, it only adds it for ones that don't specify it within a ContentStream POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch, solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- 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
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-350: --- Attachment: SOLR-350-Naming.patch Here is a patch that cleans up some naming and implements the SWAP command. It does not include the persistence stuff in the latest solr-350.patch Henri - how do you feel about committing this, then implementing persistence in a smaller patch? 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 Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.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] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554045 ] Henri Biestro commented on SOLR-350: SWAP is an important feature to exploit multicore persistence is not production ready yet, so committing feels like the next logical step . Ryan, if possible, I'd appreciate and would greatly benefit from a quick/early review of the solr-315.patch peristence core creation code (XmWriter, CoreDescriptor; keep them or loose them?). As an upside on the ALIAS discussion, if when a use case shows up, I guess we will be ready! 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 Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.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] Resolved: (SOLR-441) example app comes up with some bad links
[ https://issues.apache.org/jira/browse/SOLR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-441. Resolution: Fixed Fix Version/s: 1.3 Assignee: Ryan McKinley example app comes up with some bad links Key: SOLR-441 URL: https://issues.apache.org/jira/browse/SOLR-441 Project: Solr Issue Type: Bug Environment: Mac OSX, java version 1.5.0_13, Firefox Reporter: Mike Travers Assignee: Ryan McKinley Priority: Minor Fix For: 1.3 The solr example comes up with bad links on the admin page. They contain ?core=null, which results in an error when they are clicked. Removing the core=null from the URLs makes it work OK. This is mostly an annoyance, spoiling what would otherwise be a very slick out-of-the-box experience. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554053 ] Ryan McKinley commented on SOLR-350: just committed SOLR-350-Naming.patch Ryan, if possible, I'd appreciate and would greatly benefit from a quick/early review of the solr-315.patch peristence core creation code (XmWriter, CoreDescriptor; keep them or loose them?). I gave it a quick look this morning, but did not look too closely because all the 'alias' stuff ;) XmWriter and CoreDescriptor seem reasonable to me. The CoreDescriptor could be used to move both Config and Schema away from knowing what file opened them. Check SOLR-427 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 Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.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] Commented: (SOLR-443) POST queries don't declare its charset
[
https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554061
]
Yonik Seeley commented on SOLR-443:
---
The problem is, the body isn't really in UTF8. Here's a request from SolrJ
with the patch:
{code}
POST /solr/select HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: Solr[org.apache.solr.client.solrj.impl.CommonsHttpSolrServer] 1.0
Host: localhost:8983
Content-Length: 42
q=features%3Ah%C3%A9llowt=xmlversion=2.2
{code}
The SolrJ code is
{code}
SolrServer server = new CommonsHttpSolrServer(http://localhost:8983/solr;);
ModifiableSolrParams params = new ModifiableSolrParams();
QueryRequest req = new QueryRequest(params);
params.set(q,features:h\u00E9llo);
req.setMethod(SolrRequest.METHOD.POST);
QueryResponse rsp = server.query(params);
{code}
What HttpClient is outputing is percent encoded UTF8 bytes (and that's not
UTF-8). So the charset here really isn't the problem, because the body is
nothing but ASCII. The body coding matches the type of coding specified in the
URI RFC http://www.ietf.org/rfc/rfc3986.txt
But that only specifies the coding for parameters that go in the URI.
I haven't been able to find an updated standard that specifies percent encoded
UTF-8 bytes for application/x-www-form-urlencoded. Does anyone know if there
is one?
Anyway, long story short is that this may still fail on Tomcat.
POST queries don't declare its charset
--
Key: SOLR-443
URL: https://issues.apache.org/jira/browse/SOLR-443
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.2
Environment: Tomcat 6.0.14
Reporter: Andrew Schurman
Priority: Minor
Attachments: solr-443.patch, solr-443.patch
When sending a query via POST, the content-type is not set. The content
charset for the POST parameters are set, but this only appears to be used for
creating the Content-Length header in the commons library. Since a query is
encoded in UTF-8, the http headers should also specify content type charset.
On Tomcat, this causes problems when the query string contains non-ascii
characters (characters with accents and such) as it tries to parse the POST
body in its default ISO-9886-1. There appears to be no way to set/change the
default encoding for a message body on Tomcat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554062 ] Andrew Schurman commented on SOLR-443: -- I believe your right Yonik. I think when I was testing I forgot to remove a filter that I was using to convert the request into UTF8. I'm now testing again and it still appears to process the results inconsistently. POST queries don't declare its charset -- Key: SOLR-443 URL: https://issues.apache.org/jira/browse/SOLR-443 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.2 Environment: Tomcat 6.0.14 Reporter: Andrew Schurman Priority: Minor Attachments: solr-443.patch, solr-443.patch When sending a query via POST, the content-type is not set. The content charset for the POST parameters are set, but this only appears to be used for creating the Content-Length header in the commons library. Since a query is encoded in UTF-8, the http headers should also specify content type charset. On Tomcat, this causes problems when the query string contains non-ascii characters (characters with accents and such) as it tries to parse the POST body in its default ISO-9886-1. There appears to be no way to set/change the default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[
https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554085
]
Henri Biestro commented on SOLR-350:
On aliases - for completeness - , I had this nagging thought I was missing
something...
Re-reading Hoss's proposal and crossing that with the 1000 unique names point
you made, there is in any case 1000 unique 'instanceDir' that need to be
provided; Hoss proposed to use the 'instanceDir' instead of a name and alias
that if I'm not mistaken.
I got side tracked by the fact that the instanceDir could be absolute which
would have introduced a deployment host 'hard' dependency and lost the
equivalence.
If we define an 'instanceRoot' (at the multicore level or at the core level)
and make the (core) instanceDir = instanceRoot + '/' + name, the uniqueness of
the core name would be put to its initial intended use (instead of just being a
by-product of the alias feature). In that case, at least one alias is
convenient so we can keep the 'url' constant across index revisions.
For instance, if you are using svn, you could have you instanceDir/{schema,
conf} versioned; when you have a new revision ready to go, you copy these over
using the instanceDir+,+revision-number and use that as a name (which isn't
too bad of a convention).
And then, there are maybe future features that could be added to use aliases
for other purpose...
Oh well...
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
Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch,
SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.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.
Re: [Solr Wiki] Update of Prashant Chauhan by Prashant Chauhan
Yeah, I'd remove any page that doesn't have something to do with Solr (and just saying I use Solr, go Solr! doesn't count). Shall I clean up? Otis - Original Message From: Steven A Rowe [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Thursday, December 20, 2007 12:06:51 PM Subject: RE: [Solr Wiki] Update of Prashant Chauhan by Prashant Chauhan Hi Otis, I guess we'd have to clean up all personal pages then (found these by looking at http://wiki.apache.org/solr/TitleIndex): http://wiki.apache.org/solr/ErikHatcher http://wiki.apache.org/solr/Prashant_Chauhan http://wiki.apache.org/solr/Hemant_Verma http://wiki.apache.org/solr/IanMeyer http://wiki.apache.org/solr/JohnClarkeMills (**) http://wiki.apache.org/solr/LindaTan http://wiki.apache.org/solr/MekinMaheshwari http://wiki.apache.org/solr/Nitin (**) Looks like a copy of FrontPage ??? Steve On 12/20/2007 at 10:53 AM, Otis Gospodnetic wrote: Huh? Should we clean this up? Otis - Original Message From: Apache Wiki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 20, 2007 5:52:30 AM Subject: [Solr Wiki] Update of Prashant Chauhan by Prashant Chauhan Dear Wiki user, You have subscribed to a wiki page or wiki category on Solr Wiki for change notification. The following page has been changed by Prashant Chauhan: http://wiki.apache.org/solr/Prashant_Chauhan New page: Hi, This is Prashant Chauhan. I am working, in Times Business Solutions Ltd. (TimesJobs.com), NOIDA - INDIA. ,as a Search Engineer. Here I am using solr. Email: [EMAIL PROTECTED]
