Lucee not working in commandbox all of a sudden

OS: win 11
java “1.8.0_331”
Newest lucee I think as of 4/22/22
I do a box server start like I usuall do, and now I get 127.0.0.1 didn’t send any data.on chrome…i even tried in wirh a on line test cfm. I tried to run the admin page the error console said
io.undertow.request.io: UT005090: Unexpected failure
java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:201)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:266)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:707)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:89)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1700)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:412)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:852)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2019)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1449)
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.lang.Thread.run(Unknown Source)
this is NOT a production server. maybe I can wipe out commandbox and start again?
contentbox express now says it can’ft find JRE

Don’t forget to tell us about your stack!

OS: ???
Java Version: ???
Tomcat Version: ???
Lucee Version: ???

Undertow while blindingly fast is nefariously unstable.

My suggestion, delete your users\currentUserName.commandbox directory and then install lucee express. Its far more stable and you can still use command box to download things, but you wont go though this.

Does it work on the latest stable version of Lucee? When you say “newest”, do you mean a snapshot build?

I’ve never seen this error before. Perhaps a jar is corrupted? I’d forget the server and restart it fresh.

Please be more specific. What specific command did you run and what specific error did you get? Can you screenshot it? This isn’t much to go on. Also, I’d recommend putting CommandBox and ContentBox questions in the Ortus Community Forum, not the Lucee one.

Hmm, I’ve never heard of such a thing. I’ve used Undertow for years in production and it’s as stable as anything.

This is far too heavy handed. If a specific server is having issues, just forget that server and re-start it. Wiping your entire CommandBox folder will lose all your settings, artifacts, servers, and JREs.

2 Likes

Hmm, I’ve never heard of such a thing. I’ve used Undertow for years in production and it’s as stable as anything.

Well though it may work for you, it doesn’t work for most enterprise environments nor is Adobe willing to bet one of their biggest cash cows on it.

We could go point by point, Instance by instance and look at why Undertow is a flaming pile best to be avoided at all costs, but in a word it comes down to does it work for the enterprise? No

Is it working for the guy who asked for help, NO
Did you offer to help the guy fix his instance of your product, which uses Lucee at its core, NO.

To the guy who needs help @anthonyehrhardt , @bdw429s makes a good point, You will want to copy any custom jars, code or libraries before you hit delete.

Undertow, not only has several glaring security holes still unpatched, but it breaks for far too many reasons for anyone to account for, including google. Tomcat, the biggest issue with Tomcat applications, you didn’t throw enough memory at it. Tomcat maybe slow, but it stable. Its actually more stable that Apache HTTPD, which is why Multiple governments and mega corporations in global 500 index use it from everything for personnel records to automated high volume trading. Added to the reliance and security is ColdFusion, which even if the code is in some cases older than the personnel using it, remains highly stable, secure, and easy enough to take any junior front end developer and have them build a web application faster than they could using another language.

Just an observation.

As for undertow so there are no misconceptions on how unstable it is:
Just a couple of the 1.2 million entries for Java undertow crashing

Why did it break, well command box latest stable appears to use an affected version of undertow:
https://issues.redhat.com/projects/UNDERTOW/issues/UNDERTOW-2073?filter=allopenissues
which leads to
https://bugs.openjdk.java.net/browse/JDK-8285445
which leads to what Anthony is using.

Lucee uses tomcat which doesnt has these issues.

giphy

4 Likes

@anthonyehrhardt As Terry pointed out, you seem to be unfortunate enough to have found an actual regression in the latest version of Java which affects the XNIO libraries that Undertow uses. So you have two quick and easy options here.

  • Back up a Java version.
  • Add a JVM arg which disables the new, broken Java behavior

The first bullet you can do this easily in CommandBox by asking it for a specific version. It would seem you need to back up to jdk8u312-b07 which you can set for your current server like so:

server set jvm.javaVersion=openjdk8_jdk8u312-b07

or all servers by default like so:

java setDefault openjdk8_jdk8u312-b07

For the second bullet, setting jdk.io.File.enableADS to true should also get rid of the issue and allow you to stay on the latest Java.

server set jvm.args=" -Djdk.io.File.enableADS=true"
1 Like

@anthonyehrhardt Just to put an update here, CommandBox 5.5. which shipped this week, contains a work around for this issue. All you need to do is update your CLI and we’ll add that JVM arg for you so everything works.