[jira] [Work started] (SSHD-378) Switch to nio FileSystem api for commands (scp and sftp subsystem)
[ https://issues.apache.org/jira/browse/SSHD-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-378 started by Guillaume Nodet. Switch to nio FileSystem api for commands (scp and sftp subsystem) -- Key: SSHD-378 URL: https://issues.apache.org/jira/browse/SSHD-378 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (SSHD-379) Require JDK 1.7
[ https://issues.apache.org/jira/browse/SSHD-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-379 started by Guillaume Nodet. Require JDK 1.7 --- Key: SSHD-379 URL: https://issues.apache.org/jira/browse/SSHD-379 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SSHD-372) Server doesn't reject connections that don't send client identification, has to time out
[
https://issues.apache.org/jira/browse/SSHD-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned SSHD-372:
Assignee: Guillaume Nodet
Server doesn't reject connections that don't send client identification, has
to time out
Key: SSHD-372
URL: https://issues.apache.org/jira/browse/SSHD-372
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 0.14.0
Reporter: Robin Stocker
Assignee: Guillaume Nodet
Given a client that incorrectly tries to connect to Mina SSHD using HTTP
(such as a Git client using an incorrect remote URL), Mina SSHD is much less
strict than OpenSSH.
OpenSSH immediately closes the connection:
{noformat}
$ curl -v http://127.0.0.1:4722/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 4722 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:4722
Accept: */*
SSH-2.0-OpenSSH_6.6.1
Protocol mismatch.
* Connection #0 to host 127.0.0.1 left intact
$
{noformat}
Mina SSHD (master) waits for further input, and the connection is only closed
when the auth timeout is reached (2 minutes currently):
{noformat}
$ curl -v http://127.0.0.1:51328/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 51328 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:51328
Accept: */*
SSH-2.0-SSHD-CORE-0.13.1-SNAPSHOT
{noformat}
(In 0.9, there was also a bug that caused the auth timeout to never be
triggered, but that seems to have been fixed in 0.10 due to the work on
SSHD-282.)
The code for this is in {{AbstractSession#doReadIdentification}}. I'm not
sure if it should be as strict as OpenSSH ([which only looks at the first
line|https://github.com/openssh/openssh-portable/blob/146218ac11a1eb0dcade6f793d7acdef163b5ddc/sshd.c#L472]),
but maybe it would be worth to make this configurable.
A workaround is possible by providing a custom {{SessionFactory}} and
{{ServerSession}} and overriding {{doReadIdentification}}.
For background, see this Stash issue:
https://jira.atlassian.com/browse/STASH-5480
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SSHD-393) Ssh server freezing when under heavy load
[ https://issues.apache.org/jira/browse/SSHD-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-393. -- Resolution: Fixed Fix Version/s: 0.14.0 Assignee: Guillaume Nodet Thx for the patch. https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=commitdiff;h=0ebd488da3030f553a1b82c0d14879044985a67a Ssh server freezing when under heavy load - Key: SSHD-393 URL: https://issues.apache.org/jira/browse/SSHD-393 Project: MINA SSHD Issue Type: Bug Affects Versions: 0.12.0, 0.13.0 Reporter: Maros Marsalek Assignee: Guillaume Nodet Fix For: 0.14.0 When using the Ssh server and writing big amounts of data towards the client, server can freeze waiting for window adjust msg. It always happens after server gets into state of delaying write while waiting for window adjust. After the window adjust is received, write is not resumed. There is no mechanism to resume the write for server side, but on the client side there is. We have a junit test case that reproduces this issue. We were able to fix it with this patch: https://github.com/apache/mina-sshd/pull/10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-408) Implement sftp v4, v5 and v6
[ https://issues.apache.org/jira/browse/SSHD-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316361#comment-14316361 ] Guillaume Nodet commented on SSHD-408: -- Actually, it's really related to SSHD-377. The FileSystem api will work slightly better on top of a sftp v6 implementation, see https://github.com/gnodet/mina-sshd/commits/filesystem Implement sftp v4, v5 and v6 Key: SSHD-408 URL: https://issues.apache.org/jira/browse/SSHD-408 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SSHD-372) Server doesn't reject connections that don't send client identification, has to time out
[
https://issues.apache.org/jira/browse/SSHD-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved SSHD-372.
--
Resolution: Fixed
Fix Version/s: 0.14.0
https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=commitdiff;h=709aa932748d5f6fe28b1d0bdb9d8f6659245694
Server doesn't reject connections that don't send client identification, has
to time out
Key: SSHD-372
URL: https://issues.apache.org/jira/browse/SSHD-372
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 0.14.0
Reporter: Robin Stocker
Assignee: Guillaume Nodet
Fix For: 0.14.0
Given a client that incorrectly tries to connect to Mina SSHD using HTTP
(such as a Git client using an incorrect remote URL), Mina SSHD is much less
strict than OpenSSH.
OpenSSH immediately closes the connection:
{noformat}
$ curl -v http://127.0.0.1:4722/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 4722 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:4722
Accept: */*
SSH-2.0-OpenSSH_6.6.1
Protocol mismatch.
* Connection #0 to host 127.0.0.1 left intact
$
{noformat}
Mina SSHD (master) waits for further input, and the connection is only closed
when the auth timeout is reached (2 minutes currently):
{noformat}
$ curl -v http://127.0.0.1:51328/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 51328 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:51328
Accept: */*
SSH-2.0-SSHD-CORE-0.13.1-SNAPSHOT
{noformat}
(In 0.9, there was also a bug that caused the auth timeout to never be
triggered, but that seems to have been fixed in 0.10 due to the work on
SSHD-282.)
The code for this is in {{AbstractSession#doReadIdentification}}. I'm not
sure if it should be as strict as OpenSSH ([which only looks at the first
line|https://github.com/openssh/openssh-portable/blob/146218ac11a1eb0dcade6f793d7acdef163b5ddc/sshd.c#L472]),
but maybe it would be worth to make this configurable.
A workaround is possible by providing a custom {{SessionFactory}} and
{{ServerSession}} and overriding {{doReadIdentification}}.
For background, see this Stash issue:
https://jira.atlassian.com/browse/STASH-5480
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SSHD-408) Implement sftp v4, v5 and v6
[ https://issues.apache.org/jira/browse/SSHD-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SSHD-408 started by Guillaume Nodet. Implement sftp v4, v5 and v6 Key: SSHD-408 URL: https://issues.apache.org/jira/browse/SSHD-408 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-372) Server doesn't reject connections that don't send client identification, has to time out
[
https://issues.apache.org/jira/browse/SSHD-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316491#comment-14316491
]
Guillaume Nodet commented on SSHD-372:
--
The spec also says:
The server MAY send other lines of data before sending the version
string. Each line SHOULD be terminated by a Carriage Return and Line
Feed. Such lines MUST NOT begin with SSH-, and SHOULD be encoded
in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients
MUST be able to process such lines. Such lines MAY be silently
ignored, or MAY be displayed to the client user. If they are
displayed, control character filtering, as discussed in [SSH-ARCH],
SHOULD be used. The primary use of this feature is to allow TCP-
wrappers to display an error message before disconnecting.
That's why the code is written this way. But this only apply to the client
side, so i'll enhance the server to fail fast.
Server doesn't reject connections that don't send client identification, has
to time out
Key: SSHD-372
URL: https://issues.apache.org/jira/browse/SSHD-372
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 0.14.0
Reporter: Robin Stocker
Assignee: Guillaume Nodet
Fix For: 0.14.0
Given a client that incorrectly tries to connect to Mina SSHD using HTTP
(such as a Git client using an incorrect remote URL), Mina SSHD is much less
strict than OpenSSH.
OpenSSH immediately closes the connection:
{noformat}
$ curl -v http://127.0.0.1:4722/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 4722 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:4722
Accept: */*
SSH-2.0-OpenSSH_6.6.1
Protocol mismatch.
* Connection #0 to host 127.0.0.1 left intact
$
{noformat}
Mina SSHD (master) waits for further input, and the connection is only closed
when the auth timeout is reached (2 minutes currently):
{noformat}
$ curl -v http://127.0.0.1:51328/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 51328 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:51328
Accept: */*
SSH-2.0-SSHD-CORE-0.13.1-SNAPSHOT
{noformat}
(In 0.9, there was also a bug that caused the auth timeout to never be
triggered, but that seems to have been fixed in 0.10 due to the work on
SSHD-282.)
The code for this is in {{AbstractSession#doReadIdentification}}. I'm not
sure if it should be as strict as OpenSSH ([which only looks at the first
line|https://github.com/openssh/openssh-portable/blob/146218ac11a1eb0dcade6f793d7acdef163b5ddc/sshd.c#L472]),
but maybe it would be worth to make this configurable.
A workaround is possible by providing a custom {{SessionFactory}} and
{{ServerSession}} and overriding {{doReadIdentification}}.
For background, see this Stash issue:
https://jira.atlassian.com/browse/STASH-5480
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SSHD-348) Some SSH threads get blocked in Object.wait() method forever
[
https://issues.apache.org/jira/browse/SSHD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316846#comment-14316846
]
Guillaume Nodet commented on SSHD-348:
--
~hugares Would it be possible to raise the log level for
org.apache.sshd.server.channel.ChannelSession to debug and send me the
corresponding server log ?
Some SSH threads get blocked in Object.wait() method forever
Key: SSHD-348
URL: https://issues.apache.org/jira/browse/SSHD-348
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 0.10.0, 0.10.1, 0.11.0, 0.12.0, 0.13.0
Environment: Gerrit Code Review 2.9.1 (SSHD 0.12.0)
Gerrit Code Review 2.9.2 (SSHD 0.13.0)
Gerrit Code Review 2.9.3 (Downgraded to SSHD 0.9)
Reporter: David Ostrovsky
Assignee: Guillaume Nodet
Priority: Blocker
Fix For: 0.14.0
Attachments: 0001-Prepare-release-sshd-0.13.0-72f868e26.patch, diff,
threaddump.txt
This seems to be a regression started from 0.10.1.
In Gerrit we have SSH commamds that returns immediately and so called
stream-events command which keeps connection open until clients disconnect.
Basically for days or weeks. This is used for example to inform CI system
(jenkins) about events in gerrit, like new patch set upload etc.
In Gerrit we have configurable SSH-Stream-Worker thread pool which is
dedicated to the mentioned stream-events SSH command. The observed behaviour
on latest SSHD release is that after some time all threads are stuck. They
aren't stuck at the same time, but one after another untill at some time all
threads are stuck and Gerrit must be restarted. Usually after one week. The
stack dump of all such stuck thread are the same, see below. If we had a
patch we could apply it to our production Gerrit instance and try if this
helps.
{code}
SSH-Stream-Worker-10 cpu=95400.00 [reset 95400.00] ms elapsed=146444.30
[reset 146444.30] s allocated=552670 B (5.15 GB) [reset 552670 B
(5.15 GB)] defined_classes=0
io= file i/o: 15622752/0 B, net i/o: 0/0 B, files opened:0, socks opened:0
[reset file i/o: 15622752/0 B, net i/o: 0/0 B, files opened:0, socks opened:0
]
prio=10 tid=0x7f54514df800 nid=0x1c71 / 7281 pthread-id=13281374976
in Object.wait() [_thread_blocked (_at_safepoint),
stack(0x7f541f5f6000,0x7f541f6f7000)] [0x7f541f6f5000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(J)V(Native Method)
- waiting on 0x7f553aa530d0 (a
org.apache.sshd.common.channel.Window)
at java.lang.Object.wait()V(Object.java:503)
at
org.apache.sshd.common.channel.Window.waitForSpace()I(Window.java:148)
- locked 0x7f553aa530d0 (a org.apache.sshd.common.channel.Window)
at
org.apache.sshd.common.channel.ChannelOutputStream.flush()V(ChannelOutputStream.java:116)
- locked 0x7f553aa55060 (a
org.apache.sshd.common.channel.ChannelOutputStream)
at
org.apache.sshd.common.channel.ChannelOutputStream.write([BII)V(ChannelOutputStream.java:84)
- locked 0x7f553aa55060 (a
org.apache.sshd.common.channel.ChannelOutputStream)
at sun.nio.cs.StreamEncoder.writeBytes()V(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer()V(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush()V(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush()V(StreamEncoder.java:141)
- locked 0x7f553aa7e258 (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flush()V(OutputStreamWriter.java:229)
at java.io.BufferedWriter.flush()V(BufferedWriter.java:254)
- locked 0x7f553aa7e258 (a java.io.OutputStreamWriter)
at java.io.PrintWriter.flush()V(PrintWriter.java:320)
- locked 0x7f553aa7e210 (a java.io.BufferedWriter)
at java.io.PrintWriter.checkError()Z(PrintWriter.java:357)
at
com.google.gerrit.sshd.commands.StreamEvents.writeEvents()V(StreamEvents.java:186)
at
com.google.gerrit.sshd.commands.StreamEvents.access$100(Lcom/google/gerrit/sshd/commands/StreamEvents;)V(StreamEvents.java:43)
at
com.google.gerrit.sshd.commands.StreamEvents$3.run()V(StreamEvents.java:82)
at
java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;(Executors.java:471)
at java.util.concurrent.FutureTask.run()V(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Ljava/util/concurrent/ScheduledThreadPoolExecutor$ScheduledFutureTask;)V(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run()V(ScheduledThreadPoolExecutor.java:292)
at
[jira] [Commented] (SSHD-348) Some SSH threads get blocked in Object.wait() method forever
[
https://issues.apache.org/jira/browse/SSHD-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316901#comment-14316901
]
Guillaume Nodet commented on SSHD-348:
--
I would also very much like to have the command.done boolean value.
The command is the field on ChannelSession which is of type Command, but should
be an instance of com.google.gerrit.sshd.commands.StreamEvents which has a
boolean field done.
Some SSH threads get blocked in Object.wait() method forever
Key: SSHD-348
URL: https://issues.apache.org/jira/browse/SSHD-348
Project: MINA SSHD
Issue Type: Bug
Affects Versions: 0.10.0, 0.10.1, 0.11.0, 0.12.0, 0.13.0
Environment: Gerrit Code Review 2.9.1 (SSHD 0.12.0)
Gerrit Code Review 2.9.2 (SSHD 0.13.0)
Gerrit Code Review 2.9.3 (Downgraded to SSHD 0.9)
Reporter: David Ostrovsky
Assignee: Guillaume Nodet
Priority: Blocker
Fix For: 0.14.0
Attachments: 0001-Prepare-release-sshd-0.13.0-72f868e26.patch, diff,
threaddump.txt
This seems to be a regression started from 0.10.1.
In Gerrit we have SSH commamds that returns immediately and so called
stream-events command which keeps connection open until clients disconnect.
Basically for days or weeks. This is used for example to inform CI system
(jenkins) about events in gerrit, like new patch set upload etc.
In Gerrit we have configurable SSH-Stream-Worker thread pool which is
dedicated to the mentioned stream-events SSH command. The observed behaviour
on latest SSHD release is that after some time all threads are stuck. They
aren't stuck at the same time, but one after another untill at some time all
threads are stuck and Gerrit must be restarted. Usually after one week. The
stack dump of all such stuck thread are the same, see below. If we had a
patch we could apply it to our production Gerrit instance and try if this
helps.
{code}
SSH-Stream-Worker-10 cpu=95400.00 [reset 95400.00] ms elapsed=146444.30
[reset 146444.30] s allocated=552670 B (5.15 GB) [reset 552670 B
(5.15 GB)] defined_classes=0
io= file i/o: 15622752/0 B, net i/o: 0/0 B, files opened:0, socks opened:0
[reset file i/o: 15622752/0 B, net i/o: 0/0 B, files opened:0, socks opened:0
]
prio=10 tid=0x7f54514df800 nid=0x1c71 / 7281 pthread-id=13281374976
in Object.wait() [_thread_blocked (_at_safepoint),
stack(0x7f541f5f6000,0x7f541f6f7000)] [0x7f541f6f5000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(J)V(Native Method)
- waiting on 0x7f553aa530d0 (a
org.apache.sshd.common.channel.Window)
at java.lang.Object.wait()V(Object.java:503)
at
org.apache.sshd.common.channel.Window.waitForSpace()I(Window.java:148)
- locked 0x7f553aa530d0 (a org.apache.sshd.common.channel.Window)
at
org.apache.sshd.common.channel.ChannelOutputStream.flush()V(ChannelOutputStream.java:116)
- locked 0x7f553aa55060 (a
org.apache.sshd.common.channel.ChannelOutputStream)
at
org.apache.sshd.common.channel.ChannelOutputStream.write([BII)V(ChannelOutputStream.java:84)
- locked 0x7f553aa55060 (a
org.apache.sshd.common.channel.ChannelOutputStream)
at sun.nio.cs.StreamEncoder.writeBytes()V(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer()V(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush()V(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush()V(StreamEncoder.java:141)
- locked 0x7f553aa7e258 (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flush()V(OutputStreamWriter.java:229)
at java.io.BufferedWriter.flush()V(BufferedWriter.java:254)
- locked 0x7f553aa7e258 (a java.io.OutputStreamWriter)
at java.io.PrintWriter.flush()V(PrintWriter.java:320)
- locked 0x7f553aa7e210 (a java.io.BufferedWriter)
at java.io.PrintWriter.checkError()Z(PrintWriter.java:357)
at
com.google.gerrit.sshd.commands.StreamEvents.writeEvents()V(StreamEvents.java:186)
at
com.google.gerrit.sshd.commands.StreamEvents.access$100(Lcom/google/gerrit/sshd/commands/StreamEvents;)V(StreamEvents.java:43)
at
com.google.gerrit.sshd.commands.StreamEvents$3.run()V(StreamEvents.java:82)
at
java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;(Executors.java:471)
at java.util.concurrent.FutureTask.run()V(FutureTask.java:262)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Ljava/util/concurrent/ScheduledThreadPoolExecutor$ScheduledFutureTask;)V(ScheduledThreadPoolExecutor.java:178)
at
[jira] [Commented] (SSHD-372) Server doesn't reject connections that don't send client identification, has to time out
[
https://issues.apache.org/jira/browse/SSHD-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317320#comment-14317320
]
Robin Stocker commented on SSHD-372:
Thanks!
Server doesn't reject connections that don't send client identification, has
to time out
Key: SSHD-372
URL: https://issues.apache.org/jira/browse/SSHD-372
Project: MINA SSHD
Issue Type: Improvement
Affects Versions: 0.14.0
Reporter: Robin Stocker
Assignee: Guillaume Nodet
Fix For: 0.14.0
Given a client that incorrectly tries to connect to Mina SSHD using HTTP
(such as a Git client using an incorrect remote URL), Mina SSHD is much less
strict than OpenSSH.
OpenSSH immediately closes the connection:
{noformat}
$ curl -v http://127.0.0.1:4722/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 4722 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:4722
Accept: */*
SSH-2.0-OpenSSH_6.6.1
Protocol mismatch.
* Connection #0 to host 127.0.0.1 left intact
$
{noformat}
Mina SSHD (master) waits for further input, and the connection is only closed
when the auth timeout is reached (2 minutes currently):
{noformat}
$ curl -v http://127.0.0.1:51328/
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 51328 (#0)
GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: 127.0.0.1:51328
Accept: */*
SSH-2.0-SSHD-CORE-0.13.1-SNAPSHOT
{noformat}
(In 0.9, there was also a bug that caused the auth timeout to never be
triggered, but that seems to have been fixed in 0.10 due to the work on
SSHD-282.)
The code for this is in {{AbstractSession#doReadIdentification}}. I'm not
sure if it should be as strict as OpenSSH ([which only looks at the first
line|https://github.com/openssh/openssh-portable/blob/146218ac11a1eb0dcade6f793d7acdef163b5ddc/sshd.c#L472]),
but maybe it would be worth to make this configurable.
A workaround is possible by providing a custom {{SessionFactory}} and
{{ServerSession}} and overriding {{doReadIdentification}}.
For background, see this Stash issue:
https://jira.atlassian.com/browse/STASH-5480
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317500#comment-14317500 ] briokyd commented on DIRMINA-1006: -- The session was break at 14:30 PM after exception, the thread dump at 15:17 PM. I am confused why NioProcessor-931 keep read the broken socket. mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png, threadDump78658_20150211_151742.log running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-408) Implement sftp v4, v5 and v6
[ https://issues.apache.org/jira/browse/SSHD-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317721#comment-14317721 ] Goldstein Lyor commented on SSHD-408: - Perhaps, but if the majority of the clients use v3 what good would it do ? If you look at the [SFTP wiki|http://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol#History_and_development] then it states ```After a seven-year hiatus, in 2013 an attempt was made to restart work on SFTP using the version 3 draft as the baseline```. From this I infer that the versions 3 did not become popular. Anyway, I am not against it - I am just asking whether the development effort is cost-effective - after all, it would introduce more code, more potential bugs, etc. ? Has anyone specifically asked for it and gave a good justification ? Implement sftp v4, v5 and v6 Key: SSHD-408 URL: https://issues.apache.org/jira/browse/SSHD-408 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315874#comment-14315874 ] Emmanuel Lecharny commented on DIRMINA-1006: AFAICT, you have 25 threads reading on a socket. The thread dump does not show a lot beside that. mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png, threadDump78658_20150211_151742.log running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
briokyd created DIRMINA-1006: Summary: mina2.0.9 NioProcessor thread make cpu 100% Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] briokyd updated DIRMINA-1006: - Attachment: threadDump78658_20150211_151742.log threadDump log, same issue with NioProcessor-939 ,nid=0xf1b mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png, threadDump78658_20150211_151742.log running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315824#comment-14315824 ] Emmanuel Lecharny commented on DIRMINA-1006: Unlikely. We detect such a loop, and kill the selector when it happens. Can you attach a profiler to the running java process, to see what it's doing ? mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png, threadDump78658_20150211_151742.log running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] briokyd updated DIRMINA-1006: - Attachment: cpu100_03.png cpu100_02.png cpu100_01.png here is the screenshot mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DIRMINA-1006) mina2.0.9 NioProcessor thread make cpu 100%
[ https://issues.apache.org/jira/browse/DIRMINA-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14315871#comment-14315871 ] briokyd commented on DIRMINA-1006: -- thanks for response. normally NioProcessor thread exit after Exception, but sometimes it wouldn't. i will try install Jprofiler on the server. mina2.0.9 NioProcessor thread make cpu 100% --- Key: DIRMINA-1006 URL: https://issues.apache.org/jira/browse/DIRMINA-1006 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.9 Environment: Linux version 2.6.32-358.el6.x86_64 (Red Hat 4.4.7-3) java version 1.7.0_67 Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) Reporter: briokyd Priority: Blocker Attachments: cpu100_01.png, cpu100_02.png, cpu100_03.png, threadDump78658_20150211_151742.log running as client after the Exception (java.io.IOException: Connection reset by peer) appeared , cpu 100% thread dump: NioProcessor-931 prio=10 tid=0x7f3788004800 nid=0xd41 runnable [0x7f394f4f3000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) - locked 0x0007842118f0 (a sun.nio.ch.Util$2) - locked 0x0007842118e0 (a java.util.Collections$UnmodifiableSet) - locked 0x0007842114b0 (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at org.apache.mina.transport.socket.nio.NioProcessor.select(NioProcessor.java:97) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1074) at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Locked ownable synchronizers: - 0x000784211210 (a java.util.concurrent.ThreadPoolExecutor$Worker) is that nio epollWait bug? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (SSHD-401) Allow user control over ScpCommand send/receive buffer size
[ https://issues.apache.org/jira/browse/SSHD-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened SSHD-401: -- Now that I think about it, I wonder if a better way would be to pass customisation parameters through the FactoryManager. If a command implements SessionAware, it will receive the session that can be used to retrieve the FactoryManager and access all custom parameters. It would seem a bit cleaner to me, thoughts ? Allow user control over ScpCommand send/receive buffer size --- Key: SSHD-401 URL: https://issues.apache.org/jira/browse/SSHD-401 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.14.0 Reporter: Goldstein Lyor Assignee: Guillaume Nodet Priority: Minor Fix For: 0.14.0 Attachments: SSHD-395-to-401.diff While 8192 is a good rule-of-thumb value for I/O buffering, IMO we should allow users to fine-tune it to their needs. Attached is a patch suggestion. *Note*: the patch also optimizes the allocated I/O buffer by taking into consideration the *size* of the file it is expecting to send/receive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SSHD-401) Allow user control over ScpCommand send/receive buffer size
[ https://issues.apache.org/jira/browse/SSHD-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-401. -- Resolution: Fixed Ok, that makes sense Allow user control over ScpCommand send/receive buffer size --- Key: SSHD-401 URL: https://issues.apache.org/jira/browse/SSHD-401 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.14.0 Reporter: Goldstein Lyor Assignee: Guillaume Nodet Priority: Minor Fix For: 0.14.0 Attachments: SSHD-395-to-401.diff While 8192 is a good rule-of-thumb value for I/O buffering, IMO we should allow users to fine-tune it to their needs. Attached is a patch suggestion. *Note*: the patch also optimizes the allocated I/O buffer by taking into consideration the *size* of the file it is expecting to send/receive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-401) Allow user control over ScpCommand send/receive buffer size
[ https://issues.apache.org/jira/browse/SSHD-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316140#comment-14316140 ] Goldstein Lyor commented on SSHD-401: - I don't think so - I believe that specific settings are clearer - in this context see SSHD-407 patch that I posted. Also, passing customization parameters through the _FactoryManager_ is not type-safe - one has to use an oral agreement between the code that sets the parameter and the one the uses it. In our case, what if instead of an _ExecutorService_ we decide to use an _Executor_ ? The user's code will compile as before, but at runtime it will fail with _ClassCastException_. This way, if we change a type, the user's code will fail to compile and the change will be easier to catch and manage. Allow user control over ScpCommand send/receive buffer size --- Key: SSHD-401 URL: https://issues.apache.org/jira/browse/SSHD-401 Project: MINA SSHD Issue Type: Improvement Affects Versions: 0.14.0 Reporter: Goldstein Lyor Assignee: Guillaume Nodet Priority: Minor Fix For: 0.14.0 Attachments: SSHD-395-to-401.diff While 8192 is a good rule-of-thumb value for I/O buffering, IMO we should allow users to fine-tune it to their needs. Attached is a patch suggestion. *Note*: the patch also optimizes the allocated I/O buffer by taking into consideration the *size* of the file it is expecting to send/receive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SSHD-408) Implement sftp v4, v5 and v6
Guillaume Nodet created SSHD-408: Summary: Implement sftp v4, v5 and v6 Key: SSHD-408 URL: https://issues.apache.org/jira/browse/SSHD-408 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-393) Ssh server freezing when under heavy load
[ https://issues.apache.org/jira/browse/SSHD-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316209#comment-14316209 ] Maros Marsalek commented on SSHD-393: - What is going on with this issue and the pull request that fixes it ? Ssh server freezing when under heavy load - Key: SSHD-393 URL: https://issues.apache.org/jira/browse/SSHD-393 Project: MINA SSHD Issue Type: Bug Affects Versions: 0.12.0, 0.13.0 Reporter: Maros Marsalek When using the Ssh server and writing big amounts of data towards the client, server can freeze waiting for window adjust msg. It always happens after server gets into state of delaying write while waiting for window adjust. After the window adjust is received, write is not resumed. There is no mechanism to resume the write for server side, but on the client side there is. We have a junit test case that reproduces this issue. We were able to fix it with this patch: https://github.com/apache/mina-sshd/pull/10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SSHD-408) Implement sftp v4, v5 and v6
[ https://issues.apache.org/jira/browse/SSHD-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316213#comment-14316213 ] Goldstein Lyor commented on SSHD-408: - Is it really necessary ? AFAIK 3 is the most popular and widely support version - I am not even sure that users are aware of the various protocols or that any SFTP out there is actually implementing version 3. Is there a special feature, reason for this ? IMO, this may be nice-to-have - there are other issues more pressing... Implement sftp v4, v5 and v6 Key: SSHD-408 URL: https://issues.apache.org/jira/browse/SSHD-408 Project: MINA SSHD Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 0.14.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
