Apache Ignite with Spring framework - ignite

Does the Apache Ignite operate on a spring framework basis?
Can I register a spring controller in classpath at server remote node and use it?(using component , like #Controller)

Apache Ignite is integrated with Spring but isn't based on it.
You can register spring beans when starting remote node (using normal spring approach) and then use them from e.g. compute or distributed services.
I'm not sure if you can register beans remotely in runtime, but I don't see why not.

Related

How to deploy 2 services in an Apache Ignite cluster

I have a spring boot service that configures ignite at startup and executes Ignition.start(). There are 2 more services also on spring boot that need to be placed in one Ignite cluster. How can I do this?
You are running Apache Ignite in embedded mode using maven dependency. For sharing the same Ignite instance across services, you need to create an Ignite cluster in distributed mode and then connect to the same Cluster from all the services using Thin/Thick client as per your need.
For e.g Creating Ignite cluster using Docker refer to the link: https://ignite.apache.org/docs/latest/installation/installing-using-docker
There are other options available to create Ignite cluster.
Once the Cluster is created then you can use a Thick/Thin client to connect to the same cluster.
Please refer :
https://www.gridgain.com/docs/latest/getting-started/concepts

Connecting to pivotal cloud cache from a spring boot gemfire client app on non PCF (VSI) Platform

I have Pivotal cloud cache service with https URL , i can connect to the https service via gfsh .
I have a spring boot app annotated with #ClientCacheAPplication which is running on a VSI , on a seperate VSI server , on a non PCF / non cloud environment .
Is there a way to connect to the https PCC service from the spring boot client app ?
First, you should be using Spring Boot for Apache Geode [alternatively, VMware Tanzu GemFire] (SBDG); see project page and documentation for more details.
By using SBDG, it eliminates the need to explicitly annotate your Spring Boot (and Apache Geode or GemFire ClientCache) application with SDG's #ClientCacheApplication annotation. See here for more details.
NOTE: If you are unfamiliar with SBDG, then you can follow along in the Getting Started Sample. Keep in mind that SBDG is just an extension of Spring Boot dedicated to Apache Geode (and GemFire).
I also have documentation on connecting your Spring Boot app to a Pivotal Cloud Cache (or now know as VMware Tanzu GemFire for VMs) instance.
1 particular piece of documentation that is not present in SBDG's docs is when you are running your Spring Boot application off-platform (that is when your Spring Boot app has not been deployed to Pivotal CloudFoundry (or rather, VMware Tanzu Application Service)) and you are "connecting" to the Pivotal Cloud Cache (VMware Tanzu GemFire for VMs) service on platform (that is GemFire running in PCF as PCC, or running VMW TAS as VMW Tanzu GemFire for VMs).
To do this, you need to use the new SNI Services Gateway provided by the GemFire itself. This interface allows GemFire/Geode clients (whether Spring Boot application or otherwise) to run off-platform, yet still connect to the GemFire service (PCC or VMW Tanzu GemFire for VMs) on-platform (e.g. PCF or VMW TAS).
This is also required if you are deploying your Spring Boot application in its own foundation on-platform, separately from the services foundation where the GemFire service is running. For example, if you deploy and run your Spring Boot app in the APP_A_FOUNDATION and the GemFire service is running the the SERV_2_FOUNDATION, both on-platform, then you would also need to use the GemFire SNI Service Gateway feature.
This can be configured using Spring Boot easily enough.
I have posted an internal query, reaching out to the people who have more information on this subject, and I am currently waiting to hear back from them.
Supposedly (so I was told) there is an acceptance test (SNIAcceptanceTest) that would demonstrate how this feature works and how to use, but I cannot find any references to this in the Apache Geode codebase (develop branch).
I will get back to you (in the comments below) if I hear back from anyone.

Why Does Ignite Use Spring framework?

I had used Spring framework in my apps and while it is nice conceptually, it is not suitable for real-time apps due to its run-time overhead. For instance, http://apache-ignite-users.70518.x6.nabble.com/Failed-to-map-keys-for-cache-all-partition-nodes-left-the-grid-td23510.html shows the actual run-time Spring stack.
The Spring features that Ignite uses for loading application-defined beans are just many layers wrapped around simple Java reflection features. So Why Ignite uses Spring instead of straight Java'reflection ?
To make Ignite more performant, is there plan with Ignite to switch from Spring framework to Java reflection features ?
Similarly, if Ignite uses Spring Boot to handle port requests, why does it not use a light-weight framework such as www.sparkjava.com ?
Ignite uses Spring only to convert XML configuration files into configuration beans during startup. This way Ignite provides a convenient well-known way of configuring instead of introducing a custom one. In the runtime, after node is started, Spring is not used for anything.
In the thread you provided it's actually other way around - Spring invokes Ignite. Apparently, that's a Spring application with an embedded Ignite node.

How to share an ignite instance among jetty webapps

The docs state:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/startup/servlet/ServletStartup.html
Servlet-based startup may be used in any web container like Tomcat,
Jetty and etc. Depending on the way this startup is deployed the
Ignite instance can be accessed by either all web applications or by
only one. See web container class loading architecture:
But then points to a dead link regarding Jetty.
I'm using Jetty. How would this be done (sharing the ignite instance among all web applications)?
Link to Jetty classloading
Link to Ignite web configuration
The latter describes web session clustering but you don't have to enable that to use Ignite. I think these docs should cover your case.
To share Ignite instance between web apps, you will need:
Put Ignite libraries into server's main lib/ directory, and not under your web app directory
Instantiate Ignite using Jetty API, as per the documentation that you referenced
code:
Server service = new Server();
service.addListener("localhost:8090");
ServletHttpContext ctx = (ServletHttpContext)service.getContext("/");
ServletHolder servlet = ctx.addServlet("Ignite", "/IgniteStartup",
"org.apache.ignite.startup.servlet.ServletStartup");
servlet.setInitParameter("cfgFilePath", "config/default-config.xml");
servlet.setInitOrder(1);
servlet.start();
This assumes you are starting Jetty programmatically, i.e. with your own code. Your mileage may vary if you don't.

Service grid in a micro services environment

We are using apache ignite as a IMDG in our micro services environment.
For scalability and load balancing we are considering to use a service registry like eureka or consul which is supported by spring cloud for the deployed micro services.
There is a concept of service grid providing support for node singleton and cluster singleton in apache ignite.
I also see WCF,weblogic and JBoss to having the same sort of features.
I am trying to understand what these service grids are and if i can use them to achieve the same benefits as the eureka service registry provided by netflix and supported by spring cloud.
Can someone guide if i can achieve the same using service grid in apache ignite.
No, you cannot use Apache Ignite Service Grid for the same purposes as Eureka. Eureka is used for load balancing and service discovery over WAN. Using Ignite clusters spanning over multiple AWS zones and remote client machines is not the most efficient way of using it.
More information on Ignite Service Grid can be found here - http://apacheignite.gridgain.org/docs/service-grid
Thanks!
UPD (for the 1st comment):
You cannot (in most cases) span and effectively use Ignite over WAN networks with high latencies and lower throughput characteristics.
As far as local clusters in non-cloud environments - go ahead! This is the best environment for systems of such kind.