che: Camel devfiles are not able to start because of OOMKilled

Describe the bug

The workspace is not started with the OOMKilled message shown. Same for Apache Camel K and Apache Camel based on Spring Boot devfiles.

Che version

  • latest
  • nightly
  • other: please specify 7.25.0

Steps to reproduce

  1. Go to Dashboard, click Get Started menu item, open Get Started tab.
  2. Select Apache Camel K project or Apache Camel based on Spring Boot devfile.
  3. Wait for the error to appear.

Expected behavior

Example devfiles should work out-of-the-box.

Runtime

  • kubernetes (include output of kubectl version)
  • Openshift (include output of oc version) 4.7
  • minikube (include output of minikube version and kubectl version)
  • minishift (include output of minishift version and oc version)
  • docker-desktop + K8S (include output of docker version and kubectl version)
  • other: (please specify) Hosted Che

Screenshots

Screenshot from 2021-02-01 11-48-29

Installation method

  • chectl
    • provide a full command that was used to deploy Eclipse Che (including the output)
    • provide an output of chectl version command
  • OperatorHub
  • I don’t know

Environment

  • my computer
    • Windows
    • Linux
    • macOS
  • Cloud
    • Amazon
    • Azure
    • GCE
    • other (please specify)
  • other: please specify - Linux OpenStack

Eclipse Che Logs

Error part:

2021-02-01 14:12:03,334[aceSharedPool-1]  [WARN ] [.i.k.KubernetesInternalRuntime 257]  - Failed to start Kubernetes runtime of workspace workspaceftoo1v6yq5wxqg7t.
org.eclipse.che.api.workspace.server.spi.InfrastructureException: The following containers have terminated:
vscode-apache-camelccf: reason = 'OOMKilled', exit code = 137, message = 'null'
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments.handleStartingPodStatus(KubernetesDeployments.java:465)
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments$2.eventReceived(KubernetesDeployments.java:378)
	at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments$2.eventReceived(KubernetesDeployments.java:375)
	at io.fabric8.kubernetes.client.utils.WatcherToggle.eventReceived(WatcherToggle.java:49)
	at io.fabric8.kubernetes.client.dsl.internal.WatchConnectionManager$1.onMessage(WatchConnectionManager.java:237)
	at okhttp3.internal.ws.RealWebSocket.onReadMessage(RealWebSocket.java:323)
	at okhttp3.internal.ws.WebSocketReader.readMessageFrame(WebSocketReader.java:219)
	at okhttp3.internal.ws.WebSocketReader.processNextFrame(WebSocketReader.java:105)
	at okhttp3.internal.ws.RealWebSocket.loopReader(RealWebSocket.java:274)
	at okhttp3.internal.ws.RealWebSocket$2.onResponse(RealWebSocket.java:214)
	at okhttp3.RealCall$AsyncCall.execute(RealCall.java:203)
	at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (15 by maintainers)

Commits related to this issue

Most upvoted comments

fixed in 7.26 and 7.25.1 (no milestone 7.25.1?)

created https://issues.redhat.com/browse/FUSETOOLS2-965 to investigate why it is requiring so much memory (but unless we have more precise pointers, I fear it won’t have an high priority)