similar to: Solr clusters

>Hi, > >we have activated fts-solr about a week ago and immediately started to >experience really *low* performance with MOVE and EXPUNGE commands. >After several days of googling, tcpdumping and straceing i was able to >find and resolve the problem. > >We are using Dovecot 2.2.27 from Debian Jessie (jessie-backports), >which is doing a soft commit in solr after

> I'm a denizen of the solr-user at lucene.apache.org mailing list. > [...] > Here's a wiki page that I wrote about that topic. This wiki is going > away next month, but for now you can still access it: > > https://wiki.apache.org/solr/SolrPerformanceProblems That's a great resource, Shawn. I am about to put together a test case to provide a comprehensive FTS

Greetings We are looking into a solution to set up full text search for our multiple Dovecot instances. According to the Dovecot Wiki, fts_solr is one of the recommended plugins to use. Since we have more than just a few hundred mailboxes, I guess one Solr instance will not suffice. So I took a look at SolrCloud and set up a small cluster with three nodes and shards. I have no preceding

Hi, guys, Can you give me an example of solr usage in dovecot? As far as I know, you can search email easily by MUA like outlook, so which role does solr play? And based on https://dovecot.org/pipermail/dovecot/2019-April/115575.html I'm going to use an VIP to host 2 mail servers. Currently, it works in fail over and fail back test except solr index, so how to resolve this? Is it

On 6/14/2019 2:11 AM, luckydog xf via dovecot wrote: > ? And based on https://dovecot.org/pipermail/dovecot/2019-April/115575.html > I'm going to use an VIP to host 2 mail servers. Currently, it works in > fail over and fail back test except solr index, so how to resolve this? Solr has high availability options. Probably the easiest is SolrCloud, because the legacy master-slave

Hi I have set up SOLR in accordance with documentation and it runs well. I use solr like: ....... fts = solr fts_solr = debug url=http://IP:8983/solr/ (solr in external machine) ...... Is replication of this system really essential ?? Due to my tests, rollback of the solr server on external machine lasts less than minute and it is nearly non-visible from client side. On the other hand solr

Hi, I am finally trying to use an fts engine with dovecot. My 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 following error when trying to reindex a user's mailbox: doveadm(francis at francisaugusto.com): Error: fts_solr: Indexing failed:

Hello, I have Dovecot configured with Solr for the indexes. I have need your support for upgrade solr 7.7.2 to 8.4.1. Solr 7.7.2 has a security issue CVE-2019-12409. It's possible upgrade of Solr? Dovecot work correctly with Solr 8.x? The Solr documentation recommended after updating: "It is always strongly recommended that you fully reindex your documents after a major version

Raghavendra, Sorry for the late follow up. I have some more data on the issue. The issue tends to happen when the shards are created. The easiest time to reproduce this is during an initial VM disk format. This is a log from a test VM that was launched, and then partitioned and formatted with LVM / XFS: [2018-04-03 02:05:00.838440] W [MSGID: 109048]

Sorry for the delay, Ian :). This looks to be a genuine issue which requires some effort in fixing it. Can you file a bug? I need following information attached to bug: * Client and bricks logs. If you can reproduce the issue, please set diagnostics.client-log-level and diagnostics.brick-log-level to TRACE. If you cannot reproduce the issue or if you cannot accommodate such big logs, please set

> On Apr 23, 2018, at 10:49 AM, WK <wkmail at bneit.com> wrote: > > From some old May 2017 email. I asked the following: > "From the docs, I see you can identify the shards by the GFID > # getfattr -d -m. -e hex path_to_file > # ls /bricks/*/.shard -lh | grep GFID > > Is there a gluster tool/script that will recreate the file? > > or can you just sort

Ian, Do you've a reproducer for this bug? If not a specific one, a general outline of what operations where done on the file will help. regards, Raghavendra On Mon, Mar 26, 2018 at 12:55 PM, Raghavendra Gowdappa <rgowdapp at redhat.com> wrote: > > > On Mon, Mar 26, 2018 at 12:40 PM, Krutika Dhananjay <kdhananj at redhat.com> > wrote: > >> The gfid mismatch

Does anyone have any ideas about how to fix, or to work-around the following issue? Thanks! Bug 1549714 - On sharded tiered volume, only first shard of new file goes on hot tier. https://bugzilla.redhat.com/show_bug.cgi?id=1549714 On sharded tiered volume, only first shard of new file goes on hot tier. On a sharded tiered volume, only the first shard of a new file goes on the hot tier, the rest

On 4/13/2019 4:29 AM, John Fawcett via dovecot wrote: > If this value was made configurable people could set it to what they > want. However the underlying problem is likely on solr configuration. The Jetty that is included in Solr has its idle timeout set to 50 seconds. But in practice, I have not seen this timeout trigger ... and if the OP is seeing a 60 second timeout, then the 50

On Mon, Mar 26, 2018 at 12:40 PM, Krutika Dhananjay <kdhananj at redhat.com> wrote: > The gfid mismatch here is between the shard and its "link-to" file, the > creation of which happens at a layer below that of shard translator on the > stack. > > Adding DHT devs to take a look. > Thanks Krutika. I assume shard doesn't do any dentry operations like rename,

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 14 April 2019 16:59 John Fawcett via dovecot < <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a>> wrote: </div>

__ Francis Augusto Medeiros-Logeay francis at francisaugusto.com Mobile: +47 45 17 14 91 Oslo, Norway Sent from a mobile device / Enviado a partir de dispositivo m?vel > On 24 Jul 2020, at 19:34, Shawn Heisey <elyograg at elyograg.org> wrote: > > ?On 7/22/2020 11:13 AM, Francis Augusto Medeiros-Logeay wrote: >> On Solr I get this error: >>

From some old May 2017 email. I asked the following: "From the docs, I see you can identify the shards by the GFID # getfattr -d -m. -e hex/path_to_file/ # ls /bricks/*/.shard -lh | grep /GFID Is there a gluster tool/script that will recreate the file? or can you just sort them sort them properly and then simply cat/copy+ them back together? cat shardGFID.1 .. shardGFID.X > thefile

Good thinking, but why do you think runtime selection of shard count is better than compile time selection? For single threaded apps, shard count is always 1, so why paying the penalty to check thread id each time function is entered? For multi-threaded apps, I would expect MAX to be smaller than NUM_OF_CORES to avoid excessive memory consumption, then you always end up with N == MAX. If MAX is

The gfid mismatch here is between the shard and its "link-to" file, the creation of which happens at a layer below that of shard translator on the stack. Adding DHT devs to take a look. -Krutika On Mon, Mar 26, 2018 at 1:09 AM, Ian Halliday <ihalliday at ndevix.com> wrote: > Hello all, > > We are having a rather interesting problem with one of our VM storage >