Hello everyone, I have a question about this topic : the unification between client and server is also due to the fact that I can do computations on the client nodes ? For computation I mean something like this:
ClusterGroup clientGroup ignite.cluster().forClients ( ) ; IgniteCompute clientCompute = ignite.compute ( clientGroup ) ; // Execute computation on the client nodes . clientCompute.broadcast ( ( ) - > System.out.println ( " Hello Client " ) ) ; Thanks, Regards, Gianfranco 2015-08-03 15:23 GMT+02:00 Sergi Vladykin <[email protected]>: > Raul, > > As far as I understand your main concern is that Ignite is incompatible > with OSGi (other points seem to be more about your personal feelings about > "right engineering practices" than about real problems). I believe that we > can achieve this compatibility without such a big refactoring of > everything. But do we really need that if it is not a requirement for > Camel? > > BTW client/server API of Ignite is intentionally unified to make it easier > to use (simply switch one flag in config instead of rewriting your code to > completely different API). In this case unification works better than > separation of concerns. > > Sergi > > 2015-08-03 14:31 GMT+03:00 Raul Kripalani <[email protected]>: > > > Hello guys, > > > > Spoke to Dmitriy over the weekend about the modularisation of Ignite. > > > > At Apache Camel we strive to make all our components (including the > future > > camel-ignite) OSGi compatible because have a significant user base > > deploying Camel apps on Apache Karaf. > > > > I see some groundwork before we can aspire to make OSGi components > > communicate with Ignite: > > > > * There seems to be no concept of a client. Client-side and > server-side > > coexist in ignite-core. There's no code separation, so a client wanting > to > > communicate with an Ignite topology will end up importing the server-side > > implementation too. > > > > * ... and the server-side implementation uses classloading constructs > > (e.g. Zero Deployment) which may prove hard to engineer for compatibility > > with OSGi. This re-enginering is a waste of time IMHO because there's no > > interest in running Ignite servers on top of OSGi - only clients. > > > > * The ignite-core JAR (6.7mb) is too heavy for a component that's > > nothing but a client. Some average Java client API sizes for reference: > > hazelcast (400kb), activemq-client (1.2 mb), kafka (300kb). > > > > * Possible dependency leak. Currently not a problem as we lack 3rd > party > > deps in ignite-core. But if we introduce any, we'll impose our dep > versions > > on the client creating possible classpath hell. Or seen from another > > perspective: I don't know the reason we have no 3rd party deps, and I'm > > sure we've had to reinvent the wheel at some point... Perhaps we avoided > > them because we knew we would be imposing them on the client? If that's > the > > case, separating server and client will bring lots of flexibility. > > > > * This architecture/design entails a lack of separation of concerns, > > IMO. While it's true that a client can start an embedded Ignite instance > > (and for that it'll need the server-side code), not all clients will do. > In > > my opinion, ignite-java-client (hypothetical name) should discover > > ignite-core (just the server-side impl) in the classpath if starting an > > embedded Ignite is requested. > > > > What's your opinion? Obviously such a refactoring is a large undertaking > > and not for immediate action. If the community shares this vision, I > would > > start thinking about this for 2.0. > > > > P.S.: With regards to Camel, a warning on the camel-ignite doc page for > not > > being OSGi-compliant will suffice. > > > > Regards, > > > > *Raúl Kripalani* > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > > Integration specialist > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > > http://blog.raulkr.net | twitter: @raulvk > > >
