ss to the keystore.
> Do you know if there is a way of specifying a different HttpClient
> implementation (e.g. DefaultHttpClient rather than
> SystemDefaultHttpClient) ?
>
>
>
>
>
>
>
> From: Uwe Klosa
> To: solr-user@lucene.apa
You have to add two new Java options to your Glassfish config (example if
you use the standard keystore and truststore):
asadmin create-jvm-options -- -Djavax.net.ssl.keyStorePassword=changeit
asadmin create-jvm-options -- -Djavax.net.ssl.trustStorePassword=changeit
/Uwe
On 10 April 2013 03:59,
I found the answer myself. Thanks for the pointer.
Cheers
Uwe
On 14 March 2013 16:48, Uwe Klosa wrote:
> Thanks, but nobody has tempered with keystores. I have tested the
> application on different machines. Always the same exception is thrown.
>
> Do we have to set some system
org/jira/browse/SOLR-4451 ?
>
> Just a guess.
>
> The root cause looks to be:
>
> > Caused by: java.io.IOException: Keystore was tampered with, or password
> was
> > incorrect
>
>
> - Mark
>
> On Mar 14, 2013, at 11:24 AM, Uwe Klosa wrote:
>
> > H
idea what could be the cause to this exception.
Cheers
Uwe Klosa
2009/7/1 Ben
> I'm not quite sure I understand exactly what you mean.
> The string I'm processing could have many tens of thousands of values... I
> hope you aren't implying I'd need to split it into many tens of thousands of
> "columns".
No, that is not what I meant. It will be one field (colu
split on commas?
>
> Ben
>
>
>
> Uwe Klosa wrote:
>
>> You should split the strings at the comma yourself and store the values in
>> a
>> multivalued field? Then wildcard search like A1_* are not a problem. I
>> don't
>> know so much about facets.
You should split the strings at the comma yourself and store the values in a
multivalued field? Then wildcard search like A1_* are not a problem. I don't
know so much about facets. But if they work on multivalued fields that
should be then no problem at all.
Uwe
2009/7/1 Ben
> Yes, I had done t
You have to escape all special characters. Even [ to \[
Have a look here http://lucene.apache.org/java/2_4_0/queryparsersyntax.html
Uwe
2009/7/1 Ben
> I only just noticed that this is an exception being thrown by the
> lucene.queryParser. Should I be mailing on the lucene list, or is it ok
> h
Hi
We have a problem with slow deleteById where one delete can take up to 30
minutes and the thread which initiated the deleteById is waiting for the
method to return. The problem is not that the delete takes so much time. The
problem is that the application that initiates deletes is halted that l
Hi
I have now recreated the whole index with new index files and all is back to
normal again. I think something had happend to our old index files.
Many thanks to you who tried to help.
Uwe
On Mon, Oct 6, 2008 at 5:39 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> I already had the
ingested
documents the commit time is 1-3 seconds. I'll get back tomorrow with more
results.
Uwe
On Sun, Oct 5, 2008 at 2:52 PM, Uwe Klosa <[EMAIL PROTECTED]> wrote:
> It's a live server with many search queries. I will set up a test server
> next week or the week after and in
It's a live server with many search queries. I will set up a test server
next week or the week after and index the same amount of documents. I will
get back with the results.
Uwe
On Sat, Oct 4, 2008 at 8:18 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 4, 2008 at 11:55
A "Opening Server" is always happening directly after "start commit" with no
delay. But I can see many {commit=} with QTime around 280.000 (4 and a half
minutes)
One difference I could see to your logging is that I have waitFlush=true.
Could that have this impact?
Uwe
On Sat, Oct 4, 2008 at 4:36
many files. Have you changed mergeFactor? Or
> implemented a custom DeletionPolicy or MergePolicy?
>
> Or... does anyone know of something else in Solr's configuration that could
> lead to such an insane number of files?
>
> Mike
>
>
> Uwe Klosa wrote:
>
> The
; filesystems. I think I've read that ReiserFS may have issues, though it
> could have been addressed by now. I *believe* ext3 is OK (at least, it
> didn't show the strange "sleep to get better performance" issue above, in my
> limited testing).
>
> Mike
>
&
the Solr
instances to another server with a different file system. Would the use of a
different file system than ext3 boost the performance?
Uwe
On Fri, Oct 3, 2008 at 8:28 PM, Michael McCandless <
[EMAIL PROTECTED]> wrote:
>
> Yonik Seeley wrote:
>
> On Fri, Oct 3, 2008 at
5 minutes for only one update is slow.
On Fri, Oct 3, 2008 at 8:13 PM, Fuad Efendi <[EMAIL PROTECTED]> wrote:
> Hi Uwe,
>
> 5 minutes is not slow; commit can't be realtime... I do commit&optimize
> once a day at 3:00AM. It takes 15-20 minutes, but I have several millions
> daily updates...
>
>
>
Hi
I have a big problem with one of my solr instances. A commit can take up to
5 minutes. This time does not depend on the number of documents which are
updated. The difference for 1 or 100 updated documents is only a few
seconds. I am running solr on tomcat 5.5 and java 1.6 on Solaris 10 on Sparc
y usage in that patch's javadoc
> worries me a little large index, lots of docs, lots of memory..
>
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
> ----- Original Message
> > From: Uwe Klosa <[EMAIL PROTECTED]>
> &
gt; Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
> - Original Message
> > From: Uwe Klosa <[EMAIL PROTECTED]>
> > To: solr-user@lucene.apache.org
> > Sent: Thursday, May 29, 2008 3:36:39 AM
> > Subject: Re: Sorting in different langu
On Wed, May 28, 2008 at 11:41 PM, Alexander Ramos Jardim <
[EMAIL PROTECTED]> wrote:
> Well,
>
> One solution that I can see for this problem is having different indexes
> for
> each language.
>
>
In which way would that solve the sorting problem?
Nice idea. I'll look into that, too.
Thanks
Uwe
On Tue, May 27, 2008 at 10:34 PM, Chris Hostetter <[EMAIL PROTECTED]>
wrote:
>
> : I think Solr should support syntax like "sort=title_sv asc locale:sv",
> : minimally including the language, but possibly also the country
> : component of the local
I've been thinking about that in similar ways. I'll have look into it.
Thanks
Uwe
On Tue, May 27, 2008 at 9:06 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote:
> Hi Uwe,
>
> On 05/26/2008 at 8:43 AM, Uwe Klosa wrote:
> > We're using Solr 1.3 in our application an
You should set uriEncoding="UTF-8" in your application server. For tomcat
you can do that in the server.xml. For Glassfish you have to create a
sun-web.xml containing the according parameters. Yoy r application server
should provide a similar mechanism.
Uwe
On Mon, Mar 31, 2008 at 4:32 PM, Daniel
25 matches
Mail list logo
