ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: jdbc vs jdbc2 packages
Date Fri, 10 Feb 2017 09:58:57 GMT
Val, can you please explain your statement. You suggest users have port
forwarding for dozens of nodes in their topologies so client can initiate
connect to any of them? I don't think this is possible and routing seems to
be the only possible option.

--Yakov

2017-02-10 0:04 GMT+03:00 Valentin Kulichenko <valentin.kulichenko@gmail.com
>:

> Yakov,
>
> 1. Yes, I will file a ticket.
>
> 4. I meant that server can currently initiate connection with client, and
> that's the main problem here. Is there a way to avoid this? Message routing
> you're referring to can also be useful in some cases, but much less
> critical.
>
> -Val
>
> On Wed, Feb 8, 2017 at 9:20 PM, Yakov Zhdanov <yzhdanov@gridgain.com>
> wrote:
>
> > Val,
> >
> > 1. Our clients should stop require persistent store implementation if
> they
> > do not need it. Can you please file a ticket? I know you fixed some
> places
> > already. As an idea I would keep everything in binary format until we
> > really need it. Will that work?
> > 2. We can try adding the very first step to fetch the configuration and
> > then proceed with normal start.
> > https://issues.apache.org/jira/browse/IGNITE-4675
> > 3. Agree, but user needs to define the closures then. I would think on
> how
> > to put this to a product.
> > 4. This needs to be implemented :) I mean we can communicate to a client
> > through server it is connected to.
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2017-02-09 5:19 GMT+07:00 Valentin Kulichenko <
> > valentin.kulichenko@gmail.com
> > >:
> >
> > > 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