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