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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
