<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 30/12/2020 16:04, Antonino Esposito
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC6tC99cUctUbhc5KH3-=Re+OPmaUvyXz=ZdeuM4Lu077UpxQw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi,
<div><br>
</div>
<div>in the latest weeks i'm working on the
Solr integration and immediately i've faced
the assertion failure errors, on 2.0.19,
2.2.9 and 2.3.11.3 servers in our network.</div>
<div>Reading the thread on debian ML, I
realize this issue is related to nested MIME
and it affects large mailboxes</div>
<div><br>
</div>
<div>In my case, the error in dovecot.log
pairs with the following on solr.log and it
seems the rows value has the same value of
the last UID recorded in the mailbox. </div>
<div><br>
</div>
<div>For your reference, here is the Solr
logs, where <b>2276996170</b> is the value
passed by Dovecot as rows number and it
clearly don't fit with the rows data type.</div>
<div><br>
</div>
<div>Have you had experienced the same
behaviour? Is there a workaround?</div>
<div>Thanks</div>
<div>Antonino</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>Whatever the reason for this happening, it would make sense not
to supply unbounded values to solr. <br>
</p>
<p>The "rows" value that is passed for a lookup on a single mailbox
is the value of the uidnext for the searched mailbox. For lookups
on multiple mailboxes there is a hard coded value:</p>
<p>#define SOLR_MAX_MULTI_ROWS 100000</p>
<p>If 100000 is a good maximum for lookups on multiple mailboxes it
could also be a good upper bound for lookups on single mailboxes
too.<br>
</p>
<p>My proposed patch, which stops too large "rows" values going to
solr is as follows. This doesn't solve the issue of why uidnext is
so large in the first place for the specific mailbox. Nevertheless
I think it makes sense both as a potential workaround to the
original issue and to incorporate it as a safeguard. If the
hard-coded value is too limiting, it could be made configurable.<br>
</p>
<p>diff -ur
dovecot-2.3.11.3-orig/src/plugins/fts-solr/fts-backend-solr.c
dovecot-2.3.11.3/src/plugins/fts-solr/fts-backend-solr.c<br>
---
dovecot-2.3.11.3-orig/src/plugins/fts-solr/fts-backend-solr.c
2020-08-12 14:20:41.000000000 +0200<br>
+++ dovecot-2.3.11.3/src/plugins/fts-solr/fts-backend-solr.c
2020-12-31 09:05:07.681897716 +0100<br>
@@ -838,7 +838,7 @@<br>
<br>
str = t_str_new(256);<br>
str_printfa(str,
"wt=xml&fl=uid,score&rows=%u&sort=uid+asc&q=%%7b!lucene+q.op%%3dAND%%7d",<br>
- status.uidnext);<br>
+ I_MIN(status.uidnext,SOLR_MAX_MULTI_ROWS));<br>
prefix_len = str_len(str);<br>
<br>
if (solr_add_definite_query_args(str, args, and_args)) {<br>
<br>
</p>
<p>John<br>
</p>
<p><br>
</p>
</body>
</html>