Thanks Chris for your suggestions.
I will take a look at SolrCloud work. It has a lot of points opened.
Perhaps, I can use Erlang language for high Availability and Fault Tolerance
in this environment.
Thank you so much Chris.
2010/4/29 Chris Hostetter
> : some ideas to define my thesis work
[
https://issues.apache.org/jira/browse/LUCENE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862530#action_12862530
]
Shai Erera commented on LUCENE-2422:
Mike - this patch is against an old revision? I'm
[
https://issues.apache.org/jira/browse/LUCENE-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862529#action_12862529
]
Shai Erera commented on LUCENE-2423:
I don't see any Lucene related classes in the sta
[
https://issues.apache.org/jira/browse/LUCENE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862528#action_12862528
]
Shai Erera commented on LUCENE-2420:
That documentation discusses the limitation aroun
[
https://issues.apache.org/jira/browse/LUCENE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Green updated LUCENE-2424:
--
Attachment: LUCENE-2424.patch
A very simple patch to fix this problem.
> FieldDoc.toString on
FieldDoc.toString only returns super.toString
-
Key: LUCENE-2424
URL: https://issues.apache.org/jira/browse/LUCENE-2424
Project: Lucene - Java
Issue Type: Bug
Components: Search
Affec
NullPointerException when attemping to add a new document to an instance of
IndexWriter
---
Key: LUCENE-2423
URL: https://issues.apache.org/jira/browse/LUCENE-2423
Pr
[
https://issues.apache.org/jira/browse/LUCENE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862463#action_12862463
]
Steven Bethard commented on LUCENE-2420:
I finally found the documentation saying
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862442#action_12862442
]
Lance Norskog commented on SOLR-1163:
-
bq. what I'll do, is take the current patch and m
Hello,
In the current version Hits object is Obsolete. How to use TopDocs? How can
I get Document from it?
How is the best way to use QueryParser?
What is the best way to maintain an index updated?
I would like to create an index from a database table.
I will create the first time index, but whe
> ExternalFileField reads the data from the file once (per searcher) and
> then stores it in an internal data structure just like hte FieldCache - so
> it should be just as fast at query time as anything you might write using
> a SolrCache.
>
And if Solr instantiates a new searcher, the Fie
[
https://issues.apache.org/jira/browse/LUCENE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862409#action_12862409
]
Lance Norskog commented on LUCENE-2373:
---
Grid filesystems like larger blocksizes. HD
[
https://issues.apache.org/jira/browse/LUCENE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862407#action_12862407
]
Lance Norskog commented on LUCENE-2373:
---
bq. Lance: yes. The original use case I had
[
https://issues.apache.org/jira/browse/LUCENE-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-2422:
---
Attachment: LUCENE-2422.patch
> don't reuse byte[] in IndexInput/Output for read/wri
don't reuse byte[] in IndexInput/Output for read/writeString
Key: LUCENE-2422
URL: https://issues.apache.org/jira/browse/LUCENE-2422
Project: Lucene - Java
Issue Type: Bug
[
https://issues.apache.org/jira/browse/SOLR-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862343#action_12862343
]
Hoss Man commented on SOLR-571:
---
bq. Since this was my first patch for Solr, I didn't want to m
[
https://issues.apache.org/jira/browse/SOLR-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862340#action_12862340
]
Tomás Fernández Löbbe commented on SOLR-571:
Excellent. Since this was my first p
: Yes, it's really a lot. I am not sure whether an ExternalFileField-source
: would work faster than a SolrCache (a lot of the needed data is always the
: same, so it's okay to store it in an external file). However: is it really
: more performant to get the metadata from there? Did you make any e
[
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862327#action_12862327
]
Eric Caron commented on SOLR-236:
-
Using the latest from trunk as of 2010-04-29, and the SOLR
: some ideas to define my thesis work in information retrieval area. I work
: with solr since 2 years and I am interested in performance topics and
: distributed search, In this moments, I find without ideas.
If i understand you correctly, you're looking for some areas of Solr that
you could s
[
https://issues.apache.org/jira/browse/LUCENENET-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Digy updated LUCENENET-359:
---
Attachment: LUCENENET-359.patch
Hi Ben,
Can you test the attached patch?
If it's OK, I will commit.
DIGY
[
https://issues.apache.org/jira/browse/LUCENE-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862312#action_12862312
]
Shai Erera commented on LUCENE-2420:
I remember that the Integer.MAX_VAL is documented
The data dir from the core descriptor should override the data dir from the
solrconfig.xml rather than the other way round
--
Key: SOLR-1897
UR
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862236#action_12862236
]
Uri Boness commented on SOLR-1163:
--
yeah... our repository has changed and some libs are mi
Correct.
Mathematically speaking, if you have all positive counts then you can't get
a negative score except possibly by round-off error.
On Thu, Apr 29, 2010 at 6:10 AM, Drew Farris wrote:
> I was under the (perhaps incorrect) impression that negative LLR indicates
> some sort of problem with
Guys, FYI RE: TIKA-400...
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW: http://sunset.usc.edu/~ma
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862231#action_12862231
]
Grant Ingersoll commented on SOLR-1163:
---
{quote}
1) org.gwtoolbox:gwtoolbox-ioc-core:j
Hi Peter,
You should be able to use LCF authorities for your purposes. I'm less clear
about what you mean by the "interface into decoupled acl storage". Existing
repository connectors are not aware of any decoupled storage, and if you were
to adopt the LCF model in its entirety, you've defeate
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862225#action_12862225
]
Peter Sturge commented on SOLR-1895:
That makes total sense to keep a proxy app separate
Yes, your point about filters vs queries is a good one. I do need to move
the fq building to the Lucene model.
It's true that in the case of, say, NTFS, there is already access control
built-in to the source files.
The differences are, as you pointed out, the ones that don't have this, and
also So
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862219#action_12862219
]
Karl Wright commented on SOLR-1895:
---
There's no "proxy app" in the jira post because I obv
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862215#action_12862215
]
Peter Sturge commented on SOLR-1895:
Right, ok, so you're using a proxy app to 'shield'
If we aren't talking about a repository of some kind, then we aren't talking
about using LCF. If your design point is about applying security to NFS via an
acl-xml file, your uploaded contribution will do that just fine (although I
think you might want to use Filters in some places you are curr
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862210#action_12862210
]
Karl Wright commented on SOLR-1895:
---
>>
I don't understand how localhost-only would gi
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862206#action_12862206
]
Peter Sturge commented on SOLR-1895:
{quote}
The usual way is to configure the applicati
Hi Karl,
- There's a significant extra load on the repository, because every search
result has to be checked against the repository in real time
By repository, do you mean, for example, NTFS? You certainly wouldn't want,
or need to do that at all, particularly for environments where the
repositor
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862193#action_12862193
]
Karl Wright commented on SOLR-1895:
---
>>
Given that search requests are http-based, how
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862191#action_12862191
]
Peter Sturge commented on SOLR-1895:
>>
The presumption is that the Solr webapp is n
Hardening of NativeFSLock
-
Key: LUCENE-2421
URL: https://issues.apache.org/jira/browse/LUCENE-2421
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Reporter: Shai Erera
+1 - hopefully upgrading over major releases doesn't become a nightmare
though.
On 4/29/10 6:09 AM, Michael McCandless wrote:
Reminder -- it's almost been 3 days for this vote -- anyone else want
to vote? I count these binding votes so far:
Robert +1
Shai +1
Uwe +1
Mich
[
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862181#action_12862181
]
Karel Braeckman commented on SOLR-236:
--
Hi all,
I wondered if it is possible to sort t
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862178#action_12862178
]
Karl Wright commented on SOLR-1895:
---
>>
Otherwise, security is compromised simply by g
Putting access control lookup at search-result time has the following benefits:
- It sees changes right away, when the underlying repository changes
Here are the drawbacks, as far as I can see:
- There's a significant extra load on the repository, because every search
result has to be checked a
I'm +0, mainly on terminology. I object to using the labels stable
and unstable for the names the branches. Simply call them what they
are, trunk and branch_3_1 (or whatever), and let quality judgement be
made elsewhere.
Erik
On Apr 29, 2010, at 6:09 AM, Michael McCandless wrote
I think that's a great idea Uwe ! It will reduce the chance for collision
even further.
After we've discussed this on IRC, Uwe raised an important point about why
the lock file must be deleted. It is possible that two JVMs will attempt to
lock the same Directory, one w/ Native and the other w/ Sim
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862150#action_12862150
]
Peter Sturge commented on SOLR-1895:
It's worth bearing in mind that more than just a us
Reminder -- it's almost been 3 days for this vote -- anyone else want
to vote? I count these binding votes so far:
Robert +1
Shai +1
Uwe +1
Michael +1
Grant+0.9
Doron+1
Hoss +0
me +1
Mike
On Mon, Apr 26, 2010 at 11:59 AM, Michael McCandless
wrote:
Hi Karl,
I guess it comes down to - any solution is ultimately going to place access
control on a search and not on data, so there isn't much to be gained by
binding the access control to the data. Whatever attributes exist at index
time to build an acl will still be there at query time, so by mak
A possibility to get something that does not depend on Date/Time and so on:
ManagementFactory.getRuntimeMXBean().getName()
This returns a unique identifier of the running Java VM. On most platforms,
this contains the process ID. Maybe we should use this as an additional
information for the test
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862140#action_12862140
]
Karl Wright commented on SOLR-1895:
---
One thing I forgot in the original description...
Th
[
https://issues.apache.org/jira/browse/SOLR-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated SOLR-1895:
--
Attachment: LCFSecurityFilter.java
Another revision that explicitly uses ConstantScoreQuery and filters
On Wed, Apr 28, 2010 at 1:52 PM, Shai Erera wrote:
> I use 1.6.0_18.
>
> Maybe seeding w/ System.nanoTime() will help, but don't you think
> NativeFSLock should be more robust anyway? Even for the regular lock
> file this can happen if at the same time delete() is attempted the
> file is held by a
52 matches
Mail list logo
