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 <[email protected] >: > 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 <[email protected]> > 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 < > > [email protected] > > >: > > > > > 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 <[email protected]> > > 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 <[email protected]>: > > > > > > > > > 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 < > > > > > [email protected]> 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 < > > > > [email protected] > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
