Nope, I got this on the dovecot side. But I think the mailbox got
indexed anyway - I did a search and it returned results from that
mailbox after a few seconds. This is just amazing - have no idea why it
took me so long to get it.
Best,
Francis
On 2020-08-27 22:25, Alexandre Rafalovitch
Is this a Solr-side message? Looks like dovecot doing proactive
trimming of some crazy long header.
You can lookup the record by UID in the Admin UI (UID=153535 instead
of *:*) to check what is being indexed. Check that dovecot does not do
any prefixing of field names (any record from first
It works now! You were right - the files were on a different place. It
seems to be working now.
One last question:
I got this error:
400/49727doveadm(fran...@francisaugusto.com): Warning:
fts-solr(fran...@francisaugusto.com): Mailbox All Mail UID=153535 header
size is huge, truncating
Ok, you may want to step back and do a basic Solr example (download
matching version tgz file, decompress, "bin/solr -e techproducts" is a
good one, may need to shut the other Solr or give different port (-p
flag). Just so you know what you are looking at before dovecot starts
to introduce extra
I also noticed that I get this - maybe a permission error after all?
org.apache.solr.common.SolrException: Server error writing document id
1/a73b6e1ab8e4475f2bae1100c3fdd3da/fran...@med-lo.eu to the index
at
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:243)
Hi Alex and Erick,
Thanks for helping out.
True, restarting solr recreated the directory, but I still get 500
internal errors when reindexing from Dovecot.
Just to be clear: I delete the Data directory inside the
solr/data/dovecot directory.
All the directories are owned by solr:solr, so it
Uhm right. I may have forgotten to mention that you do need to reload
the core or maybe restart Solr server as well. If you literally just
deleted the index, Solr is probably freaking out about suddenly gone
files. It needs to redo the path of "is this the first time or do I
reopen the indexes"
“write.lock” is used by Lucene to insure that no two cores open the same index
because if they do, Bad Things Happen.
The “NoSuchFileException” may be a bit misleading, is there any chance that any
other core is looking at the same directory?
And your assertion: I then deleted the "data" under
Thanks Alex.
Well, I just deleted the whole data, and configured it again, and get
these errors from dovecot when indexing:
doveadm(fran...@francisaugusto.com): Error: fts_solr: Indexing failed:
500 Server Error
doveadm(fran...@francisaugusto.com): Error: Mailbox UOL: Mail search
failed:
Have you tried blowing the index directory away (usually 'data'
directory next to 'conf'). Because:
cannot change field "box" from index
options=DOCS_AND_FREQS_AND_POSITIONS to inconsistent index
options=DOCS
This implies that your field box had different definitions, you
updated it but the index
Hi,
I have - for a long time now - hoped to use an fts engine with dovecot.
My dovecot version is 2.3.7.2 under Ubuntu 20.04.
I installed solr 7.7.3 and then 8.6.0 to see if this was a
version-related error. I copied the schema from 7.7.0 as many people
said this was fine.
I get the
11 matches
Mail list logo