Hi.
>>  Potentially reduced resource usage - share EventLoopGroop across all
connections within one IgniteClient.
Not potentially, definitely. Current approach (one receiver thread per
TcpClientChannel and shared FJP for continuation) requires too many threads.
When TcpClientChannel is the only one, it's ok. But if we use multiple
addresses, things become worse.

>> The obvious downside is an extra dependency in the core module.
There is another downside -- we should rework our transaction's API a
little bit (Actually,  in netty socket write is performed in other thread
(channel.write is async) and
current tx logic will not work
(org.apache.ignite.internal.client.thin.TcpClientCache#writeCacheInfo))

A little bit of offtopic.
I suppose, that the java thin client (and other thin clients) should be
separated from the main ignite repo and have a separate release cycle.
For example, java thin client depends on default binary
protocol's implementation, that is notorious for heavy usage of internal
JDK api and this for example.
prevents usage of our thin client in graalvm native image.


пт, 16 окт. 2020 г. в 20:00, Pavel Tupitsyn <ptupit...@apache.org>:

> Igniters,
>
> I'm working on IEP-51 [1] to make Java thin client truly async
> and make sure user threads are never blocked
> (right now socket writes are performed from user threads).
>
> I've investigated potential approaches and came to the conclusion
> that Netty [2] is our best bet.
> - Nice Future-based async API => will greatly reduce our code complexity
>   and remove manual thread management
> - Potentially reduced resource usage - share EventLoopGroop across all
> connections within one IgniteClient
> - SSL is easy to use
> - Proven performance and reliability
>
> Other approaches, like AsynchronousSocketChannel or selectors, seem to be
> too complicated,
> especially when SSL comes into play.
> We should focus on Ignite-specific work instead of spending time on
> reinventing async IO.
>
> The obvious downside is an extra dependency in the core module.
> However, I heard some discussions about using Netty for GridNioServer in
> future.
>
> Let me know your thoughts.
>
> Pavel
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-51%3A+Java+Thin+Client+Async+API
> [2] https://netty.io
>


-- 
Sincerely yours, Ivan Daschinskiy

Reply via email to