Hello all,
I have just started using the solr server in the tutorial they have given
an example which uses post.jar but i dont find the post.jar in the solr
download and i find only the post.sh, i work on a windows machine and sh
scripts dont work on the windows machine. can any one tell me where
Hi,
On 2/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
...I have just started using the solr server in the tutorial they have given
an example which uses post.jar but i dont find the post.jar in the solr
download and i find only the post.sh...
The tutorial on the website reflects the cu
Hello,
Thank you for the jar.
regards,
aditya
> Hi,
>
> On 2/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>> ...I have just started using the solr server in the tutorial they have
>> given
>> an example which uses post.jar but i dont find the post.jar in the solr
>> download and i f
I remember when using Lucene directly in a project, I noticed this error
only comes up if the system is deployed on UNIX boxes..in our case
SOLARIS.
You can increase the number of allowed "open files" on unix ..i forget
the command but the default is 256. We increased it, and the problem
went aw
This problem is different then the normal situation where you can
increase it with "ulimit -n XXX".
This is a real bug introduced by SOLR-104. As Yonik pointed out, the
filter does not close its request and when the searcher is opened for
an update (unnecessary) it hangs on to closed files indef
[
https://issues.apache.org/jira/browse/SOLR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reassigned SOLR-173:
-
Assignee: Hoss Man
this patch changes the public API of XMLWriter in a way that isn't backwards
compatible
[
https://issues.apache.org/jira/browse/SOLR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-173.
---
Resolution: Fixed
commited
> "too many open files" with posting to update handler
> --
: It probably would simplify some logic to assume unique keys are
: required, but we should think a little on it first. Would it make it
: harder to model existing random lucene indicies?
yeah ... because then people would be force client side to generate an
arbitrary unique key for each doc ...
On 2/26/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: It probably would simplify some logic to assume unique keys are
: required, but we should think a little on it first. Would it make it
: harder to model existing random lucene indicies?
yeah ... because then people would be force client
Thinking about this a bit more (I should do that *before* hitting the
send button!)
scratch the required="true" suggestion. If you send a request with
add.overwriteX and no id, it gives you an error (#2) if you want to
get behavior #1, you should have to send add.allowDups = true
[
https://issues.apache.org/jira/browse/SOLR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476002
]
Bertrand Delacretaz commented on SOLR-69:
-
See Ken Krugler's comments about term vectors at
http://www.nabble.c
I'm a little lost by your whole question ...
1) if there is a delcaration in your schema, then any
*MUST* have that field ... regardless of what overwrite or
allowDup options are specified.
2) overwrite and allowDups options *only* make sense if there is a
field defined in the schema ... i t
On 2/26/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
1) if there is a delcaration in your schema, then any
*MUST* have that field ... regardless of what overwrite or
allowDup options are specified.
That's not currently true. allowDups means no overwriting, and no
need for the id field in
: > 1) if there is a delcaration in your schema, then any
: > *MUST* have that field ... regardless of what overwrite or
: > allowDup options are specified.
:
: That's not currently true. allowDups means no overwriting, and no
: need for the id field in the doc being added. It provides a mech
[
https://issues.apache.org/jira/browse/SOLR-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-172:
---
Attachment: SOLR-172-uniqueKey-NPE.patch
Updated patch in responce to discussion. This version:
1. Th
to sneak in docs that don't match the mold/ don't have a unique id
(not sure if that's good or not).
Probably not a good idea, but I don't think we should change the
functionality with this patch, just the error message. SOLR-139,
requires a new add document command - that would be a good place
16 matches
Mail list logo
