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

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

Implemented async NIO. Now clients join topology and communicate via NIO 
selector. Server, on node join request, decides to switch into async mode, 
according to client version, and responds to client with recipe status OK v2. 
After switch client starts adding message length to each packet to make server 
be able to assembly it from chunks.

With these changes now is avoided supplying of two threads: client message 
worker and socket reader, that were created for each client connection before.

Approx. roadmap for task:

* Handle correctly client reconnect, or make sure if it's not necessary due to 
establishing new connection.

* Refactor and obvious optimizations.

* Adding SSL support (seems not too difficult - just add SSL filter to 
GridNioServer).

* Performance tests.

> 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