[ 
https://issues.apache.org/jira/browse/JAMES-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16549038#comment-16549038
 ] 

Matthieu Baechler commented on JAMES-2483:
------------------------------------------

Hi John,

Thank your very much for your feedback.

I guess you use the Spring version of James, right ?

The indexer is configured into indexer.xml file if it's the case.

The default value is luceneIndex which actually uses LuceneMessageSearchIndex 
and as far as I know compute indices in live and stores them on filesystem.

There's no reason for lucene to be so slow and it could very well be fixed if 
someone is willing to invest some time in it.

Having an implementation of indexer use PG features would be a very great 
solution, too, but it requires some investment.

There's also an ElasticSearch indexer which is performing very well but sadly 
it doesn't work with Spring right now. 

The best solution if you can afford a ElasticSearch deployment would be to use 
a guice+jpa+elasticsearch combination. 

Feel free to join use on gitter.im here : https://gitter.im/apache/james-project

 

> Email search hogs processor
> ---------------------------
>
>                 Key: JAMES-2483
>                 URL: https://issues.apache.org/jira/browse/JAMES-2483
>             Project: James Server
>          Issue Type: Bug
>          Components: elasticsearch
>    Affects Versions: 3.0.1
>         Environment: Ubuntu 18.04 Server (Apache James with PostgreSQL 10)
> Ubuntu 16.04 Clients with Evolution configured to use IMAP+ accounts
>            Reporter: John Bester
>            Priority: Major
>              Labels: features, performance
>
> We have a James server with a database of about 17G in a LAN. There are 10 
> email clients - all Evolution running on top of Ubuntu 16.04. The James 
> server holds email in a Postgresql 10 database on an Ubuntu 18.04 Server VM. 
> The James installation is fairly new and all emails were copied from previous 
> local email boxes from the various workstations.
> Whenever someone tries to do a search, the James server completely comes to 
> grinding halt with all processors hogged at 100% (java/james - postgres 
> processes are all idle). This results in the entire office not being able to 
> do any email activity and the only way to get going again is to restart the 
> James service.
> This may be because of a search index being built, because having all 
> resources go into a search of one client does not seem like a good idea to 
> me. If it is index building, then why is this not done during the night and 
> why have indexes not been created even though the server have been running 
> for more than a month? As an alternative, why is James doing all the work 
> when there are full text indexes available in Postgres (and maybe other 
> database options as well)? Surely it would be possible to define a search 
> statement like all the other SQL statements are defined for a specific 
> database. And if the database cannot handle full text searches, then leave 
> the statement empty and fall back to whatever search algorithm is currently 
> used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to