Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGcMBHj9xbhyZcdpEsn-AUgorAh9g2P=nt67Ds4ZKJzFdc8MQg@mail.gmail.com>
References: 
 <CAGt6o8nhCwOXgPspofSdLWjO3nyN2i+uW03So0zpshpu6mrrag@mail.gmail.com>
	<289522752.1104679.1460445706141.JavaMail.yahoo@mail.yahoo.com>
	<CAGcMBHiCVNBc5c8R7OHyuxodS2cvpr4Q5ghZ_84TwGd+uV0Xiw@mail.gmail.com>
	<CAGt6o8mYVYGnOj2LcZhu2k=NncJo2dm6vG8EJeezF94_DqCwbQ@mail.gmail.com>
	<CAGcMBHj9xbhyZcdpEsn-AUgorAh9g2P=nt67Ds4ZKJzFdc8MQg@mail.gmail.com>
Date: Thu, 14 Apr 2016 16:42:30 +0300
Message-ID: 
 <CAGt6o8m7wbf3C+7EwrVV7CuPug-HuSga0tp6DHEBfnjT-9OT_Q@mail.gmail.com>
Subject: Re: Introduce generic server configuration.
From: Vladimir Ozerov <vozerov@gridgain.com>
To: dev@ignite.apache.org
Cc: Roman Shtykh <rshtykh@yahoo.com>
Content-Type: multipart/alternative; boundary=001a11432512d21f610530721062

--001a11432512d21f610530721062
Content-Type: text/plain; charset=UTF-8

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 <yzhdanov@apache.org> wrote:

> How about TcpEndpointConfiguration?
>
> --Yakov
>
> 2016-04-13 13:22 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
> > 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 <yzhdanov@apache.org>
> > 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 <rshtykh@yahoo.com.invalid>:
> > >
> > > > +1 for such a bean.
> > > > -Roman
> > > >
> > > >
> > > >     On Monday, April 11, 2016 11:48 PM, Vladimir Ozerov <
> > > > vozerov@gridgain.com> 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.
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

--001a11432512d21f610530721062--