Uploaded image for project: 'SonarQube'
  1. SonarQube
  2. SONAR-4898

Start Elasticsearch in an isolated Java process

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.5
    • Component/s: ElasticSearch
    • Labels:
      None

      Description

      Having a separated process for ES allows to tune JVM settings and to not impact webserver process with garbage collector freezes. TransportClient should be used in order to connect to ES node : http://dev.david.pilato.fr/?p=185. The current integration load the ES cluster, node and client in the same process as the rest of the JVM. The main inpact of this is the increase in permanent generation memory (about 20MB) that should be reported in wrapper.conf.

      Implementing this feature requires to fully review the wrapper in charge to launch the SonarQube server.

      Here are the requirements for the new wrapper:

      • Black box for end-users -> only one command to start and stop SonarQube (whatever is the number of underlying java processes)
      • Memory requirement can increase up to 2 Go
      • One configuration file -> containing functional and technical properties
      • If one underlying java process fail -> all java processes should stop
      • Access to ES must be highly protected
      • Only one requirement -> installation of the JVM
      • Support for windows service
      • Should be possible to launch SonarQube

      Implementation details:

      • A lightweight SonarQube java Wrapper process must be first launched
      • This SQ Wrapper is in charge to :
        • Read the sonar.conf file
        • Launch the SQ node (all properties should be injected through the command line)
        • Launch the ES node (all properties should be injected through the command line)
      • This wrapper must remain alive and must ask the SQ node and ES node to send some heartbeats each X milliseconds on some dedicated ports
      • When the SQ or ES node don't manage to send the heartbeat -> the node should kill itself
      • When the wrapper don't receive an heartbeat from the SQ or ES node, after X milliseconds, the wrapper should kill the two nodes and should stop

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              simon.brandhof Simon Brandhof (Inactive)
              Reporter:
              jb.lievremont OLD - Jean-Baptiste Lièvremont (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Due:
                Created:
                Updated:
                Resolved: