[ https://issues.apache.org/jira/browse/SSHD-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15950420#comment-15950420 ]
David Ostrovsky edited comment on SSHD-736 at 3/31/17 6:57 AM: --------------------------------------------------------------- I havn't mentioned that we have upgraded from 1.2.0 to 1.4.0 and the problem shows up. So, i used this commit bd713f4ca3fd9f4d8aa44bb60eb324be52dcd2c8 as the base (tagged with 1.2.0). I reverted the sshd upgrade to this version, and applied that patch to {{sshd-core}} to try to understand whether the same filesystem provider load code path was used in 1.2.0: {code} diff --git a/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java b/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java index 462e8fa..a69f3cb 100644 --- a/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java +++ b/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java @@ -248,6 +248,7 @@ public final class SecurityUtils { @SuppressWarnings("synthetic-access") private static void register() { if (!registrationDone) { + Thread.dumpStack(); if (registerBouncyCastle == null) { String propValue = System.getProperty(REGISTER_BOUNCY_CASTLE_PROP); if (!GenericUtils.isEmpty(propValue)) { {code} And launching the development Gerrit version from Eclipse, produced this stack traces: [1] and it works as expected. So the difference to 1.4.0, where it stopped working is that ThreadUtils.java wasn't involved in BC registration code path. So it seems to me, that this code path contributes to this problem: {noformat} at org.apache.sshd.common.util.threads.ThreadUtils.createDefaultInstance(ThreadUtils.java:107) at org.apache.sshd.common.util.security.SecurityUtils.register(SecurityUtils.java:396) {noformat} [~lgoldstein] Any clue how we could further investigate/troubleshoot that problem? Needless to say, this is very annoying, when your development environment is inherently broken. * [1] http://paste.openstack.org/show/605001 was (Author: davido2): I havn't mentioned that we have upgraded from 1.2.0 to 1.4.0 and the problem shows up. So, i used this commit bd713f4ca3fd9f4d8aa44bb60eb324be52dcd2c8 as the base (tagged with 1.2.0). I reverted the sshd upgrade to this version, and applied that patch to sshd-core to try to understand whether the same filesystem provider load code path was used in 1.2.0: {code} diff --git a/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java b/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java index 462e8fa..a69f3cb 100644 --- a/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java +++ b/sshd-core/src/main/java/org/apache/sshd/common/util/SecurityUtils.java @@ -248,6 +248,7 @@ public final class SecurityUtils { @SuppressWarnings("synthetic-access") private static void register() { if (!registrationDone) { + Thread.dumpStack(); if (registerBouncyCastle == null) { String propValue = System.getProperty(REGISTER_BOUNCY_CASTLE_PROP); if (!GenericUtils.isEmpty(propValue)) { {code} And launching the development Gerrit version from Eclipse, produced this stack traces: [1] and it works as expected. So the difference to 1.4.0, where it stopped working is that ThreadUtils.java wasn't involved in BC registration code path. So it seems to me, that this code path contributes to this problem: {noformat} at org.apache.sshd.common.util.threads.ThreadUtils.createDefaultInstance(ThreadUtils.java:107) at org.apache.sshd.common.util.security.SecurityUtils.register(SecurityUtils.java:396) {noformat} [~lgoldstein] Any clue how we could further investigate/troubleshoot that problem? Needless to say, this is very annoying, when your development environment is inherently broken. * [1] http://paste.openstack.org/show/605001 > Filesystem collision in development environment > ----------------------------------------------- > > Key: SSHD-736 > URL: https://issues.apache.org/jira/browse/SSHD-736 > Project: MINA SSHD > Issue Type: Question > Affects Versions: 1.4.0 > Environment: Linux, Gerrit > Reporter: David Ostrovsky > Priority: Minor > > In the development environment, we are using java filesystem, > to short circuit loading of servlets for the JavaScript Polymer UI. > Since upgrade to 1.4.0 Gerrit refuses to start in such dev environment. > I seems, that during start of FileSystem, it loads all file system providers > on the classpath. Since sshd-core is on the lcasspath, it's trying to load > also {{SftpFileSystemProvider}}, and is failing with class custom exception: > [1]. > Note, that we don't do that when booting release gerrit version, so we > do see this poblem only in the development environment. > We have 2 work arounds so far: disable file system usage in gerrit in this > code path: [2], or use custom built sshd-core version without this file[3]: > > {{sshd-core/src/main/filtered-resources/META-INF/services/java.nio.file.spi.FileSystemProvider}} > * [1] http://paste.openstack.org/show/604912 > * [2] http://paste.openstack.org/show/604911 > * [3] http://paste.openstack.org/show/604917 -- This message was sent by Atlassian JIRA (v6.3.15#6346)