Denis, I completely agree that we should have a thin JDBC client. Can you file a ticket?
On Wed, Mar 15, 2017 at 4:58 PM, Denis Magda <dma...@apache.org> wrote: > Frankly, during these two a couple of day I had a chance to play with Web > Console and Ignite JDBC driver. > > As many other users I referred to JDBC documentation in order to setup the > driver properly. However, then due to the recently reported issue I fell > back to JDBC v 1 (thin client based): > https://issues.apache.org/jira/browse/IGNITE-4829 < > https://issues.apache.org/jira/browse/IGNITE-4829> > > I was amazed how swift JDBC v 1 and sluggish JDBC v 2 which is default. > Unfortunately, JDBC v 1 doesn’t support DML this is why I had hard time > finding out a workaround for IGNITE-4829. But, in any case I fully support > reincarnation of JDBC v 1. > > *Val*, as one of the most experienced folks who participated in this > discussion, would you mind wrapping the discussion up in a form of a ticket > listing the design proposal? > > — > Denis > > > On Feb 10, 2017, at 4:47 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > I generally like the idea of supporting thin JDBC clients. Often it is > not > > feasible to start a client node on JDBC side. > > > > On Fri, Feb 10, 2017 at 1:04 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > >> Yakov, > >> > >> There are two separate aspects that we can improve: > >> > >> 1. Message routing as you described. I agree it can be useful in some > >> scenarios and I definitely not against this feature, but honestly I > haven't > >> seen a lot of requests for this so far. > >> 2. Server can initiate connection with client. This really blows users's > >> minds :) > >> > >> I only meant that the latter is much more critical in my view. > Configuring > >> port forwarding on the cluster can be complicated, but it absolutely > makes > >> sense, while doing the same on client just sounds crazy. Client should > be > >> able to just connect, without having public IP and without additional > >> configuration on the router. > >> > >> -Val > >> > >> On Fri, Feb 10, 2017 at 1:58 AM, Yakov Zhdanov <yzhda...@apache.org> > >> wrote: > >> > >>> 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.kuliche...@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 <yzhda...@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.kuliche...@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 <yzhda...@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 <voze...@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.kuliche...@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.vlady...@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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
