[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    Re: Java SSLSocketChannel/SSLSelector?
From:       Dean Hiller <dhiller () twitter ! com>
Date:       2019-02-19 16:17:49
Message-ID: CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w () mail ! gmail ! com
[Download RAW message or body]

>
> I am beginning to think we might be on different pages here. Someone from
> outside the selector calls selector.select(), and all selector's
> functionality is handled within the context of the calling thread. So where
> is the need for the extra thread here? More specifically, in the
> SSLSelector case, a call to its select, ends up usually to a call to its
> inner selector.select(), always in the context of the calling thread ... so
> same thing again. Why do you think another thread is necessary here (within
> the selector itself)?
>

That implies multiple threads using 1 selector.  That can be very dangerous
and prone to bugs.  Even with SSL, I would shy away from making something
like that unless putting it behind some library/abstraction like netty,
webpieces channelmanager or something.

In fact, the performance of 1 thread that runs the selector who dishes the
work to a threadpool immediately (N sockets to X threads) has been
amazing!!!  *It was even better than multiple threads on a selector we
found.* This was because that caused lots of contention with locks(slowing
it down).  The contention depended on the application as some apps had more
contention than others.  I would highly advise just sticking 1 thread on
the selector dishing out to a thread pool which removed all contention to
streamline the whole process for speed.

THEN, if you do have a threadpool and an simple implementation that runs
the data serially per socket in the threadpool(this is quite easy to do),
you can do the decryption in the threadpool as well.  webpieces impl does
this as well.

just my 2 cents,
later,

Dean

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I am beginning to think we \
might be on different pages here. Someone from outside the selector calls \
selector.select(), and all selector&#39;s functionality is handled within the context \
of the calling thread. So where is the need for the extra thread here? More \
specifically, in the SSLSelector case, a call to its select, ends up usually to a \
call to its inner selector.select(), always in the context of the calling thread ... \
so same thing again. Why do you think another thread is necessary here (within the \
selector itself)?<br></div></div></blockquote><div><br></div><div>That implies \
multiple threads using 1 selector.   That can be very dangerous and prone to bugs.   \
Even with SSL, I would shy away from making something like that unless putting it \
behind some library/abstraction like netty, webpieces channelmanager or something.    \
</div><div><br></div><div>In fact, the performance of 1 thread that runs the selector \
who dishes the work to a threadpool immediately (N sockets to X threads) has been \
amazing!!!   <b>It was even  better  than multiple threads on a selector we \
found.</b> This was because that caused lots of contention with locks(slowing it \
down).   The contention depended on the application as some apps had more contention \
than others.   I would highly advise just sticking 1 thread on the selector dishing \
out to a thread pool which removed all contention to streamline the whole process for \
speed.</div><div><br></div><div>THEN, if you do have a threadpool and an simple \
implementation that runs the data serially per socket in the threadpool(this is quite \
easy to do), you can do the decryption in the threadpool as well.   webpieces impl \
does this as well.     </div><div><br></div><div>just my 2 \
cents,</div><div>later,</div><div><br></div><div>Dean</div></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]