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