[
https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741046#action_12741046
]
Noble Paul commented on SOLR-705:
-
Let us have a special field of something like _meta_ (to
hi,
im swamynathan a computer science engineering studying in jaya engg college
which is under anna univercity,chennai,India
as a part of my curriculam in the final year i need to do a proj.
i spoke with some solr users and programmers and found out that all content
that are indexed to it are
DIH: MultiThreaded
--
Key: SOLR-1352
URL: https://issues.apache.org/jira/browse/SOLR-1352
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Reporter: Noble Paul
First of all, why this is a solr-dev question?
Second it seems you have some strong misconceptions regarding what Solr is,
and what it is supposed to do.
Read up a bit on Solr wiki and text analyzers. If you still have questions,
ask them on solr-user mailing list.
Cheers
Avlesh
On Sun, Aug 9,
[
https://issues.apache.org/jira/browse/SOLR-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741047#action_12741047
]
Avlesh Singh commented on SOLR-1352:
Thanks, once again :), for creating the ticket,
ok
On Sun, Aug 9, 2009 at 1:22 PM, Avlesh Singh avl...@gmail.com wrote:
First of all, why this is a solr-dev question?
Second it seems you have some strong misconceptions regarding what Solr is,
and what it is supposed to do.
Read up a bit on Solr wiki and text analyzers. If you still have
[
https://issues.apache.org/jira/browse/SOLR-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741050#action_12741050
]
Avlesh Singh commented on SOLR-1348:
I have used cast() function in MySQL to convert my
There is also a whole lot unassigned still, we probably should at
least give them a glance to see if there is anything that slipped that
should be in 1.4
On Aug 8, 2009, at 6:34 PM, Yonik Seeley wrote:
24 open issues left - and nothing too difficult left. It's looking
like we should be to
On Aug 9, 2009, at 3:46 AM, swamynathan wrote:
hi,
im swamynathan a computer science engineering studying in jaya engg
college
which is under anna univercity,chennai,India
as a part of my curriculam in the final year i need to do a proj.
i spoke with some solr users and programmers and
[
https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1335:
-
Attachment: SOLR-1335.patch
with a testcase
load core properties from a properties file
I did some quick indexing performance tests right before and right
after the last lucene jar update - the results are not good... about
30% slower.
The test was an 80 MB text field, 100K documents, 6 short text fields
per document, with the solrconfig/schema from trunk copied to both
environments.
On Aug 9, 2009, at 10:29 AM, Yonik Seeley wrote:
I did some quick indexing performance tests right before and right
after the last lucene jar update - the results are not good... about
30% slower.
The test was an 80 MB text field, 100K documents, 6 short text fields
per document, with the
On Sun, Aug 9, 2009 at 12:01 PM, Grant Ingersollgsing...@apache.org wrote:
Or bite the bullet and upgrade to the incrementToken() method.
Right - I'm not sure if that would fix it or not - I haven't been
involved in the new Token attribute stuff...
I'm currently writing a basic indexing unit
OK, I've isolated (magnified) the effect with a test I just checked in.
Indexing documents directly at the UpdateHandler was 85% faster before
the latest lucene update.
Run the test like this:
ant test -Dtestcase=TestIndexingPerformance -Dargs=-server
-Diter=10; grep throughput
It looks like implementing the new attribute stuff will not be enough
- the token architecture has changed enough that it looks like we must
cache tokenstreams to get back to good performance.
-Yonik
http://www.lucidimagination.com
On Sun, Aug 9, 2009 at 12:57 PM, Yonik
FYI
https://issues.apache.org/jira/browse/SOLR-1353
On Sun, Aug 9, 2009 at 2:02 PM, Yonik Seeleyyo...@lucidimagination.com wrote:
It looks like implementing the new attribute stuff will not be enough
- the token architecture has changed enough that it looks like we must
cache tokenstreams to
implement reusable token streams for all Solr tokenizers / token filters
Key: SOLR-1353
URL: https://issues.apache.org/jira/browse/SOLR-1353
Project: Solr
Issue Type:
[
https://issues.apache.org/jira/browse/SOLR-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741134#action_12741134
]
Robert Muir commented on SOLR-1353:
---
Yonik, at least in the case of analyzer class=xxx, I
Are you sure that the initialization costs of the TokenStream/
AttributeSource cause the slowdown? With the bw-comp. code now every
call of a Token method goes through a delegation layer. I'm afraid
that might cause a slowdown?
The code that figures out what Attributes to put into the map
I am concerned about this one as well. Especially since the majority
of the language analyzers in lucene-contrib do not implement
reusableTokenStream.
On Sun, Aug 9, 2009 at 5:06 PM, Michael Buschbusch...@gmail.com wrote:
Are you sure that the initialization costs of the
Hey,
I've recently noticed that there is a very large spike in the QTime for
nodes serving queries, immediately after snappulling and snapinstalling.
The numbers i'm seeing there are obviously some kind of
lock-contention/concurrency issue, as I've monitored iostat/sar and its not
a disk IO
issue
Looks like there are a couple spots to blame, but mostly,
TokenStream$isMethodOverloaded takes most of the blame. Appears very slow.
- Mark
Mark Miller wrote:
Looks like there are a couple spots to blame, but mostly,
TokenStream$isMethodOverloaded takes most of the blame. Appears very
slow.
- Mark
Or its just called too often the way Solr does things for how fast it is.
Here are the profiling results:
Before
r801845
Experimental new feature: allow out-of-the-box apps by passing HTTP request
parameters through to XSL scripts
-
Key: SOLR-1354
URL:
[
https://issues.apache.org/jira/browse/SOLR-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated SOLR-1354:
Attachment: rss2.patch
Experimental new feature: allow out-of-the-box apps by passing HTTP request
[
https://issues.apache.org/jira/browse/SOLR-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741157#action_12741157
]
Lance Norskog commented on SOLR-1354:
-
This experiment has two aims:
1) It should be
[
https://issues.apache.org/jira/browse/SOLR-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated SOLR-1354:
Summary: Pass HTTP request parameters through to XSL scripts (was:
Experimental new feature: allow
Michael Busch wrote:
Are you sure that the initialization costs of the
TokenStream/AttributeSource cause the slowdown? With the bw-comp. code
now every call of a Token method goes through a delegation layer. I'm
afraid that might cause a slowdown?
Its isMethodOverriden and
isMethodOverriden is just nasty - copying Methods, security checks,
walking the type hierarchy, this, that, some more. I bet cglib has a
really fast version - too bad there is no built in equivalent.
Its not nearly as clean, but what if a new TokenStream simply identified
itself as supporting
29 matches
Mail list logo
