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.
> >
> >
> >
> >
>
