ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Introduce generic server configuration.
Date Wed, 13 Apr 2016 10:47:18 GMT
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.
> > >
> > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message