RE: Key Value Store - control TTL refresh

Hi Stan Thank you for the quick reply. Let me clarify my use case: I want to have expiration for all regular operations. Along with that, I want to be able to read some or all entries without refreshing TTLs, for example for debugging. Following your example, I create a view with expiration and

Get TTL of the specific (K,V) entry

Hi I'm wondering if there is a way to get TTL of specific (K,V) entry, something similar to Redis TTL: https://redis.io/commands/ttl Thank you Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

RE: Key Value Store - control TTL refresh

Hi Stan That makes sense to me. Thank you for explanation. Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Get TTL of the specific (K,V) entry

Hi Val Thank you for confirming this. The use case is to assure correctness of TTL refresh with regard to defined expiry policies and especially views, where different views can have different expiry policies. >From what I saw in examples, to validate that TTL was refreshed, we wait for some

Does object should implement Serializable?

Hi I'm working with regular K,V cache: https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html I'm a bit puzzled whether objects that I want to put into cache should implement Serializable. Documentation(https://apacheignite.readme.io/docs/binary-marshaller) says

RE: Does object should implement Serializable?

Hi Stan Makes sense, thank you for clarification. Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Key Value Store - control TTL refresh

I'd like to set TTL for all entries in some map. Along with that I'd like to control operations that refresh TTL. For instance simple Read/Write should update the TTL, but pulling the whole map should not. Is that something that can be done with current expiry policies?

Transaction progress, affinity, locks

I have 2 different caches C1, C2 on 3 nodes N1, N2, N3. I want to configure it in the most possibly reliable way to avoid any inconsistency and data loss, so both caches are REPLICATED, TRANSACTIONAL, FULL_SYNC. Most of my operations are transactions: PESSIMISTIC, SERIALIZABLE that touch both

Re: Transaction progress, affinity, locks

Hi Pavel Makes sense Thank you Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Assuring quorum

I would like to have a strongly consistent (K,V) cluster of 3 nodes, with a quorum of 2. 1 node can be down / partitioned, but it won't survive the failure of 2 nodes. In my mind, if I start single node when there are 3 nodes specified in TcpDiscoveryVmIpFinder, it should not process requests

Re: Assuring quorum

Makes sense. Thank you. Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Same object different hashes

When fetching a key from different data structures on the client side, I can end up with not finding the object in the cache after putting it there. Server logs will show different hash values for the same object: PUT: *** Received event [cache=demo, evt=CACHE_OBJECT_PUT,

Re: Same object different hashes

Totally makes sense. Thank you. Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Cluster is not responsive after node segmentation and reconciliation

Another interesting piece - sudden ClassNotFoundException - it obviously works in a steady state. ignite-cluster-pairs.log -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Cluster is not responsive after node segmentation and reconciliation

Understood. Those logs are pretty lengthy, let me bring some interesting pieces here. I can separate this part, with communication errors and out of memory ignite-cluster-oom.log -- Sent from:

Re: Conflict resolution during rebalancing

I guess my question is rather about networking partition. Let's say you have 2 servers S1, S2 and 2 clients C1, C2 Let's say network is partitioned [C1,S1] , [C2,S2]. We allow topology of a single node, so both servers stay functional. Let's say C1 writes and C2 writes . What will happen when the

Re: Cluster is not responsive after node segmentation and reconciliation

Understood. Those logs are pretty lengthy, let me bring some interesting pieces here. I can separate this part, with communication errors and out of memory. ignite-cluster-oom.log -- Sent from:

Conflict resolution during rebalancing

I'm looking for pointers on how conflicts in key/values are resolved during rebalancing. Theoretically, if I have a cluster of 2 nodes, CacheWriteSynchronizationMode - FULL_SYNC, CacheRebalanceMode - SYNC. Let's say nodes are partitioned in the network and valid topology is 1 node, so they

Re: Cluster is not responsive after node segmentation and reconciliation

ok, thanks -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Cluster is not responsive after node segmentation and reconciliation

Yeah, this log is JVM log. Let me past it below if it could be of any help. The cluster had less than 1000 records at the time of event. Do you think eviction still can help? Event: 0.728 Thread 0x7fee4404b800 Implicit null exception at 0x7fee353fef75 to 0x7fee353ff335 Event: 0.728

Re: Cluster is not responsive after node segmentation and reconciliation

You are right, this log is JVM log. Let me post some messages below if it can be of any help. The cluster had less than 1000 records at the time of event. Do you still think eviction can help there? Event: 0.993 Thread 0x7fee4404b800 Exception (0x000587b0aad0) thrown at

Re: Cluster is not responsive after node segmentation and reconciliation

The file I've attached contains JVM logs. Let me post it below. About eviction - the cluster didn't have too many records, less than 1000. Do you still think eviction could be useful here? Event: 0.728 Thread 0x7fee4404b800 Implicit null exception at 0x7fee353fef75 to 0x7fee353ff335

Cluster is not responsive after node segmentation and reconciliation

Apache Ignite 2.4A cluster of 3 in-memory nodes, REPLICATED, TRANSACTIONAL.- All 3 nodes got segmented around the same time (Local node SEGMENTED)- After reconciliation, all records are lost- Cluster starts to accumulate transactions: (Pending transaction deadlock detection futures)At this point,

Cluster is not responsive after node segmentation and reconciliation

Apache 2.4 A cluster of 3 in-memory nodes, REPLICATED, TRANSACTIONAL. - All 3 nodes got segmented around the same time (Local node SEGMENTED) - After reconciliation, all records are lost - Cluster starts to accumulate transactions: (Pending transaction deadlock detection futures) At this point,

Re: txSize parameter in transaction

Great, thank you -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Transactions stuck after tearing down cluster

I have in-memory cluster of 3 nodes (2.4), replicated mode, transactional caches. There is a client sending transactions to the cluster. 1. I bring down all 3 server nodes. 2. Bring all of them back. 3. Client sends some transactions - it's stuck, no visible progress Logs show that the client

txSize parameter in transaction

Hi I wanted to start the TX transaction with a timeout value, however the "txStart" API also expects a "txSize" parameter. The documentation states we can pass an approximate value. https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteTransactions.html Could you tell how

Re: Transactions stuck after tearing down cluster

I see. Let me get back to you on that - it may take some time employ 2.7. Thank you Ariel -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

getAll behaviour

Hi I'm reading through forum threads, trying to grasp the getAll behaviour. Also could be useful to know if there were any changes in recent versions. Let's say I have a client running query like cache.query(new ScanQuery()).getAll() on cache in transactional mode with pessimistic locking. My