[GitHub] [mina-sshd] jvz commented on a change in pull request #132: [SSHD-506] Add support for RFC 5647
jvz commented on a change in pull request #132:
URL: https://github.com/apache/mina-sshd/pull/132#discussion_r427733788
##
File path:
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
##
@@ -1334,9 +1362,19 @@ protected void decode() throws Exception {
assert decoderBuffer.rpos() == Integer.BYTES;
int macSize = (inMac != null) ? inMacSize : 0;
// Check if the packet has been fully received
-if (decoderBuffer.available() >= (decoderLength + macSize)) {
+if (decoderBuffer.available() >= (decoderLength + macSize +
authLen)) {
byte[] data = decoderBuffer.array();
-if (etmMode) {
+if (authMode) {
+final BaseGCMCipher cipher = (BaseGCMCipher) inCipher;
+cipher.incrementIV();
+// RFC 5647: packet length encoded in additional data
and unencrypted
+int off = decoderBuffer.rpos();
+cipher.updateAAD(data, off - Integer.BYTES,
Integer.BYTES);
+cipher.update(data, off, decoderLength);
+cipher.doFinal(data, Integer.BYTES + decoderLength);
Review comment:
Finally, I figured out one of the problems. This use of the Cipher class
is incorrect. When verifying an AT, that should be processed in `update` rather
than `doFinal`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work logged] (SSHD-506) Add support for aes128/256-gcm ciphers
[
https://issues.apache.org/jira/browse/SSHD-506?focusedWorklogId=435338=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-435338
]
ASF GitHub Bot logged work on SSHD-506:
---
Author: ASF GitHub Bot
Created on: 20/May/20 04:25
Start Date: 20/May/20 04:25
Worklog Time Spent: 10m
Work Description: jvz commented on a change in pull request #132:
URL: https://github.com/apache/mina-sshd/pull/132#discussion_r427733788
##
File path:
sshd-core/src/main/java/org/apache/sshd/common/session/helpers/AbstractSession.java
##
@@ -1334,9 +1362,19 @@ protected void decode() throws Exception {
assert decoderBuffer.rpos() == Integer.BYTES;
int macSize = (inMac != null) ? inMacSize : 0;
// Check if the packet has been fully received
-if (decoderBuffer.available() >= (decoderLength + macSize)) {
+if (decoderBuffer.available() >= (decoderLength + macSize +
authLen)) {
byte[] data = decoderBuffer.array();
-if (etmMode) {
+if (authMode) {
+final BaseGCMCipher cipher = (BaseGCMCipher) inCipher;
+cipher.incrementIV();
+// RFC 5647: packet length encoded in additional data
and unencrypted
+int off = decoderBuffer.rpos();
+cipher.updateAAD(data, off - Integer.BYTES,
Integer.BYTES);
+cipher.update(data, off, decoderLength);
+cipher.doFinal(data, Integer.BYTES + decoderLength);
Review comment:
Finally, I figured out one of the problems. This use of the Cipher class
is incorrect. When verifying an AT, that should be processed in `update` rather
than `doFinal`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 435338)
Time Spent: 0.5h (was: 20m)
> Add support for aes128/256-gcm ciphers
> --
>
> Key: SSHD-506
> URL: https://issues.apache.org/jira/browse/SSHD-506
> Project: MINA SSHD
> Issue Type: Improvement
>Reporter: Lyor Goldstein
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See:
> * [rfc5647|https://tools.ietf.org/html/rfc5647]
> *
> [draft-igoe-secsh-aes-gcm-01|https://tools.ietf.org/html/draft-igoe-secsh-aes-gcm-01]
> * [OpenSSH v6.2|http://www.openssh.com/txt/release-6.2]
> * [JAVA AES 256 GCM encrypt/decrypt
> example|https://javainterviewpoint.com/java-aes-256-gcm-encryption-and-decryption/]
> - especially the usage of {{GCMParameterSpec}} to initialize the cipher
> * [OpenJDK 8 AESCipher.java source
> code|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/AESCipher.java]
> ** See also
> [CipherCore.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/CipherCore.java],
>
> [FeedbackCipher.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/FeedbackCipher.java],
>
> [GaloisCounterMode.java|https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA & Project Loom
If they do something like deferring the blocking operation on to a real thread and use an async callback then the wasted cpu cycles is going to shoot through the roof but that might be a trade off acceptable to some. Uring was doing something similar using their worker thread model for AIO and the cpu usage skyrockets because the design is horribly inefficient so much that a newer version has a way to bypass it. On Tue, May 19, 2020 at 12:06 PM Jonathan Valliere wrote: > I expected they would have to change the IO API in some way to hack that > together. It will be interesting to see what they actually had to change. > The IO API is already hugely inefficient as-is compared to calling the > native functions directly via JNI. > > On Tue, May 19, 2020 at 11:49 AM Emmanuel Lécharny > wrote: > >> >> On 19/05/2020 17:25, Jonathan Valliere wrote: >> > Right, I’m not sure how loom is going to make any difference other than >> > being able to resource limit certain groups of threads. The problem >> With >> > virtual threads is pausing the thread during io; I’m not sure it is even >> > possible to do. >> >> >> "The following blocking operations are /virtual thread friendly in/ the >> current prototype; these methods do not pin the carrier thread when the >> operation blocks." >> >> (https://wiki.openjdk.java.net/display/loom/Networking+IO) >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org >> For additional commands, e-mail: dev-h...@mina.apache.org >> >>
Re: MINA & Project Loom
I expected they would have to change the IO API in some way to hack that together. It will be interesting to see what they actually had to change. The IO API is already hugely inefficient as-is compared to calling the native functions directly via JNI. On Tue, May 19, 2020 at 11:49 AM Emmanuel Lécharny wrote: > > On 19/05/2020 17:25, Jonathan Valliere wrote: > > Right, I’m not sure how loom is going to make any difference other than > > being able to resource limit certain groups of threads. The problem With > > virtual threads is pausing the thread during io; I’m not sure it is even > > possible to do. > > > "The following blocking operations are /virtual thread friendly in/ the > current prototype; these methods do not pin the carrier thread when the > operation blocks." > > (https://wiki.openjdk.java.net/display/loom/Networking+IO) > > > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > >
[jira] [Resolved] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[ https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein resolved SSHD-998. - Fix Version/s: 2.5.0 Resolution: Fixed > respect SftpVersionSelector when establishing a new connection > -- > > Key: SSHD-998 > URL: https://issues.apache.org/jira/browse/SSHD-998 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Holger Rehn >Assignee: Lyor Goldstein >Priority: Major > Labels: features, patch, performance > Fix For: 2.5.0 > > Attachments: patch.diff > > Time Spent: 20m > Remaining Estimate: 0h > > Even if using an SftpVersionSelector (e.g. created by > SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol > version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. > This behaviour is hard-coded and may cause problems if the server doesn't > correctly handle the request/support protocol version 6. One of our customers > is using a server that initially accepts protocol version 6, but then fails > every single request by sending invalid data. Actually, the server only > correctly supports SFTP 3, so this clearly is a bug in the server > implementation - but could be circumvented quite easily by starting with > protocol version 3. Furthermore an additional (and actually unnecessary) > version renegotiation may be required later. > If using an SftpVersionSelector that prefers a certain protocol version other > than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), > an additional (and actually unnecessary) network round trip is required for > protocol version renegotiation. > > Please find attached a minimally invasive patch against the official 2.4.0 > source to respect the version(s) accepted by an SftpVersionSelector for > choosing the initial protocol version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] lgoldstein closed pull request #133: [SSHD-998] Take into account SFTP version preference when establishing initial channel
lgoldstein closed pull request #133: URL: https://github.com/apache/mina-sshd/pull/133 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work logged] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[ https://issues.apache.org/jira/browse/SSHD-998?focusedWorklogId=435027=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-435027 ] ASF GitHub Bot logged work on SSHD-998: --- Author: ASF GitHub Bot Created on: 19/May/20 15:53 Start Date: 19/May/20 15:53 Worklog Time Spent: 10m Work Description: lgoldstein closed pull request #133: URL: https://github.com/apache/mina-sshd/pull/133 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 435027) Time Spent: 20m (was: 10m) > respect SftpVersionSelector when establishing a new connection > -- > > Key: SSHD-998 > URL: https://issues.apache.org/jira/browse/SSHD-998 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Holger Rehn >Assignee: Lyor Goldstein >Priority: Major > Labels: features, patch, performance > Attachments: patch.diff > > Time Spent: 20m > Remaining Estimate: 0h > > Even if using an SftpVersionSelector (e.g. created by > SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol > version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. > This behaviour is hard-coded and may cause problems if the server doesn't > correctly handle the request/support protocol version 6. One of our customers > is using a server that initially accepts protocol version 6, but then fails > every single request by sending invalid data. Actually, the server only > correctly supports SFTP 3, so this clearly is a bug in the server > implementation - but could be circumvented quite easily by starting with > protocol version 3. Furthermore an additional (and actually unnecessary) > version renegotiation may be required later. > If using an SftpVersionSelector that prefers a certain protocol version other > than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), > an additional (and actually unnecessary) network round trip is required for > protocol version renegotiation. > > Please find attached a minimally invasive patch against the official 2.4.0 > source to respect the version(s) accepted by an SftpVersionSelector for > choosing the initial protocol version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA & Project Loom
On 19/05/2020 17:25, Jonathan Valliere wrote: Right, I’m not sure how loom is going to make any difference other than being able to resource limit certain groups of threads. The problem With virtual threads is pausing the thread during io; I’m not sure it is even possible to do. "The following blocking operations are /virtual thread friendly in/ the current prototype; these methods do not pin the carrier thread when the operation blocks." (https://wiki.openjdk.java.net/display/loom/Networking+IO) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-966) Deadlock on disconnection at the end of key-exchange
[
https://issues.apache.org/jira/browse/SSHD-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111280#comment-17111280
]
Lyor Goldstein commented on SSHD-966:
-
I'll see what I can do
> Deadlock on disconnection at the end of key-exchange
>
>
> Key: SSHD-966
> URL: https://issues.apache.org/jira/browse/SSHD-966
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Francois Ferrand
>Assignee: Lyor Goldstein
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We are using git-repo to download projects from Gerrit server, using SSH.
> Gerrit is in version 2.16.16. which uses SSHD 2.0.0 and Mina 2.0.17 with NIO2
> backend.
> One particularity of this setup is that git-repo creates a single control
> master channel, and then downloads *lots* of Git repositories (500
> repositories, some of them relatively large), with some degree of
> parallelism. This takes a long time, lots of data, and the multiplexed
> connections are handled by gerrit in multiple threads.
> In some cases, we experience a deadlock when an error happens at the end of
> the key exchange, while sending pending packets:
> {noformat}
> Warning, the following threads are deadlocked : SSH git-upload-pack /project1
> (myuser), sshd-SshServer[df5f657]-nio2-thread-3
> "SSH git-upload-pack /project1 (myuser)" prio=1 BLOCKED
>
> org.apache.sshd.common.session.helpers.AbstractSession.writePacket(AbstractSession.java:1107)
>
> org.apache.sshd.common.channel.AbstractChannel.writePacket(AbstractChannel.java:798)
>
> org.apache.sshd.common.channel.ChannelOutputStream.flush(ChannelOutputStream.java:227)
>
> org.apache.sshd.common.channel.ChannelOutputStream.write(ChannelOutputStream.java:127)
>
> org.eclipse.jgit.transport.UploadPack$ResponseBufferedOutputStream.write(UploadPack.java:2183)
>
> org.eclipse.jgit.transport.SideBandOutputStream.writeBuffer(SideBandOutputStream.java:174)
>
> org.eclipse.jgit.transport.SideBandOutputStream.write(SideBandOutputStream.java:153)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.write(PackOutputStream.java:132)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs2(PackFile.java:614)
>
> org.eclipse.jgit.internal.storage.file.PackFile.copyAsIs(PackFile.java:433)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.copyObjectAsIs(WindowCursor.java:221)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjectImpl(PackWriter.java:1644)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObject(PackWriter.java:1621)
>
> org.eclipse.jgit.internal.storage.pack.PackOutputStream.writeObject(PackOutputStream.java:171)
>
> org.eclipse.jgit.internal.storage.file.WindowCursor.writeObjects(WindowCursor.java:229)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1609)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writeObjects(PackWriter.java:1597)
>
> org.eclipse.jgit.internal.storage.pack.PackWriter.writePack(PackWriter.java:1154)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:2133)
> org.eclipse.jgit.transport.UploadPack.sendPack(UploadPack.java:1947)
> org.eclipse.jgit.transport.UploadPack.service(UploadPack.java:971)
> org.eclipse.jgit.transport.UploadPack.upload(UploadPack.java:776)
> com.google.gerrit.sshd.commands.Upload.runImpl(Upload.java:77)
>
> com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:98)
>
> com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:31)
>
> com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:63)
> com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:467)
>
> com.google.gerrit.server.logging.LoggingContextAwareRunnable.run(LoggingContextAwareRunnable.java:83)
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:646)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> "sshd-SshServer[df5f657]-nio2-thread-3" daemon prio=5 BLOCKED
>
>
[GitHub] [mina-sshd] lgoldstein commented on a change in pull request #134: Fix a possible problem where an sftp chunked packet could be lost
lgoldstein commented on a change in pull request #134:
URL: https://github.com/apache/mina-sshd/pull/134#discussion_r427399422
##
File path:
sshd-sftp/src/main/java/org/apache/sshd/client/subsystem/sftp/impl/AbstractSftpClient.java
##
@@ -1308,6 +1308,9 @@ public FileChannel openRemoteFileChannel(String path,
Collection modes
@Override
public InputStream read(String path, int bufferSize, Collection
mode) throws IOException {
+if (bufferSize <= 0) {
+bufferSize = (int)
getClientChannel().getLocalWindow().getPacketSize() - 13;
Review comment:
Can we write a short comment why `-13`
##
File path:
sshd-sftp/src/main/java/org/apache/sshd/client/subsystem/sftp/impl/AbstractSftpClient.java
##
@@ -1329,6 +1332,9 @@ public InputStream read(String path, Collection
mode) throws IOExcepti
@Override
public OutputStream write(String path, int bufferSize,
Collection mode) throws IOException {
+if (bufferSize <= 0) {
+bufferSize = (int)
getClientChannel().getRemoteWindow().getPacketSize() - 13;
Review comment:
Can we write a short comment why -13
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111278#comment-17111278
]
Lyor Goldstein commented on SSHD-998:
-
{quote}
I tested your code and can confirm it works as expected.
{quote}
Thanks will merge...
> respect SftpVersionSelector when establishing a new connection
> --
>
> Key: SSHD-998
> URL: https://issues.apache.org/jira/browse/SSHD-998
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Holger Rehn
>Assignee: Lyor Goldstein
>Priority: Major
> Labels: features, patch, performance
> Attachments: patch.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Even if using an SftpVersionSelector (e.g. created by
> SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol
> version that is supported (namely 6) in the initial SSH_FXP_INIT datagram.
> This behaviour is hard-coded and may cause problems if the server doesn't
> correctly handle the request/support protocol version 6. One of our customers
> is using a server that initially accepts protocol version 6, but then fails
> every single request by sending invalid data. Actually, the server only
> correctly supports SFTP 3, so this clearly is a bug in the server
> implementation - but could be circumvented quite easily by starting with
> protocol version 3. Furthermore an additional (and actually unnecessary)
> version renegotiation may be required later.
> If using an SftpVersionSelector that prefers a certain protocol version other
> than 6 (custom or created by SftpVersionSelector.preferredVersionSelector),
> an additional (and actually unnecessary) network round trip is required for
> protocol version renegotiation.
>
> Please find attached a minimally invasive patch against the official 2.4.0
> source to respect the version(s) accepted by an SftpVersionSelector for
> choosing the initial protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[
https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111276#comment-17111276
]
Lyor Goldstein commented on SSHD-998:
-
{quote}Your changes will break backward compatibility though, but surely you
are aware of that.
{quote}
Yes but:
* It's not something major that would confuse programmers who upgrade to it
* The next release (2.5) also breaks other backward compatibility (hence
2.+*5*+)
> respect SftpVersionSelector when establishing a new connection
> --
>
> Key: SSHD-998
> URL: https://issues.apache.org/jira/browse/SSHD-998
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Holger Rehn
>Assignee: Lyor Goldstein
>Priority: Major
> Labels: features, patch, performance
> Attachments: patch.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Even if using an SftpVersionSelector (e.g. created by
> SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol
> version that is supported (namely 6) in the initial SSH_FXP_INIT datagram.
> This behaviour is hard-coded and may cause problems if the server doesn't
> correctly handle the request/support protocol version 6. One of our customers
> is using a server that initially accepts protocol version 6, but then fails
> every single request by sending invalid data. Actually, the server only
> correctly supports SFTP 3, so this clearly is a bug in the server
> implementation - but could be circumvented quite easily by starting with
> protocol version 3. Furthermore an additional (and actually unnecessary)
> version renegotiation may be required later.
> If using an SftpVersionSelector that prefers a certain protocol version other
> than 6 (custom or created by SftpVersionSelector.preferredVersionSelector),
> an additional (and actually unnecessary) network round trip is required for
> protocol version renegotiation.
>
> Please find attached a minimally invasive patch against the official 2.4.0
> source to respect the version(s) accepted by an SftpVersionSelector for
> choosing the initial protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA & Project Loom
Right, I’m not sure how loom is going to make any difference other than being able to resource limit certain groups of threads. The problem With virtual threads is pausing the thread during io; I’m not sure it is even possible to do. The cool idea of virtual threads would be that I could make a bunch of threads share a single core which prevents a thread pool from locking up the entire system. This is one of the reasons why having 2x core processor threads can lead to a softirq attack locking up the system during very small message DOS. On Tue, May 19, 2020 at 11:14 AM Emmanuel Lécharny wrote: > > On 19/05/2020 16:01, Jonathan Valliere wrote: > > I’ll have to look at it but generally speaking virtual threads are not > for > > us because they cannot be paused during blocking operations within the > > kernel space so you can’t have ten virtual threads blocked on a kernel > > action on a single process thread. > > > > Java once had “green” threads back in version 3 or so but was removed and > > migrated to full threads. > > > Java 1.1. It was removed in 1.2. The reason is that even with green > threads, the JVM was running on one single thread, so performance wise, > it was just not an improvement, unless you had threads waiting for IOs. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > >
Re: MINA & Project Loom
On 19/05/2020 16:01, Jonathan Valliere wrote: I’ll have to look at it but generally speaking virtual threads are not for us because they cannot be paused during blocking operations within the kernel space so you can’t have ten virtual threads blocked on a kernel action on a single process thread. Java once had “green” threads back in version 3 or so but was removed and migrated to full threads. Java 1.1. It was removed in 1.2. The reason is that even with green threads, the JVM was running on one single thread, so performance wise, it was just not an improvement, unless you had threads waiting for IOs. - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA & Project Loom
I’ll have to look at it but generally speaking virtual threads are not for us because they cannot be paused during blocking operations within the kernel space so you can’t have ten virtual threads blocked on a kernel action on a single process thread. Java once had “green” threads back in version 3 or so but was removed and migrated to full threads. On Tue, May 19, 2020 at 3:36 AM Emmanuel Lécharny wrote: > Hi! > > this is an interesting development in Java, the addition of Virtual > Threads [1] through project Loom [2]. > > This may impact MINA significantly, as we may simply use the new IO > system [3] to leverage those virtual threads, simplifying the underlying > implementation (bottom line: one sessions <-> one VT). > > There is a synthetic description in this page [4], worth reading. > > > I don't know when we would expect this proposal to be integrated in > Java, but we could expect something available around Java 15 or 16, for > a final release in the LTS Java 17. A early-access version is already > available [5]. > > I wonder if this would be something we want to invest time beforehand, > just to be ready when Loom get available. > > > wdyt ? > > > [1] > > https://wiki.openjdk.java.net/display/loom/Differences+between+regular+Threads+and+virtual+Threads > > [2] https://wiki.openjdk.java.net/display/loom > > [3] (https://wiki.openjdk.java.net/display/loom/Networking+IO) > > [4] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html > > [5] http://jdk.java.net/loom/ > > > -- > - > Emmanuel Lécharny > CTO, Busit > > > - > To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org > For additional commands, e-mail: dev-h...@mina.apache.org > >
[jira] [Commented] (SSHD-998) respect SftpVersionSelector when establishing a new connection
[ https://issues.apache.org/jira/browse/SSHD-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111053#comment-17111053 ] Holger Rehn commented on SSHD-998: -- [~lgoldstein] I tested your code and can confirm it works as expected. Your changes will break backward compatibility though, but surely you are aware of that. Cheers, Holger > respect SftpVersionSelector when establishing a new connection > -- > > Key: SSHD-998 > URL: https://issues.apache.org/jira/browse/SSHD-998 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Holger Rehn >Assignee: Lyor Goldstein >Priority: Major > Labels: features, patch, performance > Attachments: patch.diff > > Time Spent: 10m > Remaining Estimate: 0h > > Even if using an SftpVersionSelector (e.g. created by > SftpVersionSelector.fixedVersionSelector), SSHD sends the maximum protocol > version that is supported (namely 6) in the initial SSH_FXP_INIT datagram. > This behaviour is hard-coded and may cause problems if the server doesn't > correctly handle the request/support protocol version 6. One of our customers > is using a server that initially accepts protocol version 6, but then fails > every single request by sending invalid data. Actually, the server only > correctly supports SFTP 3, so this clearly is a bug in the server > implementation - but could be circumvented quite easily by starting with > protocol version 3. Furthermore an additional (and actually unnecessary) > version renegotiation may be required later. > If using an SftpVersionSelector that prefers a certain protocol version other > than 6 (custom or created by SftpVersionSelector.preferredVersionSelector), > an additional (and actually unnecessary) network round trip is required for > protocol version renegotiation. > > Please find attached a minimally invasive patch against the official 2.4.0 > source to respect the version(s) accepted by an SftpVersionSelector for > choosing the initial protocol version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] gnodet opened a new pull request #134: Fix a possible problem where an sftp chunked packet could be lost
gnodet opened a new pull request #134: URL: https://github.com/apache/mina-sshd/pull/134 PR to validate the fix against CI This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
MINA & Project Loom
Hi! this is an interesting development in Java, the addition of Virtual Threads [1] through project Loom [2]. This may impact MINA significantly, as we may simply use the new IO system [3] to leverage those virtual threads, simplifying the underlying implementation (bottom line: one sessions <-> one VT). There is a synthetic description in this page [4], worth reading. I don't know when we would expect this proposal to be integrated in Java, but we could expect something available around Java 15 or 16, for a final release in the LTS Java 17. A early-access version is already available [5]. I wonder if this would be something we want to invest time beforehand, just to be ready when Loom get available. wdyt ? [1] https://wiki.openjdk.java.net/display/loom/Differences+between+regular+Threads+and+virtual+Threads [2] https://wiki.openjdk.java.net/display/loom [3] (https://wiki.openjdk.java.net/display/loom/Networking+IO) [4] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html [5] http://jdk.java.net/loom/ -- - Emmanuel Lécharny CTO, Busit - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
