[ 
https://issues.apache.org/jira/browse/IGNITE-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318855#comment-15318855
 ] 

Dmitry Karachentsev commented on IGNITE-3054:
---------------------------------------------

1. Implemented SSL support.
2. Fixed bugs.
3. Checked resource consuming. Actually I've just started server node and 200 
client nodes, but don't see any difference in memory (probably there weren't 
counted threads stacks in Visual VM) or CPU consumption. Significant difference 
is observed only in number of live threads (as expected). No message processing 
velocity was measured. Here are some numbers:

Initial (no clients):
Threads: 76
Heap: 50 M

Master (200 clients):
Threads: 486
Heap: 120 M

NIO (200 clients):
Threads: 93
Heap: 100 M

4. Verified compatibility with previous version (master branch used).
5. Added pretty ugly workaround: Sometimes OutputStream from NIO socket may 
block thread infinitely, so in this case used SocketChannel directly.
6. Now trying to resolve bug that causes to fail random tests. On server start 
when SocketServerChannel.bind() is called it sometimes throws SocketException 
from native bind0() method:

java.net.SocketException: Invalid argument
    at sun.nio.ch.Net.bind0(Native Method)
    at sun.nio.ch.Net.bind(Net.java:463)
    at sun.nio.ch.Net.bind(Net.java:455)
    ...

I'm trying to find it's implementation for Linux but still no luck. Continue 
investigating.

> Rework client connection handling from thread-per-client to NIO model.
> ----------------------------------------------------------------------
>
>                 Key: IGNITE-3054
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3054
>             Project: Ignite
>          Issue Type: Task
>          Components: general
>    Affects Versions: 1.5.0.final
>            Reporter: Vladimir Ozerov
>            Assignee: Dmitry Karachentsev
>            Priority: Blocker
>             Fix For: 1.7
>
>
> Currently both servers and clients has the same operational model - 
> thread-per-connection. While being more or less fine for servers, this could 
> be a problem for clients when their total number is too high (e.g. 1000 or 
> even more).
> We should rework client handling model and employ standard NIO technique: one 
> or several acceptor threads + thread pool to server requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to