) for Solr.
Adding mail support means you can index your emails into Sols with a
few lines of configuration
--Noble
On Fri, Jan 2, 2009 at 4:30 AM, Ben Johnson
ben.john...@jandpconsulting.co.uk wrote:
I'm watching this issue with interest, but I'm having trouble
understanding
the bigger picture. I am
, Ben Johnson
ben.john...@jandpconsulting.co.uk wrote:
Thanks Paul and Preetam. A couple of further things:
- How do you envisage this functionality being used? I can see indexing
all
emails for all users as part of a one-off system setup/migration process,
but also as a core feature to ensure
To a certain extent SLF4j makes this decision a fairly small one, namely
what API do you want to code to inside SOLR and what jars do you want to
ship as a part of the distribution. It doesn't really matter if you pick
commons-logging, log4j or slf4j; all have drop in replacements via SLF4j.
They
A little late to the email party but...
[ ] Keep solr logging as is. (JUL)
[ X ] Convert solr logging to SLF4J
And SOLR-560 looks good too.
- will
(putting on flame suit)
I'd be in favor seeing is how I spent a good bit of time 2 months ago
writing JUL handlers and log managers to forward log messages to our logging
framework (log4j). Pretty much any alternative (Commons, Log4j, SLF4J) is
better since all of them allow you to _configure_
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570319#action_12570319
]
Will Johnson commented on SOLR-342:
---
the new solr with the new lucene did the trick. i
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569408#action_12569408
]
Will Johnson commented on SOLR-342:
---
i switched to the lucene 2.3 branch, updated
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567508#action_12567508
]
Will Johnson commented on SOLR-342:
---
we are doing multi-threaded indexing and searching
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567099#action_12567099
]
Will Johnson commented on SOLR-342:
---
I think we're running into a very serious issue
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567198#action_12567198
]
Will Johnson commented on SOLR-342:
---
we have:
mergeFactor10/mergeFactor
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567235#action_12567235
]
Will Johnson commented on SOLR-342:
---
we're using SolrCore in terms of:
core = new SolrCore
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567218#action_12567218
]
Will Johnson commented on SOLR-342:
---
we're not using parallel reader but we are using
Components: update
Affects Versions: 1.3
Reporter: Will Johnson
Has anyone run into the problem of handling bad documents / failures mid batch.
Ie:
add
doc
field name=id1/field
/doc
doc
field name=id2/field
field name=myDateFieldI_AM_A_BAD_DATE/field
/doc
Fyi: the CommonsHttpSolrServer already has method to do all of those
things:
/** set connectionTimeout on the underlying
MultiThreadedHttpConnectionManager */
public void setConnectionTimeout(int timeout) {
_connectionManager.getParams().setConnectionTimeout(timeout);
}
/** set
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547853
]
Will Johnson commented on SOLR-421:
---
i also added 'implements java.io.Serializable' to:
SolrRequest
SolrInputField
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547854
]
Will Johnson commented on SOLR-342:
---
just a comment to say that we added this patch and saw rather signifigant
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547925
]
Will Johnson commented on SOLR-342:
---
is there any update on getting this patch committed? we needed to be able
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546249
]
Will Johnson commented on SOLR-421:
---
it would also be good to make the same changes to all of the solrj library
Check out luke:
http://wiki.apache.org/solr/LukeRequestHandler
- will
-Original Message-
From: S DALAL [mailto:[EMAIL PROTECTED]
Sent: Monday, November 05, 2007 7:29 AM
To: solr-dev@lucene.apache.org
Subject: schema query
Hi,
Is there a way to query for the schema or the field
Even if we used a dependency management tool, the junit/ant
integration
still requires that developers have the ant-junit bindings (aka:
ant-junit.jar) in the class path when the build.xml is parsed.
supposedly
you can explicitly declare the junit tasks with your own taskdef and
identify
Components: update
Affects Versions: 1.3
Environment: test fails on both pc + mac, tomcat + jetty all java 1.6
Reporter: Will Johnson
we were doing some performance testing for the updating aspects of solr and ran
into what seems to be a large problem. we're creating small
[
https://issues.apache.org/jira/browse/SOLR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-360:
--
Attachment: TestJettyLargeVolume.java
i'll work on the patch to make it cleaner and run with the build
I haven't yet looked at SOLR-192 to see how it is done there, though.
-Mike
it no where near perfect but it did at least pass some unit tests.
my immediate need to have that bit of functionality has lessened but
i'd be happy to keep working and testing if anyone has comments on
the
[
https://issues.apache.org/jira/browse/SOLR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-192:
--
Attachment: SOLR-192-functionQueries.patch
patch attached that uses the functionality from lucene
[
https://issues.apache.org/jira/browse/SOLR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523042
]
Will Johnson commented on SOLR-192:
---
is anyone currently working on doing this migration? i submitted a patch
Environment: a new task in build.xml named javadoc-solrj that does
pretty much what you'd expect. creates a new fold build/docs/api-solrj.
heavily based on the example from the solr core javadoc target.
Reporter: Will Johnson
Priority: Minor
Fix For: 1.3
[
https://issues.apache.org/jira/browse/SOLR-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-312:
--
Attachment: create-solrj-javadoc.patch
simple patch to add new task
create solrj javadoc in build.xml
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513912
]
Will Johnson commented on SOLR-215:
---
did anything ever get baked into the patch for handling the core name as a cgi
comments?
Hooray, and very cool. I didn't know you only needed a locking
mechanism if you only have multiple index writers so the use of NoLock
by default makes perfect sense.
A quick stability update: Since I first submitted the patch ~2 months
ago we've had 0 lockups with it running in all
One question I had was about backward compatibility... is there a way
to register a null or default core that reverts to the original paths?
Are there any other backward compatible gotchas (not related to custom
java code)?
I'm very excited about this patch as it would remove my current scheme
of
) Multiple Solr Cores
On 7/11/07, Will Johnson [EMAIL PROTECTED] wrote:
I think it would be nice to have the core name
specified as a CGI param instead of (or in addition to) a url path.
Otherwise, large section of client code (such as solrj/solr#) will
need
to be changed.
Only if you want
[
https://issues.apache.org/jira/browse/SOLR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-280:
--
Attachment: SOLR-280-SolrDocument2-API-Compatibility.patch
The API changes mostly affect solrj users
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-278:
--
Attachment: LukeSchemaHandling.patch
LukeRequest/Response for handling show=schema
Affects Versions: 1.3
Reporter: Will Johnson
Priority: Minor
Fix For: 1.3
the soon to be attached patch adds a method to LukeRequest to set the option
for showing schema from SOLR-266. the patch also modifies LukeRepsonse to
handle the schema info in the same
[
https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509160
]
Will Johnson commented on SOLR-278:
---
I guess I was hoping for a super set of features in
LukeResponse.FieldInfo
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
new patch that writes out request params as cgi instead
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508163
]
Will Johnson commented on SOLR-267:
---
A few response rolled up:
Yonik Seeley commented on SOLR-267
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507312
]
Will Johnson commented on SOLR-267:
---
One thing that comes to mind is making the response header a standard
part
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
new patch to promote responseHeader from a defacto standard
This produces log messages that look like this:
INFO: /select q=solrwt=pythonindent=on hits=1 0 94
If there was no DocSet, it would look like this:
INFO: /select q=solrwt=pythonindent=on - 0 94
I would think that tacking the new stats onto the end of the line would
be better than in the middle.
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
slight update to log the webapp name which is set
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-176:
--
Attachment: RequesthandlerBase.patch
a slightly more ambitious patch that tracks:
* total number
log handler + query +
--
Key: SOLR-267
URL: https://issues.apache.org/jira/browse/SOLR-267
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.3
Reporter: Will Johnson
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
hit a random key a little fast on the last post. the attached patch
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Description:
adds a logger to log handler, query string and hit counts for each query
was:
adds
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
updated patch to work in SolrCore.execute() instead. i annotated
Would it be better to have an option to record traffic for the last 'x
minutes/seconds/hours' configurable on a per handler basis? The goal is
to have hooks for nagios/cacti/etc to be able to pull live status info
for monitoring purposes. If you want fine grained performance history
then log
Has anyone tried to get solr statistics with cacti/nagios? If it isn't
too difficult, I would like to set this up.
Can cacti read parse a file?
Generally speaking nagios/cacti are as powerful as you are with bash.
We haven't done it yet but it's a requirement at my company to integrate
the
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505846
]
Will Johnson commented on SOLR-239:
---
after looking at all the dependencies for IndexSchema and with the addition
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505938
]
Will Johnson commented on SOLR-265:
---
After doing some more thinking about the issue after I submitted the
patch I
I haven't looked at the patch, but have a couple questions:
* What is the motivation/use case for editing the schema at runtime? (I'm not
suggesting there aren't good ones, just curious)
to add new fields on the fly without having any search downtime
* Would changes be saved?
the patch as is
Some thoughts:
One of the most powerful and useful concepts that many of the other
engines (well the good ones) use is the notion of processing pipelines.
For queries this means a series of stages that do things such as:
* faceting
* collapsing
* applying default values
* spell checking
*
Having worked on a number of customer implementations regarding this
feature I can say that the number one requirement is for the facet
counts to be accurate post collapsing. It all comes down to the user
experience. For example, if I run a query that get collapsed and has a
facet count for the
I assumed they would... I think our signals might be crossed w.r.t.
the meaning of pre or post collapsing. Faceting post collapsing I
took to mean that the base docset would be restricted to the top n
of each category.
In my view, faceting should occur on the full collapsed result set. Ie
break
And one other point, one of the reasons why it's hard to find an example
of post-faceting is that many of the major engines can't do it.
- will
-Original Message-
From: Will Johnson [mailto:[EMAIL PROTECTED]
Sent: Monday, June 11, 2007 11:05 AM
To: solr-dev@lucene.apache.org
Subject
Reporter: Will Johnson
Priority: Minor
Fix For: 1.2
when solr/home is set improperly, tomcat (and other containers) fail to log any
useful error messages because everything goes to SolrConfig.severeErrors
instead of some basic container level logs. the soon
Sorry, I forgot to turn on my _wild_ideas_ flag before that last post.
That being said, you could build the notion of dependencies into each
stage and have the search logic omputed based on those dependencies,
alternatively you could do pre/post methods for each processing stage
that allow each
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream2.patch
new patch that includes a GetFile servlet to possibly replace get
Has anyone thought of adding the docsum time to the qtime or possibly
adding separate timing information for the real 'solr query time'.
While my bosses are very pleased that most searches seem to take ~5ms it
does seem a bit misleading.
I'll take a crack at a patch unless there is a reason not
I haven't looked at any of the patches but I can comment some other uses
for the feature that are in production today with major vendors. While
it's used for site collapsing ala google it's also heavily used in
ecommerce settings. Check out BestBuy.com/circuitcity/etc and do a
search for some
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream2.patch
New patch that address all 6 suggestions. The one thing
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500704
]
Will Johnson commented on SOLR-239:
---
after seeing that i'd need to regenerate a patch for the new IndexSchema's
[
https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499843
]
Will Johnson commented on SOLR-240:
---
i get the stacktrace below with the latest from head with useNativeLocks turned
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream2.patch
updated with fixed and test raw-schema.jsp and added back
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream2.patch
the attached patch (IndexSchemaStream2.patch) includes a cleaned up
Environment: all
Reporter: Will Johnson
Priority: Minor
Fix For: 1.2
Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch,
IndexSchemaStream2.patch
Soon to follow patch adds a constructor to IndexSchema to allow them
i'll have another go at the patch tomorrow morning; testing the raw-schema.jsp
(even if it's not used) and put back the test.
- will
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Thu 5/24/2007 6:02 PM
To: solr-dev@lucene.apache.org
Subject: RE: [jira]
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-176:
--
Attachment: RequesthandlerBase.patch
added some average stats to RequestHandlerBase. all of the same
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream2.patch
patch updated. now with the added benefit of compiling.
Read
Affects Versions: 1.2
Environment: windows xp
Reporter: Will Johnson
when running the soon to be attached sample application against solr it will
eventually die. this same error has happened on both windows and rh4 linux.
the app is just submitting docs with an id
[
https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-240:
--
Attachment: stacktrace.txt
ThrashIndex.java
java.io.IOException: Lock obtain timed out
-240
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.2
Environment: windows xp
Reporter: Will Johnson
Attachments: IndexWriter.patch, stacktrace.txt,
ThrashIndex.java
when running the soon to be attached
On my XP laptop it takes a couple minutes, on the Linux server it took 2
days.
- will
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik
Seeley
Sent: Tuesday, May 15, 2007 4:57 PM
To: solr-dev@lucene.apache.org
Subject: Re: (solr 240)
[
https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-240:
--
Attachment: IndexWriter2.patch
the attached patch adds a param to SolrIndexConfig called useNativeLocks
: 1.2
Environment: all
Reporter: Will Johnson
Priority: Minor
Fix For: 1.2
Soon to follow patch adds a constructor to IndexSchema to allow them to be
created directly from InputStreams. The overall logic for the Core's use of
the IndexSchema creation
[
https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-239:
--
Attachment: IndexSchemaStream.patch
patch with test cases attached. i also had to change raw-schema.jsp
[
https://issues.apache.org/jira/browse/SOLR-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493784
]
Will Johnson commented on SOLR-86:
--
has anyone brought up the idea of creating post.bat and post.sh scripts that
use
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492902
]
Will Johnson commented on SOLR-20:
--
the new api's work great, thanks! what's the plan for this going forward? id
[
https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492664
]
Will Johnson commented on SOLR-217:
---
since we now have required fields
(http://issues.apache.org/jira/browse/SOLR
[
https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-217:
--
Attachment: ignoreUnnamedFields_v3.patch
v3 patch included. this version of the patch also takes
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492700
]
Will Johnson commented on SOLR-20:
--
the trunk version at http://solrstuff.org/svn/solrj/ seems to be missing
[
https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-217:
--
Attachment: ignoreUnnamedFields.patch
the attached patch solve this problme by adding a new option
Reporter: Will Johnson
Priority: Minor
Fix For: 1.2
Attachments: ignoreUnnamedFields.patch
One thing that causes problems for me (and i assume others) is that Solr is
schema-strict in that unknown fields cause solr to throw exceptions and there
is no way
[
https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-217:
--
Attachment: ignoreNonIndexedNonStoredField.patch
I like that solution and I can definitely see
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 1.2
Reporter: Will Johnson
Priority: Minor
Fix For: 1.2
Attachments: ignoreNonIndexedNonStoredField.patch,
ignoreUnnamedFields.patch
One thing
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490117
]
Will Johnson commented on SOLR-20:
--
is there an updated package or anyone working on such a thing at the moment
86 matches
Mail list logo
