the trick is to try to write first with the socket configured in non
blocking mode, so if it's congestion controlled , the write will
fail instantaneously so we en-queue the message and set the OP_WRITE flag
on the selection key.
On Tue, Jan 8, 2013 at 3:24 AM, Chad Beaulac cabeau...@gmail.com
[
https://issues.apache.org/jira/browse/SSHD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546750#comment-13546750
]
Guillaume Nodet commented on SSHD-149:
--
Sorry about the very long delay.
I've had a
[
https://issues.apache.org/jira/browse/SSHD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546754#comment-13546754
]
Guillaume Nodet commented on SSHD-149:
--
In addition, I think we may want to extract the
Non-blocking mode for all sockets for sure. I like the algorithm. Seems like
you almost certainly still avoid trying to write multiple times to a congestion
controlled socket which must not happen. I'll modify my code to try your
slightly different approach.
Chad
Sent from my iPhone
On Jan
I would add that just because you told the selectionKey to be ready for
a write by setting the OP_WRITE flag, and that the select() has been
interrupted because the underlying socket is ready to process a write
does not mean it's ready to be written when you try to do so : in the
mean time, the
Le 1/8/13 3:13 PM, Chad Beaulac a écrit :
Non-blocking mode for all sockets for sure. I like the algorithm. Seems like
you almost certainly still avoid trying to write multiple times to a
congestion controlled socket which must not happen.
Yes, this is exactly what we do. The kind of stuff
Understood on change in state between writable event firing and socket could
close by the time you goto write. In which case the read event would fire next
and result in zero bytes read signaling the socket is closed.
Your statement below is exactly what I have dealt with on many systems.
Hi guys,
it's time for a new report, as I have to post it by tomorrow (sorry for
posting it with such a short notice :/)
Here is a draft you could comment :
MINA board report draft :
--
Apache MINA is a network application
Andrew C created SSHD-202:
-
Summary: SSH Client silently accepts server key by default :-(
Key: SSHD-202
URL: https://issues.apache.org/jira/browse/SSHD-202
Project: MINA SSHD
Issue Type: Bug
Andrew C created SSHD-203:
-
Summary: SSH server doesn't know when auth completed
Key: SSHD-203
URL: https://issues.apache.org/jira/browse/SSHD-203
Project: MINA SSHD
Issue Type: Bug
Affects
Le 1/8/13 4:06 PM, Chad Beaulac a écrit :
Understood on change in state between writable event firing and socket could
close by the time you goto write. In which case the read event would fire
next and result in zero bytes read signaling the socket is closed.
Your statement below is
-- Forwarded message --
From: David Nalley (JIRA) j...@apache.org
Date: Tue, Jan 8, 2013 at 5:24 PM
Subject: [jira] [Commented] (INFRA-5736) SVN to GIT migration for MINA
project
To: jvermill...@apache.org
[
Just a clarification :
Chad, I don't want to fell like I'm arguing. I'm really trying to see if
the change I have pushed should be made optional, and if doing so will
really help when we are dealing with a congestion situation.
What I dont get is how waiting for the select() to wake up the
-- Forwarded message --
From: David Nalley (JIRA) j...@apache.org
Date: Tue, Jan 8, 2013 at 5:32 PM
Subject: [jira] [Commented] (INFRA-5736) SVN to GIT migration for MINA
project
To: jvermill...@apache.org
[
Oops, I totally forgot about the GIT migration...
(added into the development section)
Le 1/8/13 4:20 PM, Emmanuel Lécharny a écrit :
Hi guys,
it's time for a new report, as I have to post it by tomorrow (sorry for
posting it with such a short notice :/)
Here is a draft you could comment :
+1 for me
On Tue, Jan 8, 2013 at 5:44 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Oops, I totally forgot about the GIT migration...
(added into the development section)
Le 1/8/13 4:20 PM, Emmanuel Lécharny a écrit :
Hi guys,
it's time for a new report, as I have to post it by
[
https://issues.apache.org/jira/browse/DIRMINA-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff MAURY updated DIRMINA-922:
---
Attachment: NettyServer.patch
Added a Netty server and the 2 corresponding tests
Le 1/5/13 8:23 PM, Jeff MAURY a écrit :
I'm working on the netty server. It should be ok by the end of the week-end.
I just ran the NettyClient/NettyServer test you provided, using Java 7 :
NettyClient/NettyServer
10 : 38.308 - 26104/s
1024 : 39.383 - 25392/s
10240 : 49.132 - 20353/s
Hi Emmanuel.
It's all good. We want the same thing. I'm not feeling like we're arguing at
all. :-)
Understood on setting SO_SNDBUF.
I think your algorithm is good. The write before the select fires the write
event only when the queue is empty should be ok and it should lower initial
latency as
19 matches
Mail list logo
