Ctrl-C after jetty:run produces NoClassDefFoundError

[sbordet]

Jetty version
10.0.x

Description
Starting Jetty 10 in a terminal window with the Jetty Maven Plugin via jetty:run, and then hitting ctrl-c produces:

Exception in thread "JettyShutdownThread" java.lang.NoClassDefFoundError: org/eclipse/jetty/util/BlockingArrayQueue$Itr
	at org.eclipse.jetty.util.BlockingArrayQueue.listIterator(BlockingArrayQueue.java:749)
	at java.base/java.util.AbstractList.listIterator(AbstractList.java:311)
	at org.eclipse.jetty.util.BlockingArrayQueue.iterator(BlockingArrayQueue.java:173)
	at java.base/java.util.AbstractCollection.toArray(AbstractCollection.java:142)
	at java.base/java.util.ArrayList.<init>(ArrayList.java:181)
	at org.eclipse.jetty.client.HttpDestination.abort(HttpDestination.java:482)
	at org.eclipse.jetty.client.HttpDestination.close(HttpDestination.java:412)
	at org.eclipse.jetty.client.HttpClient.doStop(HttpClient.java:242)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:137)
	at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:185)
	at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:208)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:137)
	at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:185)
	at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:208)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:137)
	at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThread.java:141)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jetty.util.BlockingArrayQueue$Itr
	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
	... 16 more

[janbartel]

What webapp?

[sbordet]

@janbartel with the CometD Demo WebApp. Not sure where that HttpClient being stopped comes from, I don't think it's CometD, especially not registered in ShutdownThread.

Could be the HttpClient used by WebSocket? @lachlan-roberts?

[lachlan-roberts]

@sbordet If you call ContainerProvider.getWebSocketContainer() it will register the JavaxWebSocketClientContainer with the shutdown thread and this contains an HttpClient so it could be the websocket one. But it is strange because the NoClassDefFoundError is for the jetty-util BlockingArrayQueue and not the HttpClient.

[olamy]

is this line https://github.com/eclipse/jetty.project/blob/06df421b56c62263311330b26b233c4dd27adca7/jetty-websocket/websocket-javax-client/src/main/java/org/eclipse/jetty/websocket/javax/client/JavaxWebSocketClientContainerProvider.java#L64 registering a shutdownHook?

[lachlan-roberts]

I think I've seen this before. See issue #4410.

In short, on Jetty stop/shutdown the maven process yanks the classloader out from underneath the Jetty threads (and Spring threads) leaving random errors in its wake.
This can happen with any version of Jetty and the Jetty Maven Plugin.
It's random, and can happen at any time, with no work around that we are aware of.

[olamy]

yes it's documented on maven core side (I don't remember the link). Maven core is very aggressive to close classloader. So when a registered shutdown hook try to run the context classloader has been closed and so classnotfound.

[olamy]

link http://maven.apache.org/plugin-developers/common-bugs.html#using-shutdown-hooks

[lachlan-roberts]

@sbordet when you do Ctrl-C, this will end up in the ShutdownThread for the server. So even if you have the JavaxWebSocketClientContainer attached to some LifeCycle in cometd you will still end up in the shutdown thread and may still encounter this maven bug.

Also the ContainerProvider.getWebSocketContainer() instance will be using the servers version of the jetty-util classes and not the version in the webapp for cometd. So calling addBean(container) in the ClientTransport.Factory will just be a NOOP as it is not an instance of the same LifeCycle class.

[sbordet]

So even if you have the JavaxWebSocketClientContainer attached to some LifeCycle in cometd you will still end up in the shutdown thread and may still encounter this maven bug.

I don't see how? If the component is already stopped, it will have removed itself from the ShutdownThread registration and should not end up trying to stop again.

[lachlan-roberts]

Fixed with PR #5840.