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