case1：According to the official documentation I tried to use the “Distributed Locks” with transactional mode. but it will occur the below when I restart or scale the cluster.so than the new node cannot start
^-- Transactions in deadlock.
^-- Long running transactions (ignore if this is the case).
^-- Unreleased explicit locks，
case2：the ignite.reentrantLock API found in the code ,I try to use it simply,and not error issue found.but this API can not found in official documentation. Is it officially recommended to use it in a production environment?
Case 1
I tried to use the “Distributed Locks” with transactional mode
As the doc says, "Explicit locks are not transactional and cannot not be used from within transactions". Don't use both at the same time.
Case 2
Yes, org.apache.ignite.Ignite#reentrantLock is an official public API:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignite.html#reentrantLock-java.lang.String-boolean-boolean-boolean-
Related
I have two questions regarding the reddison client:
Does redisson support automatic synchronization of local cache with remote redis cache (when remote cache data change or invalidate)?
I understand that redisson supports data partitioning only in pro edition but isn't that feature already supported OOTB by redis cluster mode? Am I missing something here?
Answering to your questions:
RLocalCachedMap has two synchronization strategies:
INVALIDATE - Used by default. Invalidate cache entry across all RLocalCachedMap instances on map entry change.
UPDATE - Update cache entry across all LocalCachedMap instances on map entry change.
Right, all Redisson objects works also in cluster mode. Each object tied to some Redis node and its content always remain only on the same Redis node and not distributed. If your object couldn't fit in single Redis node then you need to use data partitioning feature. This feature evenly distributes content of object across multiple Redis nodes in cluster.
Re: "local cache truely local" -- I think you can just use a java Map, initially populate it with a RMap contents then from then on just serve your requests from the 'truely local' map in memory.
I am trying to read from multiple kafka brokers using KafkaIO on apache beam. The default option for offset management is to the kafka partition itself (no longer using zookeper from kafka >0.9). With this setup, when i restart the job/pipeline, there is issue with duplicate and missing records.
From what i read, the best way to handle this is to manage offset to external data stores. Is it possible to do this with current version of apache beam and KafkaIO? I am using 2.2.0 version right now.
And, after reading from kafka,i will write it to BigQuery. Is there a setup in KafkaIO where I can set the committed message only after i insert the message to BigQuery? I can only find auto commit setup right now.
In Dataflow, you can update a job rather than restarting from scratch. The new job resumes from the last checkpointed state, ensuring exactly-once processing. This works for KafkaIO source as well. The auto-commit option in Kafka consumer configuration helps but it is not atomic with Dataflow internal state, which implies restarted job might have small fraction of duplicate or missing messages.
I am trying to figure how distributed locks are used/implemented in Redis using Redis Template. I have race condition scenario so cant use Optimistic Locking with Multi and Exec.
I see RedisLockService implmentations which implements org.springframework.cloud.cluster.lock.LockService but that has been deprecated. Is there something new that has replaced it.
Why not use Redisson to implement a redis lock. there is a complete set of different distributed lock implementation in Redisson.
I recently migrated from Booksleeve to StackExchange.Redis.
For monitoring purposes, I need to use the MONITOR command.
In the wiki I read
From the IServer instance, the Server commands are available
But I can't find any method concerning MONITOR in IServer ; After a quick search in the repository, it seems this command is not mappped even if RedisCommand.MONITOR is defined.
So, is the MONITOR command supported by StackExchange.Redis ?
Support for monitor is not provided, for multiple reasons:
invoking monitor is a path with of no return; a monitor connection can never be anything except a monitor connection - it certainly doesn't play nicely with the multiplexer (although I guess a separate connection could be used)
monitor is not something that is generally encouraged - it has impact; and when you do use it, it would be a good idea to run it as close to the server as possible (typically in a terminal to the server itself)
it should typically be used for short durations
But more importantly, perhaps, I simply haven't seen a suitable user-case or had a request for it. If there is some scenario where monitor makes sense, I'm happy to consider adding some kind of support. What is it that you want to do with it here?
Note that caveat on the monitor page you link to:
In this particular case, running a single MONITOR client can reduce the throughput by more than 50%. Running more MONITOR clients will reduce throughput even more.
I have to use distributed cache and I would like to use Infinispan 5.3 for that.
I examined the different connection modes and I picked hot rod to implement the client-server communication. I also need to lock a specific key in the cache and later after processing to unlock it (the places for locking and unlocking are in different class in my application...).
I read many documents, articles and forum entries regarding the issue but I haven't found any solution so far. If I interpreted properly what I read then it is not possible to lock the key manually in hot rod. I tried to handle the transactions manually but I am not sure how to do that. Perhaps it is not possible in Infinispan 5.3...?
Or can you tell me a different connection mode (instead of hot rod) that can provide me client-server communication and the locking is solved?
Thanks,
V.
Remote transactions (and locking) via HotRod are not supported in Infinispan 5.3.
See ISPN-375 and ISPN-848.