Workspaces stuck consuming 100% CPU since 5.17

We are experimenting with v5.17.0. It seems a bug has been introduced that causes che to get stuck (indefinitely) consuming 100% of the CPU when retrieving the project file tree.

I can reliably reproduce this by switching between v5.16.0 (where it doesn’t happen) to v5.17.0 where it does.

The process in question is the main workspace process:

/usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms256m -Xmx2048m -Djava.security.egd=file:/dev/./urandom -Dche.logs.dir=/home/user/che/ws-agent/logs -Dche.logs.level=INFO -Djuli-logback.configurationFile=file:/home/user/che/ws-agent/conf/tomcat-logger.xml -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -agentlib:jdwp=transport=dt_socket,address=4403,server=y,suspend=n -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dche.local.conf.dir=/mnt/che/conf -classpath /home/user/che/ws-agent/conf/:/usr/lib/jvm/java-1.8.0-openjdk-amd64/lib/tools.jar:/home/user/che/ws-agent/bin/bootstrap.jar:/home/user/che/ws-agent/bin/tomcat-juli.jar -Dcatalina.base=/home/user/che/ws-agent -Dcatalina.home=/home/user/che/ws-agent -Djava.io.tmpdir=/home/user/che/ws-agent/temp org.apache.catalina.startup.Bootstrap start

I’m happy to provide access to che devs to the workspace in question if that helps debug the issue.

Large project trees seem to be the most affected.

[ghost]

Btw, deleting git repo fixes the problem, but that’s, of course, not a solution.

[vinokurig]

analyzing