I send request in Ignite Client and client execute task on Ignite servers in cluster. Server need calculate some data from cache and return response to client. Client use IgniteCompute for execute, but if server was lost (crashed, connect lost, timeout) Ignite not balance this task for execute another server.
My question
Can Ignite repair (repeat) execute if connection lost with server in cluster? Or i need check this errors in client myself and send repeat request ?
I found some properties :
setAckTimeout
setSocketTimeout
setNetworkTimeout
setDiscoverySpi
setFailureDetectionTimeout
setClientFailureDetectionTimeout
setRebalanceTimeout
But it is not work....
My stack
Java 1.8
SpringBoot 2.4.5
Ignite 2.10
Ignite supports failover in terms of jobs. In order to achieve that you need to configure FailoverSPI. More information could be found in the documentation.
Related
I am trying to build an apache ignite thinclient poc and am able to connect to a cluster and also read the data using a ScanQuery. But am stuck at creating a Listener for any cache updates. I looked through but could not find anything for thin clients. Does ignite thin client even support listening on cache updates? How do I do that?
No, thin clients don't support Continuous Queries. You'll need to use a thick client to get that functionality.
How can we stop a client from reconnecting to the server after some retries.
In our case (in memory DB for fast retrieval), we have used Ignite and Oracle in parallel so that if Ignite server is down, then I could get my data from Oracle.
But when I start my application (while the Ignite server node is down for some reason), my application always waiting until it connects to server.
Console message:
Failed to connect to any address from IP finder (will retry to join topology every 2000 ms; change 'reconnectDelay' to configure the frequency of retries):
There is a TcpDiscoverySpi.joinTimeout property, which does exactly what you want: https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/discovery/tcp/TcpDiscoverySpi.html#setJoinTimeout-long-
By default, it's not defined, so, node will try to reconnect endlessly.
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
Ignite has two modes, one is Server mode, and the other is client mode.I am reading https://apacheignite.readme.io/docs/clients-vs-servers, but didn't get a good understanding of these two modes.
In my opinion, there are two use cases:
If the Ignite is used as an embedded server in a java application, they the Ignite should be in server mode, that is, Ignite should be started with
Ignite ignite = Ignition.start(configFile)
If I have setup an Ignite cluster that are running as standalone processes. Then in my java code, I should start Ignite in client mode, so that the client mode Ignite can connect to the Ignite cluster, and CRUD the cache data that resides in the ignite cluster?
Ignition.setClientMode(true);
Ignite ignite = Ignition.start(configFile)
Yeah, this is correct understanding.
Ignite client mode intended as lightweight mode (which do not store data and do not execute compute tasks). Client node should communicate with a cluster and should not utilize self resources.
Client does not even started without server node presented in topology.
In order to further add to #Makros answer, Ignite Client stores data if near cache is enabled. This is done in order to increase the performance of cache retrievals.
Yeah, you are right in ignite client has IgniteConfiguration.setClientMode(true); and for server IgniteConfiguration.setClientMode(false);, which is default value. if set IgniteConfiguration.setClientMode(false); in you code or forget to set setClientMode(); it will work as server.
I have gemfire client server configured via gfe based xml. The locator, cache server and client cache start through these xml configurations. I populate my Region by getting data from database. The client uses data from this Region. It works very well for about 2 hours but after that the client starts throwing following exception and trace.
I don't do any changes to running application. That means the locator and cache server should be running at all times. Any help would be great. Thanks.
com.gemstone.gemfire.cache.client.NoAvailableLocatorsException: Unable to connect to any locators in the list [/locator-host:locator-port]
at com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
at com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:205)
at com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:418)
at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:114)
at com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:638)
at com.gemstone.gemfire.cache.client.internal.GetOp.execute(GetOp.java:89)
at com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:126)
at com.gemstone.gemfire.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2767)
at com.gemstone.gemfire.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1605)
at com.gemstone.gemfire.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:133)
at com.gemstone.gemfire.internal.cache.LocalRegion.get(LocalRegion.java:1489)
at com.gemstone.gemfire.internal.cache.LocalRegion.get(LocalRegion.java:1451)
at com.gemstone.gemfire.internal.cache.AbstractRegion.get(AbstractRegion.java:278)
Do you have anything in your locator or server logs? That exception indicates the client is trying to create a new connection and can't connect to a locator.
If your locator goes down, the client might still be able to work for a while using it's existing connections because it doesn't need to go back to the locator until it needs a new connection.