Uploaded image for project: 'James Server'
  1. James Server
  2. JAMES-2483

Email search hogs processor

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Abandoned
    • 3.0.1
    • None
    • elasticsearch
    • Ubuntu 18.04 Server (Apache James with PostgreSQL 10)
      Ubuntu 16.04 Clients with Evolution configured to use IMAP+ accounts
    • Important

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            stellenbosser John Bester
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: