Vladimir, I like the idea and it should really make things simpler, however, it is not clear to me how to incorporate this bean properly. NIO server is in internal package, but configuration should be under public one. Having this bean on public API of components exposes their internal implementation details.
As far as your examples - it is ok to have bean setter on TCP communication - it does not seem ok to have bean setter on IgniteConfiguration (is ODBC component implemented as a processor?) Vova, can you please provide your thoughts on implementation? --Yakov 2016-04-12 10:21 GMT+03:00 Roman Shtykh <[email protected]>: > +1 for such a bean. > -Roman > > > On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov < > [email protected]> wrote: > > > Igniters, > > We have several public components which use *GridNioServer* internally. NIO > server has several properties for fine tuning. Selector count, direct > buffer flag, max queue size, send/receive buffer sizes, etc.. > > And in every public component we have separate getters/setters to pass > values to NIO server. E.g. look at *TcpCommunicatinoSpi*, > *ConnectorConfiguration > *and *SocketStreamer*. They all have similar properties. > > Now we have ODBC component which also use *GridNioServer*. I do not want to > expose these properties through getters/setters because it will make > *OdbConfiguration* very complex. Instead, I have an idea to introduce new > bean *ServerConfiguration *which will have all these fine-grained > properties. Later this bean could be re-used in other components which work > with NIO server. > > This way component configuration will be very simple and straightforward > when user do not want to tune NIO server. And I think this is the most > common use case. Simple config fox common case, complex config for complex > case. > > Thoughts? > > Vladimir. > > > >
