Maxim, I fixed issue, which you found above. Look
at
org.apache.ignite.internal.processors.cache.ClusterReadOnlyModeTest#testDataStreamerReadOnlyConcurrent*
tests.
вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov :
> >> We throw CacheException on each update to read-only cluster. User code
> must han
I agree with Ivan's concern - do we really need the "activation" concept in
Ignite?
Activation was introduced with Ignite persistence: we must prevent both the
read and write operations on a cluster with persistence on until full data
set is loaded (all the nodes are started). Cluster "activation"
Alex and all,
> From a user's point of view:
> Inactive cluster - deny writes, deny reads.
> Read-only cluster - deny writes, allow reads.
I would be great to explain what is the need to deny both reads and
writes. What tasks are not possible to solve when cluster is in
read-only state?
ср, 5 ию
Ivan,
>From a user's point of view:
Inactive cluster - deny writes, deny reads.
Read-only cluster - deny writes, allow reads.
ср, 5 июн. 2019 г. в 10:44, Павлухин Иван :
> Sergey,
>
> > On inactive cluster caches aren't started. So you can't get data from
> cache.
>
> As a user I do not understa
Sergey,
> On inactive cluster caches aren't started. So you can't get data from
cache.
As a user I do not understand what does it mean for cache to be
started. IgniteCache does not provide start/stop methods.
I am trying to figure out why there should be 2 modes (not from an
implementation point
Maxim, thank you for reproducer. It looks like a bug. I will fix it!
вт, 4 июн. 2019 г. в 15:58, Maxim Muzafarov :
> >> We throw CacheException on each update to read-only cluster. User code
> must handle CacheException correctly .You could find test on it in
> ClusterReadOnlyModeTest#testDataStr
>> We throw CacheException on each update to read-only cluster. User code must
>> handle CacheException correctly .You could find test on it in
>> ClusterReadOnlyModeTest#testDataStreamerReadOnly()
In this test, DataStreamer starts when the cluster already changes its
mode, but not before. Pleas
Hello, Maxim!
>> Do we have an IEP for this feature?
No, we don't have.
>> How we guarantee that all cache operations delivered (or not yet) to
backups are not rejected by applied read-only request?
I reused cluster activation mechanism. So enabling read-only mode generates
an exchange on cluster
Hello, Ivan.
>>What is a fundamental difference between them?
On inactive cluster caches aren't started. So you can't get data from
cache.
вт, 4 июн. 2019 г. в 12:16, Павлухин Иван :
> Sergey, Igniters,
>
> Sorry if my question is not very smart.
>
> I am trying to think about it from a perspect
I don't remember if we agreed on it before. But it may be so, just a
problem for me to remember it. Any big feature - it is quite a vague
definition.
My concern we'll end up with +1 inactive/uncompleted/not actual IEP. For
now, we have a number of open IEPs, and no-one resolves it. I guess it
shou
Hello, Dmitriy.
I don't agree with you.
IEP should be written for any big changes in product.
We should have it for:
1. Following contributors.
2. History of decision making.
3. Easier documenting.
Without IEPs our product will become a total mess.
In the Apache Kafka one can't change any publ
Folks,
Sorry for offtopic. IEP is a good tool for case design is discussed before
any implementation available. It is a good place to share the intent to do
something and provide some details. It is a better place then mile-long
emails.
For now, we have code and documentation later should be upda
Sergey, Igniters,
Sorry if my question is not very smart.
I am trying to think about it from a perspective of a (newbie) user.
And from the first glance it is not clear how a read-only cluster is
different from a not active cluster? What is a fundamental difference
between them? Can we combine tw
Sergey,
Do we have an IEP for this feature?
What should happen when on an active cluster with put operations if we
receive a read-only state change request? How we guarantee that all
cache operations delivered (or not yet) to backups are not rejected by
applied read-only request? I haven't found
Hello, Zhenya, Maxim!
Thank you for your replies!
>> Should we also allow writes to the DistributedMetaStorage and if not why?
Yes. DistributedMetastorage available for updates with enabled read-only
mode. I added test about it to ClusterReadOnlyModeSelfTest
>> What's the purpose for ignite-sys-
hi, Sergey.
What's the purpose for ignite-sys-cache updates still be available ?
thanks !
Hello Igniters!
I'm working on cluster read-only mode [1] feature. In this mode cluster
will be available only for read operations, all data modification
operations in user caches will be rejected
with Cl
Sergey,
I think it will be a very useful feature for Ignite's users, my +1 here.
Can you clarify what kind of updates are written to the ignite-sys-cache?
Should we also allow writes to the DistributedMetaStorage and if not why?
On Thu, 30 May 2019 at 19:55, Dmitriy Pavlov wrote:
>
> ++1 from
++1 from my side. This mode seems to be very useful for Ignite users.
чт, 30 мая 2019 г. в 19:47, Sergey Antonov :
> Hello Igniters!
>
> I'm working on cluster read-only mode [1] feature. In this mode cluster
> will be available only for read operations, all data modification
> operations in user
Hello Igniters!
I'm working on cluster read-only mode [1] feature. In this mode cluster
will be available only for read operations, all data modification
operations in user caches will be rejected
with ClusterReadOnlyModeCheckedException. This feature could be helpfull
for maintenance works (contr
19 matches
Mail list logo
