Hi Prasad,
Answering your questions:
1. Ignite documentation portal has a "suggest edits" link. You can
suggest an improvement there. Another option is to create a ticket to
improve documentation.
2. You can find both approaches in [1]. You can see a different
picture if cache.put is called.
[1]
Hi Ivan,
Thank you for the clarification.
So the behavior is same for REPLICATED as well as PARTITIONED cache.
1) Can we please have this behavior documented on Ignite web page? This
will just help users to avoid confusion and design their cache effectively.
2) You said "You can check it using
Hi Prasad,
AFAIK, when value is read through it is not sent to backup nodes. You
can check it using IgniteCache.localPeek method (ask if more details
how to do it are needed).
I usually think about read-through cache for a following case. There
is an underlying storage with "real" data, cache is
Ignite Dev team,
This sounds like an issue in our replicated cache implementation rather
than an expected behavior. Especially, if partitioned caches don't have
such a specificity.
Who can explain why write-through needs to be enabled for replicated caches
to reload an entry from an underlying da
Hello!
I think this is by design. You may suggest edits on readme.io.
Regards,
--
Ilya Kasnacheev
пн, 24 февр. 2020 г. в 17:28, Prasad Bhalerao :
> Hi,
>
> Is this a bug or the cache is designed to work this way?
>
> If it is as-designed, can this behavior be updated in ignite documentation?
Hi,
Is this a bug or the cache is designed to work this way?
If it is as-designed, can this behavior be updated in ignite documentation?
Thanks,
Prasad
On Wed, Oct 30, 2019 at 7:19 PM Ilya Kasnacheev
wrote:
> Hello!
>
> I have discussed this with fellow Ignite developers, and they say read
>
Hello!
I have discussed this with fellow Ignite developers, and they say read
through for replicated cache would work where there is either:
- writeThrough enabled and all changes do through it.
- database contents do not change for already read keys.
I can see that neither is met in your case,
Hello!
Can you provide a reproducer project for this problematic behavior? We
could check it, file an issue (or you can file a JIRA issue yourself).
Regards,
--
Ilya Kasnacheev
вт, 29 окт. 2019 г. в 21:01, Akash Shinde :
> Hi,
> I tried this scenario with version 2.7.6 and issue is still ther
Hi,
I tried this scenario with version 2.7.6 and issue is still there with
2.7.6.
I can not go with version 2.7.6 due to IGNITE-10884. This
issue(IGNITE-10884) if fixed but not yet released.
Could you please let me know what is the workaround for replicated cache
issue.
Thanks,
Akash
On Tue, Oct
Hello!
I remember that we had this issue. Have you tried 2.7.6 yet?
Regards,
--
Ilya Kasnacheev
вт, 29 окт. 2019 г. в 18:18, Akash Shinde :
> I am using Ignite 2.6 version.
>
> I am starting 3 server nodes with a replicated cache and 1 client node.
> Cache configuration is as follows.
> Read-
I am using Ignite 2.6 version.
I am starting 3 server nodes with a replicated cache and 1 client node.
Cache configuration is as follows.
Read-through true on but write-through is false. Load data by key is
implemented as given below in cache-loader.
Steps to reproduce issue:
1) Delete an entry f
11 matches
Mail list logo
