ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: jdbc vs jdbc2 packages
Date Wed, 08 Feb 2017 22:19:00 GMT
Yakov,

I agree that investing in the legacy client doesn't make sense - it's slow
and outdated. Regarding your points:

1. This is just another build step, but the JAR is going to pretty fat I
think (it will have to include Spring). Not ideal, but definitely better
than what we have now. However, our clients also often require some user
classes, like CacheStore implementations. This is also a problem.

2. That's a great idea! Actually, I'm not sure why we require to have full
verbose config on client that is consistent with server. Why not fetch the
configuration from cluster during join? Not sure how hard this change is,
but it can be a very big usability improvement. And surely, JDBC driver
should be able to config with host:port without config file.

3. This can be already achieved with Compute Grid, no? I don't think we
need to add anything here.

Another issue with clients is that they currently can't work behind NAT
without additional config which is not very trivial (AddressResolver). Is
it possible to avoid server->client connections in communication SPI?

-Val

On Tue, Feb 7, 2017 at 9:09 PM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> "undeprecating" - lol :D
> Consider introducing @Un annotation which negates all annotations on the
> same level and below.
>
> I would probably agree with Val and Vova, but adding features to
> thin-client seems questionable to me.
>
> Is these possible:
> 1. avoid dependencies on client machine and require ignite-jdbc.jar only
> (e.g. gathering dependencies inside the jar).
> 2. make it possible to provide just address and port to send join request
> to without providing the entire IgniteConfiguration. Client node sends join
> request to the cluster with flag that this is jdbc-driver connection and
> server-side topology omits configuration validation and forces client to
> set some properties if this is necessary (e.g. CommunicationSpi
> implementation class and settings)
> 3. add possibility to offload complex reduce processing to server. Which
> may be very helpful for main client-server use cases when clients being run
> on much weaker machines.
>
> ?
>
> --Yakov
>
> 2017-02-07 14:30 GMT+07:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
> > Big +1 to Val, not only about JDBC, but about our overall approach to
> > clients. Starting a node with "client=true" is:
> > + Very reach feature set, which is cool
> > - Tons of dependencies
> > - Tons of threads
> >
> > It would be very cool if we have a true thin client with small single
> JAR.
> > It should have:
> > - Failover
> > - Load-balance
> > - Optional server "stickyness"
> >
> > Once all these things are in place we will be able to provide the same
> API
> > as in current client, but with predictable behavior and memory footprint.
> > For instance our current client is not well-suited for running map-reduce
> > (compute or SQL) because it moves large amount of data and processing to
> > the client, which is potentially a slow desktop machine.
> >
> >
> > On Tue, Feb 7, 2017 at 3:44 AM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> >
> > > There are two implementations of JDBC driver - based on legacy thin
> > client
> > > (jdbc package) and on client node (jdbc2). The first one was deprecated
> > > when we introduced the latter, but now I tend to think that this was
> not
> > a
> > > right decision. Thin client driver provides worse performance, but it's
> > > much easier to use, never requires additional dependencies like Spring
> > and
> > > can be used from any remote machine. Probably we can consider
> > undeprecating
> > > it.
> > >
> > > -Val
> > >
> > > On Mon, Feb 6, 2017 at 2:02 AM, Sergi Vladykin <
> sergi.vladykin@gmail.com
> > >
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > We have 2 different packages: jdbc and jdbc2. Everything in jdbc is
> > > > deprecated. Because of that new features like DML support were not
> > added
> > > > there.
> > > >
> > > > This seems to cause some problems to our users. Can someone clarify,
> > did
> > > we
> > > > deprecated these classes wrongly and we have to continue developing
> > them
> > > or
> > > > what?
> > > >
> > > > Sergi
> > > >
> > >
> >
>

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