Ok, so here is the summary of proposed design:
1) We introduce org.apache.ignite.configuration.TcpEndpointConfiguration.
This is generic bean which could be used in different components having TCP
server semantics.
2) This class will contain a set of TCP-specific properties:
class TcpEndpointConfiguration {
String address; // Endpoint host and port. Allowed formats: "host",
"host:port", "host:port1..port2"
int selectorCount; // Number of selectors.
long idleTimeout; // Half-opened socket detection.
/** TCP-specific config. */
int socketSendBuffer;
int socketReceiveBuffer;
boolean noDelay;
/** Convenient constructor. */
TcpEndpointConfiguration(String address) { }
}
3) For now we will inject it only inside OdbcConfiguration. Later on we
will gradually rework other components.
class OdbcConfiguration {
// Endpoint config with default all-interface binding and default port
range.
TcpEndpointConfiguration tcpEndpointConfiguration = new
TcpEndpointConfiguration("0.0.0.0:49500..49510");
/** Other ODBC-specific config goes here. */
...
}
And several examples how it could be configured:
1) All defaults.
<bean class="OdbcConfiguration" />
2) Set specific address:
<bean class="OdbcConfiguration">
<property name="tcpEndpointConfiguration">
<bean class="TcpEndpointConfiguration">
<property name="address" value="myHost:10000" />
</bean>
</property>
</bean>
Thoughts?
Vladimir.
On Wed, Apr 13, 2016 at 1:47 PM, Yakov Zhdanov <[email protected]> wrote:
> 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.
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
