How about TcpEndpointConfiguration? --Yakov
2016-04-13 13:22 GMT+03:00 Vladimir Ozerov <[email protected]>: > Yakov, > > I thought about the following design: > > 1) Create org.apache.ignite.server.ServerConfiguration bean. I am not sure > about "server" word here, because it is too generic. May be "endpoint" or > "tcpServer", or something like this. > > 2) Then we plug this bean into other beans. E.g., for ODBC it will look as > follows: > > IgniteConfiguration { > OdbcConfiguration odbcConfiguration; > } > > OdbcConfiguration { > ServerConfiguration serverConfiguration; > int maxCursors; // This is ODBC-specific stuff. > } > > ServerConfiguration { > String address; // E.g. "myHost:15000..15004" > } > > Vladimir. > > > On Wed, Apr 13, 2016 at 12:59 PM, Yakov Zhdanov <[email protected]> > wrote: > > > 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. > > > > > > > > > > > > > > >
