I am using Ignite.Net and I have a very simple use case, wherein I want to put something into the cache without any transaction using CacheAtomicityMode.ATOMIC, to achieve that I am trying to use putIfAbsentAsync(key,Value) method.
But having a look at the description of the method on
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#putIfAbsentAsync-K-V- page, I am a bit confused!
Being new to Ignite can you please help me understand this better?Below are my doubts.
Description of putIfAbsentAsync method in the above link states the below
"For CacheAtomicityMode.ATOMIC return value on primary node crash may be incorrect because of the automatic retries.It is recommended to disable retries with withNoRetries() and manually restore primary-backup consistency in case of update failure."
Can you please explain what are automatic retries ? How and when to use it ?
What are pros and cons of disabling retries with withNoRetries() ?
I am also using ReplaceAsync(), RemoveAsync() And PutIfAbsentAsync() with the same cache configuration. Will there be any impact on the functionally of these functions after disabling retries?
What are the possible scenarios where in primary node may crash?
In what scenarios will putIfAbsentAsync() return false?
In what scenarios will putIfAbsentAsync() throw an exception? And List of all possible exception ?
I know the above link states the list of exceptions
(TransactionTimeoutException,TransactionRollbackException,TransactionHeuristicException) But all three are related to Transactions ! I don't really understand why Transaction exception will be thrown in ATOMIC mode, as there aren't any transactions in ATOMIC mode ?
I tried another use case have just one server node and one client node. Server Node creates and stores the cache and client Node just puts or gets cache ,When I manual stopped the server node just before a client node was trying to put something in the cache I got SocketException i.e java.net.SocketException: Socket is closed Exception. If this is a valid use case it would be better if you list these exception on the page.
I don't understand this line "manually restore primary-backup consistency in case of update failure" can you please explain what is primary-backup consistency ? and how to manually restore it ?
withNoRetries() just disallows retries. If operation fails, you get exception promptly. This compared to default behavior where operation will be retried until it is possible.
See more about ATOMIC limitations and IEP-12 in the docs. Note that normally this is only possible when more than one node leaves cluster at once.
Related
If I push a Runnable to a redisson distributed executor service, what rules am I required to oblige by?
Surely , I can not have free reign, I do not see how that is possible, yet, it is not mention in the docs at all, nor are any rules apparently enforced by the API, like R extends Serializable or similar.
If I pass this runnable:
new Runnable(()-> {
// What can I access here, and have it be recreated in whatever server instance picks it up later for execution?
// newlyCreatedInstanceCreatedJustBeforeThisRunnableWasCreated.isAccissible(); // ?
// newlyComplexInstanceSuchAsADatabaseDriverThatisAccessedHere.isAccissible(); // ?
// transactionalHibernateEntityContainingStaticReferencesToComplexObjects....
// I think you get the point.
// Does Redisson serialize everything within this scope?
// When it is recreated later, surely, I can not have access to those exact objects, unless they run on the same server, right?
// If the server goes does and up, or another server executes this runnable, then what happens?
// What rules do we have to abide by here?
})
Also, what rules do we have to abide by when pushing something to a RQueue, RBlockingDequeu, or Redisson live objects?
It is not clear from the docs.
Also, would be great if a link to a single site documentation site could be provided. The one here requires a lot of clickin and navigation:
https://github.com/redisson/redisson/wiki/Table-of-Content
https://github.com/redisson/redisson/wiki/9.-distributed-services#933-distributed-executor-service-tasks
You can have an access to RedisClient and taskId. Full state of task object will be serialized.
TaskRetry setting applied to each task. If task isn't executed after 5 minutes since the moment of start then it will requeued.
I agree that the documentation is lacking some "under the hood" explanations.
I was able to execute db reads and inserts through the Callable/runnable that was submitted to the remote ExecutorService.
I configured a single Redis on a remote VM, the database and the app running locally on my laptop.
The tasks were executed without any errors.
I am new to mulesoft and while studing it i strugle to understand why on module "onErrorPropagate" the error is being rethrown after executing the scope.
can you explain the benefits?
An on-error-propagate will rollback any transactions, execute, and use that result to rethrow the existing error––meaning its owner will be considered as “failing.”
The best use is in a layered system, to allow each layer to do its own small part of an error response.
If you are familiar with Java you can think of it as catching the exception and re-throwing it. For example, sometimes you want to do something with the error yourself, but still want to propagate it upwards for higher levels to deal with.
You could add logging in a specific flow for the error but then leave it to the parent flows to actually deal with the exception.
The "onErrorPropagate" propagates (rethrows) the error to the parent flow (or the global error handler if it's already reached the main flow).
This can be usefull in a few cases.
Say you have some flow specific error handling (e.g. if something goes wrong, set a default payload).
Then you propagate this error to the next level where you have your Global error handler that, say, stores some info in a QA database.
You don't want to have that database connector in every single error handler.
In this way you can achieve a 'java inherritance' like structure, for your errors.
Side note: if you want your error to only be handled and do nothing further, you can use "onErrorContinue"
I have an operation contract, on a windows service and it has an attribute
[OperationBehavior(TransactionScopeRequired = true)]
I would like to get rid of this attribute. Reason :
containerize the service.
and Containerized apps do not support MSDTC , that's the purpose of the attribute!
What are the implications of doing this?
I can confirm the code within the operation contract inserts into a single database.
No events triggered, however I am unsure of whether there is a transaction where the service is consumed.
Can I get some advice on this?
Your service is requiring a transaction.
Only you can know whether this is necessary, we cannot check your service and database to check.
Please be aware that this enables not only local transactions, but -depending on binding- also enables distributed transactions. See here for details.
You new system does not seem to support this (MSDTC is the Distributed Transaction Controller from MS). Again, whether this is a problem when you move over to this system is nothing we could find out. You will have to have a look at the system architecture and see whether this is something that was included "just because" and can be deleted without replacement, or if it's a key feature of your system that you need to keep.
1.Which category of CAP theoram does ignite fall under ?
2.While doing a loadCache using a client on multiple Servers , after the loadCache being called if the client goes down, will the operation complete on the Servers ?(Unable to try it due to some permission restriction)
Ignite guarantees data consistency. In case of cluster is segmented into two parts, they can't be merged back. One of the parts has to be considered invalid and restarted.
Most likely data will not be fully loaded in this case. The loading process should be restarted.
For the first question: the enum of CacheAtomicityMode has two values
TRANSACTIONAL: if you configure this in you CacheConfigure, then your application is CP
ATOMIC: if you configure this in you CacheConfigure, then your application is AP, and ATOMIC is the default value.
For the second question: if your client is embeddedwith your application，locaCache failed for some reason, then CacheLoaderException will be throw. If you want to custome CacheStore，you can extend CacheStoreAdapter and override method.
What would I need to be doing wrong to get an aggregate to be returned from the session (loading by id) that is an empty instance of the aggregate and not the entire graph. When I hit the actual url that is requested in my browser I see the full json object, hence, why I am suspicious of my session management.
I have tried recreating the situation in unit tests but no manner of poor session management can recreate what I am seeing. I see some null instances returned but never this strange 'empty' instance - which has an id but none of the properties have been hydrated.
I am seeing this behaviour in unstable build 438.
I just checked the behaviour by executing a query and am seeing the same issue, so it is not just when calling Load()
If you are seeing symptoms similar to those that I presented in the original question - the most likely scenario is that you are loading the entity via a 'stale' session.
I discovered that due to some IoC container config flaws on my behalf (remember, singletons are bad kiddies) that I was attempting to load via a session that had been hanging around far too long. I can't determine whether it had been disposed or not (I suspect not) but it was definitely living well past its creation date.
I am not sure this exactly explains the behaviour I was seeing, but I present it here in the hope of helping others.