On 2-Jul-07, at 11:34 PM, Ryan McKinley wrote:
URL: http://svn.apache.org/viewvc?view=rev&rev=552683
Log:
SOLR-102 - regex fragmenter using SOLR-225 plugin framework
Mike - I did not add this to CHANGES.txt.
Do you want to?
I'll add it, along with some javadocs/wiki docs.
Thanks,
-Mike
[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509728
]
Mike Klaas commented on SOLR-225:
-
> I'm torn on what is more/less elegant.
> Should we have a n
[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509709
]
Mike Klaas edited comment on SOLR-225 at 7/2/07 4:14 PM:
-
Looking great Ryan (again, only
[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509709
]
Mike Klaas commented on SOLR-225:
-
Looking great Ryan (again, only commenting on the Highlighting configurability
On 2-Jul-07, at 11:32 AM, Yonik Seeley wrote:
In the spirit of shared ownership, what do people think of getting rid
of @author tags (for committers or other dev people that consent?).
Other apache projects have done so, for a host of reasons.
- some people don't use author tags, hence credit i
[
https://issues.apache.org/jira/browse/SOLR-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-274.
-
Resolution: Fixed
fixed in r550576
> autoCommit maxDocs does not apply if maxTime is defi
[
https://issues.apache.org/jira/browse/SOLR-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SOLR-274 started by Mike Klaas.
> autoCommit maxDocs does not apply if maxTime is defi
Reporter: Mike Klaas
Assignee: Mike Klaas
Fix For: 1.3
the problem is in this block:
public void addedDocument() {
docsSinceCommit++;
lastAddedTime = System.currentTimeMillis();
if( pending == null ) { // Don't start a new event if o
Components: search
Affects Versions: 1.2
Reporter: Mike Klaas
Assignee: Mike Klaas
Priority: Minor
Fix For: 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On 22-Jun-07, at 6:53 AM, Henri Biestro (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SOLR-255?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12507326 ]
Henri Biestro commented on SOLR-255:
Toru,
I've been loo
On 20-Jun-07, at 9:54 AM, Ryan McKinley wrote:
should we update to latest stable builds?
* lucene-2.2
+1, once the release is finalized.
-mike
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-176:
Attachment: dtiming.patch
added javadocs for RTimer.java, and removed a superfluous line from SRH.java
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505393
]
Mike Klaas commented on SOLR-176:
-
Might it then make sense to wait until the search component thing is done?
Auto
On 12-Jun-07, at 2:36 PM, Yonik Seeley wrote:
On 6/12/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
The way I do field collapsing is simply gathering documents and
collapsing them until I've gathered X groups for user display (which
usually involves looking at a few tens of documents m
On 11-Jun-07, at 5:48 PM, Chris Hostetter wrote:
: Yes, the current JIRA patch uses the FieldCache.
I just ment in contrast with Mike's comment about iterating over
all the
stored fields to support the "post-faceting" situation (but frankly
i'm
not sure that i undersatnd what the "post-fac
On 11-Jun-07, at 8:10 AM, Will Johnson wrote:
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.
It seems that the only way to do it would be to collapse the entire
result set first, which entails loadin
On 8-Jun-07, at 2:44 PM, Chris Hostetter wrote:
:* '''generateWordParts="1"''' causes parts of words to be
generated:
: * `"PowerShot" => "Power" "Shot"`
: +* `"Power-Shot" => "Power" "Shot"`
: + * '''splitOnCaseChange="1"''' causes lowercase => uppercase
transitions to gene
On 8-Jun-07, at 10:57 AM, Will Johnson wrote:
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.
docsum
[
https://issues.apache.org/jira/browse/SOLR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-257.
-
Resolution: Fixed
commited in r545597 with inverted logic and yonik's name suggestion.
> Add abi
[
https://issues.apache.org/jira/browse/SOLR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502906
]
Mike Klaas commented on SOLR-257:
-
Might be a good idea. Case-based splitting is a relatively aggressive default
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-176:
Fix Version/s: (was: 1.2)
1.3
> Add detailed timing data to query response out
[
https://issues.apache.org/jira/browse/SOLR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502546
]
Mike Klaas commented on SOLR-257:
-
The difference from generateWordParts is as follows: gWP splits adjacent
tokens
[
https://issues.apache.org/jira/browse/SOLR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-257:
Attachment: ignoreCaseChange.patch
> Add ability for WordDelimiterFilter to ignore case chan
Components: update
Affects Versions: 1.2
Reporter: Mike Klaas
Assignee: Mike Klaas
Priority: Trivial
Fix For: 1.3
Attachments: ignoreCaseChange.patch
patch adds ignoreCaseChange option to WordDelimiterFilter, which I have used
and it may be
On 31-May-07, at 4:02 PM, Yonik Seeley wrote:
Sorry folks... one more time. This release candidate fixes SOLR-250
(scripts need to tell curl the content-type), as well as the minor
README typo.
Please vote to release the artifacts at
http://people.apache.org/~yonik/staging_area/solr/1.2rc3/
as
On 30-May-07, at 12:43 PM, Erik Hatcher wrote:
On May 29, 2007, at 4:38 PM, Mike Klaas wrote:
I agree. I was not aware of field boosts at the time. I'll code
this change.
Unfortunately, it is still somewhat awkward. In my python client
I end up passing (, , )
everywhere, but
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500216
]
Mike Klaas commented on SOLR-215:
-
I haven't looked at the patch, but:
- there are no current failures on
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499922
]
Mike Klaas commented on SOLR-216:
-
I just noticed that I changed my own python query code to POST from GET two
months
[reposting to solr-dev as JIRA destroyed my quoting...]
On 29-May-07, at 12:41 PM, Jason Cater wrote:
I've had my solr.py in production use internally for about a month
now. So, as you can imagine, I've worked through a few oddball bugs
that occasionally pop up. It seems pretty stable for me
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499913
]
Mike Klaas commented on SOLR-216:
-
On 29-May-07, at 12:41 PM, Jason Cater wrote:
I've had my solr.py in produ
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SOLR-216 started by Mike Klaas.
> Improvements to solr.py
> ---
>
> Key: SOLR-216
>
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas reassigned SOLR-216:
---
Assignee: Mike Klaas
> Improvements to solr.py
> ---
>
>
On 26-May-07, at 7:08 AM, Yonik Seeley wrote:
On 5/25/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
Wasn't HashDocSet significantly optimized for intersection recently?
More like optimized/simplified for storing lucene doc ids. Only about
8-10% speedup.
OpenBitSet was more on the or
[
https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499273
]
Mike Klaas commented on SOLR-216:
-
Thanks for your contribution! Some comments:
style:
- list comprehensions
On 25-May-07, at 2:09 PM, Yonik Seeley wrote:
On 5/25/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
HashDocSet maxSize: perhaps consider increasing this, or making this
by default a parameter which is tuned automatically (.5% of maxDocs,
for instance)
I think when HashDocSet is large
Since auditing solrconfig.xml defaults is on the list of things for
1.2, I thought I'd get the ball rolling:
Lazy field loading: seems like it would benefit more people to be
enabled explicitly. I've been using it successfully and some
substantial gains have been reported on the lucene lis
On 24-May-07, at 12:23 PM, Chris Hostetter wrote:
i still don't really know enough about Hudson to have an opinion on
relying on it for nightly builds, but either way i don't think we
should
add a link to the nighltys from the site ... Doug's repeated reminders
have engrained in me the impo
[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497959
]
Mike Klaas commented on SOLR-225:
-
Yeah. I'm happy to review the highlighting stuff (there are some para
On 14-May-07, at 1:01 PM, Yonik Seeley wrote:
I've audited the Lucene changes since 2.1, and don't see anything
problematic, so perhaps we should upgrade to the latest lucene trunk
to get:
- file descriptor usage reduction (only one descriptor for all
norms now)
- leading + trailing wildcard
On 11-May-07, at 5:02 PM, Ryan McKinley wrote:
Chris Hostetter wrote:
: My real use case is adding the the trim filter to the pattern
tokenizer.
: the 'correct' answer in my case it to update the offsets.
hmmm... wouldn't the "correct" thing to do in that case be to
change your
pattern so
On 10-May-07, at 4:46 PM, Ryan McKinley wrote:
Otis Gospodnetic wrote:
I haven't moved to 6.* yet. But I did notice 6.1.3 showed up a
few days ago.
I think 6.1.3 showed up a day after 6.1.2!
That's always an encouraging sign :)
-Mike
On 10-May-07, at 3:02 PM, Daniel Creão wrote:
So, I tried Solr and read about FederatedSearch and
CollectionDistribution.
An 'all-machines-have-complete-index' strategy (using rsync) can
improve
system throughput and concurrency by each station processing different
queries, but each query wil
[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494113
]
Mike Klaas commented on SOLR-225:
-
Wow, that is some honking configurability! I've looked at the patch, but
ha
On 5/4/07, Apache Wiki <[EMAIL PROTECTED]> wrote:
--
}}}
+ * audit schema.xml duplicate field definition behavior. As is {{
+
+
+
+
+
+
+
+
+ }} quietly continues -- tossing out the first defini
On 5/2/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
How about Mike's other suggestion:
this would keep the glob style for "source" and "dest", but use "regex"
to transform a sorce -> dest
Wow, I didn't even remember suggesting that. I agree (with Hoss) that
backward compatibility is impor
On 5/2/07, Brian Whitman <[EMAIL PROTECTED]> wrote:
Would love to set a custom fragmenter in Solr for highlighting. But I
don't see a way to change the fragmenter "on the fly." Should this be
a solrconfig/schema setting?
It would be nice to able to register custom formatters and
subsequently us
On 5/1/07, David Xiao <[EMAIL PROTECTED]> wrote:
Would you please give me an example? For example, I want to pick only
fieldname="features"
from the query result
Try something like:
?q=a+query&hl=true&hl.fl=features&fl=features
-Mike
On 4/27/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
2.. Non-trivial patches require a [VOTE] on the dev list before being
committed. What's "non-trivial"? I'd suggest using our common sense
and trusting each other to judge this, for a start.
"Non-trivial" seems a little weak to require
On 4/26/07, Jason Cater <[EMAIL PROTECTED]> wrote:
Greetings all.
I've recently implemented a SOLR solution internally. We typically use
python as our language of choice, so I needed a python library to
connect to SOLR.
The one in your svn repository was a good starting point, but was very
low
On 4/25/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
I'm pleased to announce that the Lucene PMC has voted to add Ryan
McKinley as a Solr committer.
Congrats, Ryan!
The standard initiation is to tell everyone a bit about yourself, and
to go use your new privileges to add yourself to the who-we-a
On 4/3/07, Lutz Steinborn <[EMAIL PROTECTED]> wrote:
But one question cames up as the index goes bigger and bigger: is it
possible to add fields to the schema without a complete reindex ?
Absolutely.
-Mike
On 3/30/07, Maximilian Hütter <[EMAIL PROTECTED]> wrote:
Chris Hostetter schrieb:
> I freely admit, I didn't appricate how much commons-logging is intended to
> be a middle-layer API for other arbitrary logging frameworks like JDK
> logging or log4j, but i still don't think it makes sense to swi
On 3/26/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
parseQueryString uses URLDecoder.decode()
With the JavaDoc:
* The platform's default encoding is used to determine what characters
* are represented by any consecutive sequences of the form
* "%xy".
That won't correctly handle p
Reporter: Mike Klaas
Priority: Minor
Fix For: 1.2
Possible bug in query rewrite()ing:
http://www.nabble.com/return-matched-terms---fuzzy-or-wildcard-searches-tf3452757.html#a9640214
--
This message is automatically generated by JIRA.
-
You can reply to this
On 3/22/07, Thierry Collogne (JIRA) <[EMAIL PROTECTED]> wrote:
I think that is all. If I forgot something, post it here. One remark. The
setHighlightSurroundingTags method can only take simple tags,
no tags containing quotes or such.
Out of curiosity, why is this? Solr should be able to handl
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482289
]
Mike Klaas commented on SOLR-176:
-
Anyone else have an opinion on timing? It would be easy for me to wrap
On 3/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: ConvertedLegacyTest can revered to a pre 520088 version with "id_i"
: and it will still pass.
would you might rolling that back Mike? ... i'd rather not change any test
unless we have to, makes it easier to be certain we are stll testing
On 3/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Thanks for comitting Mike, sorry i never got around to reviewing the patch.
Just out of curiousity though, can anyone explain why ConvertedLegacyTest
was functioning properly before this change?
I'm just wondering if we're breaking a case
[
https://issues.apache.org/jira/browse/SOLR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-172.
-
Resolution: Fixed
Fix Version/s: 1.2
Assignee: Mike Klaas
Committed in r520088. Thanks
[
https://issues.apache.org/jira/browse/SOLR-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481264
]
Mike Klaas commented on SOLR-124:
-
DUH may be simpler, but DUH2 has also been carefully modified to safely support
On 3/7/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message format
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-176:
Attachment: dtiming.patch
Same version with ASF license. Output format looks like:
13.0
1.0
19.0
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-176:
Attachment: dtiming.patch
A quick version for people to play with. Includes a new timing class, plus
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SOLR-176 started by Mike Klaas.
> Add detailed timing data to query response output
> -
>
>
[
https://issues.apache.org/jira/browse/SOLR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-174.
-
Resolution: Fixed
committed in r514851
> Add multi-param support to qf,pf,bf
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477446
]
Mike Klaas commented on SOLR-176:
-
Well, we could provide deltas of all the solr statistics, but I'm not sure i
Affects Versions: 1.2
Reporter: Mike Klaas
Assigned To: Mike Klaas
Priority: Minor
Fix For: 1.2
see http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html
--
This message is automatically generated by JIRA.
-
You can reply to this
[
https://issues.apache.org/jira/browse/SOLR-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477408
]
Mike Klaas commented on SOLR-175:
-
One thing to consider here is that every so often there are rumblings of new
[
https://issues.apache.org/jira/browse/SOLR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-174:
Attachment: multiparam.patch
updated patch as per Hoss' comments. This could use a once-over b
[
https://issues.apache.org/jira/browse/SOLR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477060
]
Mike Klaas commented on SOLR-174:
-
That's fine with me. I suspect too that anyone who knows lucene well enough
[
https://issues.apache.org/jira/browse/SOLR-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-174:
Attachment: multiparam.patch
(also includes a two-line change to re-write queries prior to highlighting
Reporter: Mike Klaas
Assigned To: Mike Klaas
Priority: Minor
Fix For: 1.2
A quick patch that adds multi-params support for the listed dismax params.
I opened an issue to get some feedback on the bq situation. I left the
subquery-extraction logic as in
On 2/21/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
Sigh, sorry about that. ant test is not ant clean test. Will fix presently.
Done.
Anyone think that we should continue maintaing CommonParams? It is
never instantiated. It is possible that it is being used by a custom
request handl
On 2/21/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
I have a clean trunk, and get a bunch of HIGHLIGHT errors:
$ ant compile
Buildfile: build.xml
checkJunitPresence:
Sigh, sorry about that. ant test is not ant clean test. Will fix presently.
-Mike
Affects Versions: 1.1.0, 1.2
Reporter: Mike Klaas
Assigned To: Yonik Seeley
Fix For: 1.1.0, 1.2
SynonymFilter can mix up options from different synonyms, sometimes inserting
the wrong word, sometimes using the wrong offset. Issue appears to be use of
the matched
On 2/19/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
On 2/19/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
> : If you commit a document while the updater is autocommiting, it is
> : likely to immediatly start another autocommit (unless you are also
> : using maxDocs).
>
> i don't really unders
On 2/14/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
I've updated the nightly build script to hopefully not proceed after
an ant failure, and kicked it off manually just now.
Do you have the failure message? We could further increase the tolerances.
-Mike
On 2/12/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
>... * A newer version of Lucene's JAR: to have *:* syntax...
+0, don't know enough about the issues to comment.
FWIW, I'm currently using the current lucene trunk with no apparently problems.
2.1 appears extremely close to r
On 2/12/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
So I'm fine with updating to the latest Lucene nightly build now... It
would give us a chance to make sure it works well for us too. Lucene
2.1 shouldn't be too far off... but I'm sick yet again, and it's hard
enough writing email in this stat
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-126.
-
Resolution: Fixed
Fix Version/s: 1.2
> Auto-commit documents after time inter
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471550
]
Mike Klaas commented on SOLR-126:
-
extra patch committed in r505114
> Auto-commit documents after time inter
On 2/8/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
Can someone commit an empty folder for:
/src/test/org/apache/solr/handler
r505069
TortoiseSVN does not support making patches with new folders. You can
get around this with svn diff from command line, but it is hard to
pick and choose wha
On 2/5/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 2/5/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 2/5/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
> > That's probably a good idea.
> >
> > I was able to get the current version to fail
On 2/5/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
That's probably a good idea.
I was able to get the current version to fail on my PC at work
intermittently by running something else that was eating CPU.
Could you try the latest trunk? It should block on pending commits if
they happen to ta
On 2/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
>
> Getting the test to pass is one thing... but this exception is
> another. Is it possible that this could be triggered by normal use of
> Solr? Perhaps by too-frequent commits?
>
I don't *think* so... I haven't seen any trouble while load
On 2/4/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
Stack trace:
INFO: Opening [EMAIL PROTECTED] main
Feb 4, 2007 5:19:41 PM org.apache.solr.core.SolrException log
SEVERE: java.util.concurrent.RejectedExecutionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExec
On 2/4/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
hymmm. what do you think the best option is?
Should we increase the time it waits to check if stuff autocommited?
It currently waits 1 second for something that *should* start an
autocommit within 1/2 sec.
Perhaps we should increase the allo
On 2/2/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Does anyone know how to access the build logs? I don't know from
> apache infra (except people./minotaur.)
It's on the lucene zone with restricted access.
It might be possible to set something up to copy some stuff to
minotaur on a failure t
On 2/2/07, solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 26.557 sec
[junit] Test org.apache.
Thanks! That's what I get for not running the test suite One Last Time
before committing.
-Mike
On 2/1/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469663
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469559
]
Mike Klaas commented on SOLR-126:
-
Committed in r502328. Thanks!
Ryan, the last comment of mine was about the units
On 1/31/07, Yonik Seeley (JIRA) <[EMAIL PROTECTED]> wrote:
tutorial update: faceting, highlighting, etc
Key: SOLR-131
URL: https://issues.apache.org/jira/browse/SOLR-131
Project: Solr
Issue Type
On 1/30/07, Fuad Efendi <[EMAIL PROTECTED]> wrote:
After 8 hours:
552955 documents -> 554827
(average s: about 3000/hour, but many of them are currently updates of
existing records)
I'm afraid this still doesn't tell me much (other than it not having
to do with autocommit). A thread dump and
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469187
]
Mike Klaas commented on SOLR-126:
-
Ryan: looking good! A few comments:
- You notify the tracker that the document
On 1/29/07, Fuad Efendi <[EMAIL PROTECTED]> wrote:
1000
Makes me suspect overlapping searchers even more strongly. The
current autocommit implementation does not wait for the searcher to
finish warming...
-Mike
[
https://issues.apache.org/jira/browse/SOLR-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468485
]
Mike Klaas commented on SOLR-126:
-
A few high-level comments:
- commitTer/commitTing. It seems pedantic to gripe
On 1/29/07, Fuad Efendi <[EMAIL PROTECTED]> wrote:
Solr runs at Tomcat with 4Gb: -Xms4096M -Xmx4096M
How much physical ram do you have on the machine? I'd suggest leaving
a healthy chunk free for the OS to cache the index.
-Mike
Hi Fuad,
Responses inline.
On 1/29/07, Fuad Efendi <[EMAIL PROTECTED]> wrote:
Thanks for response, I started crawler again trying to repeat the problem...
Already 1 hour, no any problem... Probably tomorrow evening I'll be ready to
execute kill -QUIT .
Great.
I have multithreaded SOLR-clie
Hi Fuad,
The point at which the thread is blocking is the only synchronization
on tracker, so another thread must be in the block. Is it possible
that another thread is stalled during commit? Do you have autowarming
enabled, and are these queries processor-intensive?
If it is in fact a deadloc
[
https://issues.apache.org/jira/browse/SOLR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466621
]
Mike Klaas commented on SOLR-80:
Hoss: thanks for the explanation.
I might throw this in our production code this
301 - 400 of 522 matches
Mail list logo
