FYI: https://issues.apache.org/jira/browse/FLINK-9437
We will revert the changes of FLINK-9310 with Flink 1.5.1. For Flink 1.6, the problem should not arise since we are currently upgrading our Netty dependency. Cheers, Till On Fri, May 25, 2018 at 8:40 AM, Till Rohrmann <trohrm...@apache.org> wrote: > Thanks for reporting the issue Edward. > > Taking a look at Netty SslHandler, it looks that we introduced this > problem with the update of the cipher algorithms [1]. Apparently, the > SslHandler wants to use inbound heap byte buffer when using a cipher suite > with GCM enabled [2]. This seems to be fixed with a later version of Netty > 4 (we are using 4.0.27 at the moment). The problem with the heap byte > buffers are, that our NettyBufferPool does not support the allocation of > heap byte buffers in order to have the memory consumption under control. > > As a work around, you could set `security.ssl.algorithms` to > `TLS_RSA_WITH_AES_128_CBC_SHA` in the Flink configuration. That should make > it work again at the cost of using a cipher which is no longer recommended. > > [1] https://issues.apache.org/jira/browse/FLINK-9310. > [2] https://github.com/netty/netty/blob/netty-4.0.27.Final/ > handler/src/main/java/io/netty/handler/ssl/SslHandler.java#L1218 > > Cheers, > Till > > On Thu, May 24, 2018 at 8:49 PM, Edward Rojas <edward.roja...@gmail.com> > wrote: > >> This may help to target the issue: >> If I let global ssl enabled, but I set taskmanager.data.ssl.enabled: >> false, >> it works again. >> >> >> >> -- >> Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble. >> com/ >> > >
