I started Ignite on the server with default configs. My application connects to the ignite server as a server/client and load the cache configuration and create the cache by uses CassandraCacheStoreFactory.
Zero deploy feature doesn't work for cache store. I should provide cache store configuration and implementation for each node in cluster ???
Thanks,
If you mean peer class loading, then yes, class for a cache store cannot be loaded from remote nodes. Peer class loading works only for objects, that have short bounded lifetime, like compute tasks or data stream receivers.
In case of a cache store, its class should be on a class path of every node in the cluster, that will participate in transactions, using the cache store. But the safest way is just to put it to the class path of every node in the cluster.
Specifying cache store configuration on every node is not mandatory. Only nodes, that create a cache or have it in a static config should have this configuration.
Related
I'm new to OpenStack and have a basic question about it. Assume that we have 3 Master node (Controller) and 10 Slave node (Compute node) in our cloud. We make 50 VMs (Instances) on the cloud. What will happen if one node (Controller or Compute node) become offline (Failure)? What is the best solution to prevent shutting down a VM if a server get offline?
Best regards
This question requires more than a short Stackoverflow answer. Here are a few initial thoughts.
When a controller goes offline, the instance itself continues running, but if the failed controller hosts a router, the instance might be cut off from the network. Generally, if the controller has anything that the instance needs, that thing won't be available anymore. There are measures like HA routers that can help in such a case.
When the instance's compute host goes down, the instance doesn't run anymore. You can evacuate instances from a failed compute host, which means that they are rebuilt on different hosts. If an instance's root disk resides on a volume or an ephemeral disk that is shared with other compute hosts, this means a mere instance reboot. If the instance has an ephemeral disk inside the failed host, it must be rebuilt from scratch.
OpenStack has a project named Masakari whose goal is to make instances resilient by redundancy. In short, instance HA. The application keeps running even if an instance crashes.
By the way, master and slave are not correct terminology in this context. Use controller and compute instead.
I have two different ignite deployments. In both, Apache Ignite server is started from the java program. The program sets work directory, configures the logger and then starts the server.
I have web application (Apache Ignite Client), which connects to respective Apache Ignite Server and performs the operation on cache.
What I am observing is that, in one enviroment some files are created inside work/marshaller directory and in other deployment the marshaller folder is empty.
Persistence is not enabled.
Can anyone explain?
Thanks
Ignite would write to marshaller dir when a corresponding type is used. This is because it is possible to have situation when all nodes which knew what type corresponding to a given typeId has left, and the remaining can no longer make sense of data they possess.
I am wondering if it's possible to start an Apache Ignite client Node by passing configuration parameters to the JVM. For instance, we may start a server Node by running "org.apache.ignite.startup.cmdline.CommandLineStartup" and passing config parameters to it.
I know it's possible to start a Node from inside a class implementation by initializing Ignite interface and explicitly joining a Cluster.
The easiest way to start a client node is invoke the Ignition.start(..) method. For more details you can refer to any example shipped with Ignite and to this documentation page: https://apacheignite.readme.io/docs/clients-vs-servers
I have a 3 node ignite cluster and 1 client that creates cache. During the development and testing, I had to stop the cluster or interrupt the cache building several time and the entire system is broken now. Only one node starts and the other nodes crashes. The client is blocked and it does not do anythin.
Is there any way to clean everything and sort of start fresh?
I am using Ignite 2.1 and using Persistent Cache storage.
Thank you for your help.
Just delete Ignite work directory - by default, it's ${IGNITE_HOME}/work.
Also, if you configured WAL store path, you need to clean it too:
https://apacheignite.readme.io/docs/distributed-persistent-store#section-write-ahead-log
Note: All data in persistent store will be lost.
I would like to know answers for below questions:
1) In case if Ignite server is restarted, I need to restart the client (web applications). Is there any way client can reconnect to server on server restart. I know when server restarts it allocates a different ID and because of this the current existing connection becomes stale. Is there way to overcome this problem and if so, which version of Ignite supports this feature. Currently I utilize version 1.7
2) Can I have client cache like how Ehcache provides. I don’t want client cache as a front–end to a distributed cache. When I looked at the Near Cache API, it doesn’t have cache name properties like cache configuration and it acts only as a front-end to a distributed cache. Is it possible to create client only cache in Ignite
3) If I have a large object to cache, I find Serialization and Deserialization takes a longer time in Ignite and retrieving from distributed cache is slow. Is there any way we can speed up large objects retrieval from Ignite DataGrid.
This topic is discussed on Apache Ignite users mailing list: http://apache-ignite-users.70518.x6.nabble.com/Questions-on-Client-Reconnect-and-Client-Cache-td10018.html