Introduce generic server configuration.

[Vladimir Ozerov]

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.

[Roman Shtykh]

+1 for such a bean.
-Roman
 

    On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <[hidden email]> 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.


   

[yzhdanov]

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 <[hidden email]>:

> +1 for such a bean.
> -Roman
>
>
>     On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <
> [hidden email]> 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.
>
>
>
>

[Vladimir Ozerov]

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 <[hidden email]> 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 <[hidden email]>:
>
> > +1 for such a bean.
> > -Roman
> >
> >
> >     On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <
> > [hidden email]> 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.
> >
> >
> >
> >
>

[yzhdanov]

How about TcpEndpointConfiguration?

--Yakov

2016-04-13 13:22 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > +1 for such a bean.
> > > -Roman
> > >
> > >
> > >     On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <
> > > [hidden email]> 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.
> > >
> > >
> > >
> > >
> >
>

[Vladimir Ozerov]

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 <[hidden email]> wrote:

> How about TcpEndpointConfiguration?
>
> --Yakov
>
> 2016-04-13 13:22 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > +1 for such a bean.
> > > > -Roman
> > > >
> > > >
> > > >     On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <
> > > > [hidden email]> 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.
> > > >
> > > >
> > > >
> > > >
> > >
> >
>