On 16.08.23 11:51 , Slawomir Skalka wrote:
Given:
jdk 19.0.2.7 (Temurin)
sshd-core 2.10.0
sshd-common 2.10.0
slf4j-api 1.7.36
And: Windows.
attached code causes circa 50 exceptions:
Exception in thread "Thread-3" Exception in thread "Thread-2"
java.lang.IllegalStateException: Executor has been shut down
at
org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
at
org.apache.sshd.common.util.ValidateUtils.throwIllegalStateException(ValidateUtils.java:207)
at
org.apache.sshd.common.util.ValidateUtils.checkState(ValidateUtils.java:184)
at
org.apache.sshd.common.util.threads.NoCloseExecutor.execute(NoCloseExecutor.java:100)
at
java.base/sun.nio.ch.AsynchronousChannelGroupImpl.executeOnPooledThread(AsynchronousChannelGroupImpl.java:190)
at java.base/sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:215)
at java.base/sun.nio.ch.Invoker.invokeIndirectly(Invoker.java:316)
at
java.base/sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl$AcceptTask.failed(WindowsAsynchronousServerSocketChannelImpl.java:288)
at java.base/sun.nio.ch.Iocp$EventHandlerTask.run(Iocp.java:389)
at java.base/java.lang.Thread.run(Thread.java:1589)
Code causing exception:
public static void main(String[] args) throws Exception {
for (int i = 0; i < 100; i++) {
var sshd = SshServer.setUpDefaultServer();
var hostKeyProvider = new SimpleGeneratorHostKeyProvider(
Paths.get(".", "cert"));
hostKeyProvider.setAlgorithm(KeyUtils.RSA_ALGORITHM);
sshd.setKeyPairProvider(hostKeyProvider);
sshd.start();
sshd.stop(false);
}
}
This is just a code to easily reproduce the exception. In our product
we start and stop the server at a far way lower rate, but still we
observe the exception being thrown.
I wonder if there should be any additional method called after/before
server stop or if this is some kind of a bug, or is the server restart
somehow forbidden or unadvised?
No, this should work.
Or maybe it is this specific jvm fault
This problem appears to be specific to Windows. I cannot reproduce on OS
X, but I can easily reproduce on Windows.
This is actually an implementation difference in
AsynchronousServerSocketChannel between Unix and Windows.
The channel (used by the acceptor) is closed asynchronously, and there
is a java.nio.channels.AsynchronousCloseException to be reported.
The Unix implementation in
sun.nio.ch.UnixAsynchronousServerSocketChannelImpl calls the acceptor's
completion handler in Nio2Acceptor.AcceptCompletionHandler.onFailed()
directly.
The Windows implementation in
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl calls it
indirectly via the thread pool executor of the AsynchronousChannelGroup,
but that executor is already shut down.
Not sure if this is a JDK bug in the Windows implementation, or what we
could do about it. It looks like the underlying
OverlappedChannel.close() in the Windows implementation in the JDK is
asynchronous, and that there is a race with the shutdown of the executor.
Cheers,
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org
