ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianfranco Murador <murador.gianfra...@gmail.com>
Subject Re: Ignite modularisation: client/server separation
Date Mon, 03 Aug 2015 13:48:07 GMT
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 <sergi.vladykin@gmail.com>:

> 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 <raulk@apache.org>:
>
> > 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message