Near Cache versus Continuous Query

Hi, I have a use case where I want a fully copy of a replicated cache on a subset of my thick clients. In this example, I have an ETL thick client that creates and updates a replicated cache in my server grid. I then have a series of webserver thick clients that I always want a fully up to date

Near Cache versus Continuous Query

Hi, I have a use case where I want a fully copy of a replicated cache on a subset of my thick clients. In this example, I have an ETL thick client that creates and updates a replicated cache in my server grid. I then have a series of webserver thick clients that I always want a fully up to date

Re: Ignite Startup Warnings

Paolo, > I could get rid of most of them by changing my configuration (e.g. setting > a default non-logging CheckpointSpi or non-logging CollisionSpi implementation) Would you have the snippet for this config? If they are your custom non-logging classes are you comfortable sharing them here

RE: incorrect partition map exchange behaviour

Sorry about mixing the terminology. My post was meant to be about the PME and the primary keys. So the summary of my post and what it was trying to show was the PME was only happening on cluster node leaves (server or visor) but not cluster node joins (at least with previously joined nodes -

Re: incorrect partition map exchange behaviour

Haven't tested on 2.9.1 as we don't have that database provisioned and sadly won't for awhile. When we do though I will update. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: incorrect partition map exchange behaviour

Here's my attempt to demonstrate and also provide logs Standup 3 node cluster and load with data Using a thick client, 250k devices are loaded into the device cache. The thick client then leaves. There's one other thick client connected the whole time for serving requests but I think that's

incorrect partition map exchange behaviour

Hi, We have a cluster of Ignite 2.8.1 server nodes and have recently started looking at the individual cache metrics for primary keys org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl.OffHeapPrimaryEntriesCount In our configuration we have a replicated cache with 2 backups.

Ignite timeouts and trouble interpreting the logs

First some background. Ignite 2.8.1 with a 3 node cluster, two webserver client nodes, and one batch processing client node that comes and goes. The two webserver thick client nodes and the one batch processing thick client node have the following configuration values: *

Re: "Node with same ID" error

I also found two stack overflow comments suggesting they saw it after upgrading to 2.8.1: https://stackoverflow.com/questions/62258394/i-would-like-to-know-the-cause-for-this-error-org-apache-ignite-spi-ignitespiex#comment111425289_62258394

"Node with same ID" error

Background: Running an Ignite 2.8.1 cluster. 3 node server configuration with one persistent client and one or more ad hoc clients. Problem: We ssh'ed onto one of the nodes and ran visor there to quickly gather cache stats. Visor hung indefinitely and one of the 3 nodes had their ignite process

Visor configuration

To use visor we typically ssh onto a server node and use run visor there. When doing so we launch visor with the exact same configuration as that server node is running. Two questions regarding this: * Is running visor from a server node problematic? * Should we be using a different

Re: Bug with client cache_size for metrics() and localMetrics()

Apologies. I modified the tests to wait longer for the 2.8.1 test scenario on the client printouts and eventually the cluster metrics started reporting. Client - Cluster metrics: cache_size=100 Client - Local metrics: cache_size=0 -- Sent from:

Bug with client cache_size for metrics() and localMetrics()

IgniteClusterClient.java IgniteClusterNode1.java IgniteClusterNode2.java