Hi Alexey,
Oleksiy Stashok wrote:
> Hello.
>
> Implementing Grizzly benchmark measurement, I've found out that
> currently SSLReadFilter doesn't support chunked reading. If secured
> chunk came, but it's not enough for SSLEngine to decode info - next
> time, when second chunk will come - SSLReadFilter will not be able to
> concatenate these chunks! As currently secured input buffer and secured
> output buffer are associated with Thread, but not with SSLEngine
> session. And if 1st and 2nd chunks will come in separate threads - error
> will occur.
I agree this can happens if you don't use the ByteBufferInputStream. If
you use the trick associated with ByteBufferInputStream, then you are
always guarantee to read all the chunks. Since I've ported the code from
grizzly 1.0 where only http was supported usinh the BBInputStream, then
I'm completely missed that use case. Good catch!
> To avoid this problem I think we need to associate secured buffers with
> SSLEngine's session, at least it makes sense, when there is some secured
> data (input or output), which should be used with next time during
> read/write operations.
+1
or WorkerThreadImpl - we can implement some
> common attribute map interface: setAttribute(String name, Object obj),
> getAttribute(String name) and remove members: inputBB, outputBB, sslEngine.
>
> What do you think?
Can the get/setSSLEngine be enough? Then you can always do
WorkerThread.getSSLEngine().getSession().getValue(..)/setValue(..).
Thanks
-- Jeanfrancois
>
> WBR,
> Alexey.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>