OutOfMemory-Error beim Build in der CI-Pipeline

[Zrebna]

Hi!

Beim Build eines Maven-Projektes in der CI-Pipeline kommt es zu einem OutOfMemoryError:

Caused by: java.lang.OutOfMemoryError: Java heap space

Das Problem ist, dass lokal vor dem Comitten alle Tests auch mittels 'mvn test' ausgeführt werden und dabei kommt es ja auch zu einem Maven-Build, wobei hier alles problemlos durchläuft.
Mittlerweile konnte ich in Erfahrung bringen, wieviel RAM der Pipeline zur Verfügung gestellt werden.
Die Vermutung lag nun darin, dass lokal deutlich mehr Speicher freigestellt wird.
In Intellij im Hauptmenü unter 'Help' -> 'Change Memory Settings', sehe ich aber, dass dort sogar weniger Speicher für den Heap (Maximum Heap Size) zur Verfügung steht, als remote. Trotzdem habe ich mal testweise den Wert dort halbiert, aber den Fehler konnte ich auch danach lokal nicht reproduzieren.

Hat Jemand schon einmal ein ähnliches Problem gehabt und hat evtl. Jemand eine Idee, wie ich das Problem lokal reproduzieren könnte und remote bzgl. dem
Pipeline-Run (nach einem Push, der die Pipeline triggert) und dort dem Maven-Build nach beheben kann?

Lg
Zrebna

 

[httpdigest]

Das, was du in den IntelliJ IDEA Settings unter "Help" -> "Change Memory Settings" siehst, ist der Speicher, den sich die IDE (also IntelliJ IDEA selbst) nehmen darf, also womit letztlich der Java/JVM Prozess der IDE gestartet wird. Das ist nicht der Speicher eines von der IDE gestarteten Prozesses, wie etwa eines Maven Build Prozesses. IntelliJ IDEA baut hier also dein Java Programm nicht und lässt die Tests hier also nicht in-process laufen, sondern startet dafür einen separaten Prozess, der dann eine separate JVM ausführt, in der dann Maven ausgeführt wird, welches dann wiederum den Build ausführt und die Tests startet.

 

[Zrebna]

Das, was du in den IntelliJ IDEA Settings unter "Help" -> "Change Memory Settings" siehst, ist der Speicher, den sich die IDE (also IntelliJ IDEA selbst) nehmen darf, also womit letztlich der Java/JVM Prozess der IDE gestartet wird. Das ist nicht der Speicher eines von der IDE gestarteten Prozesses, wie etwa eines Maven Build Prozesses. IntelliJ IDEA baut hier also dein Java Programm nicht und lässt die Tests hier also nicht in-process laufen, sondern startet dafür einen separaten Prozess, der dann eine separate JVM ausführt, in der dann Maven ausgeführt wird, welches dann wiederum den Build ausführt und die Tests startet.

Ah ok, danke schonmal.

Das heißt quasi, dass es bei diesem Setting eben nicht um den Speicher für für separate Prozesse, wie für den Build-Prozess von Maven geht.

 

[Zrebna]

Ah ok, danke schonmal.

Das heißt quasi, dass es bei diesem Setting eben nicht um den Speicher für für separate Prozesse, wie für den Build-Prozess von Maven geht.

Ich hab jetzt in den Umgebungsvariablen in den Systemvariablen eine MAVEN_OPTS mit folgendem Wert gesetzt: -Xms512m -Xmx512m.
Und jetzt failt die Testausführung lokal.

Nach dieser Heap-Exception kam auch noch im Log in der Pipeline folgendes:

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'myController' defined in file [/home/xyz/work/1/s/target/classes/MyController.class]: Unsatisfied dependency expressed through constructor parameter 0: Error creating bean with name 'MyServiceImpl': Invocation of init method failed

Und genau diese obige error-message kommt nun auch lokal beim Fail der Testausführung.
Jedoch sind die Klassen korrekt annotiert - so wie in anderen Projekten, die Spring verwenden...Jemand da evtl. eine Idee?

So wären sie annotiert:

Controller:

@Slf4j
@RestController
@RequestMapping(BASE_URL)
public class MyController {

    public static final String BASE_URL = "xyz";

    
    private final MyService MyService;

    @Autowired
    public MyController(@Qualifier(MY_SERVICE_IMPL) MyService myService) {
        this.MyService = myService;
    }

Service-Klasse:

@Slf4j
@Service(MY_SERVICE_IMPL)
public class MyServiceImpl implements MyService {

...

 @PostConstruct
    private void init() {
      ...

 

[mrBrown]

Wie sieht denn die ganze Fehlermeldung inklusive Stacktrace aus?

Kann gut sein, dass der OutOfMemoryError der eigentliche Grund ist, das sollte aber durch Caused By etc erkennbar sein.

 

[Zrebna]

Wie sieht denn die ganze Fehlermeldung inklusive Stacktrace aus?

Kann gut sein, dass der OutOfMemoryError der eigentliche Grund ist, das sollte aber durch Caused By etc erkennbar sein.

Das wars auch - ein Aufruf im Programm nimmt braucht besonders viel Memory, weil die dort erzeugte Daten-Ressource remote immer größer wird. Deswegen lief auch lokal alles weiter und nur remote gingen die Pipelines nichts mehr durch - die RAM-Kapazität remote zu erhöhen hat das Problem gelöst.