Hello, Vladimir.
I think we should do the following:
* Update Ignite documentation and write down the fact that in-memory cache
cleared on deactivation.
* Disallow, by default, deactivation of the cluster that has in-memory cache
with proper error message
«Your cluster has in-memory cac
Hi, guys.
I suggest mark as deprecated the IgniteMXBean#active(boolean) method.
The Ignite#active(boolean), IgniteMXBean#active(),
IgniteCluster#active(boolean) methods already deprecated and told to
use the #state(ClusterState)} instead.
Should the old IgniteMXBean#state(ClusterState) method th
Kirill Tkalenko created IGNITE-12680:
Summary: Cleanup unneeded explicit usages of SystemPropertiesRule
Key: IGNITE-12680
URL: https://issues.apache.org/jira/browse/IGNITE-12680
Project: Ignite
Hello everyone,
I've fixed codestyle issues in my branch and got "No possible blockers" in
TC bot, so PR is currently ready for review.
PR github link: https://github.com/apache/ignite/pull/7394
Jira task link: https://issues.apache.org/jira/browse/IGNITE-10698
TeamcityBot link:
https://mtcga.gri
Alexey Goncharuk created IGNITE-12681:
-
Summary: IgniteShutdownOnSupplyMessageFailureTest
Key: IGNITE-12681
URL: https://issues.apache.org/jira/browse/IGNITE-12681
Project: Ignite
Issue T
Igniters,
Do we really need the confirmation flag on the public API? I absolutely
agree on the CLI and MXBean, but what is the reason for the flag in the
API? It will be specified at the compile time anyway and does not prevent
any user error.
>From the implementation point of view I see no contra
Andrey N. Gura created IGNITE-12682:
---
Summary: Remove IgniteMessageFactoryImpl.registerCustom() method
Key: IGNITE-12682
URL: https://issues.apache.org/jira/browse/IGNITE-12682
Project: Ignite
Alexey.
The issue with the existing method.
Single implementation for both Ignite#active(boolean) and
IgniteMXBean#active(boolean)
Should it continue to silently clears in-memory caches?
> 14 февр. 2020 г., в 15:20, Alexey Goncharuk
> написал(а):
>
> Igniters,
>
> Do we really need the conf
Alexey, adding a new method with force flag means old methods change their
behavior: they are considered as executed without ‘force‘ flag and can fail
to prevent data loss. Ignite and IgniteMXBean are different interfaces.
Unfortunately, they have same method
void active(boolean active)
When exe
Hello Vladimir,
> adding a new method with force flag means old methods change their
behavior:
I don't think that changing the behavior of public API is the right way.
Moreover, I agree with Alex that there is no need to introduce a
"confirmation" flag to the java API.
Thanks,
S.
пт, 14 февр. 20
Vyacheslav.
What is your suggestion for the API?
Single implementation for both Ignite#active(boolean) and
IgniteMXBean#active(boolean)
Should public java API continue to silently clears in-memory caches?
> 14 февр. 2020 г., в 15:56, Вячеслав Коптилин
> написал(а):
>
> Hello Vladimir,
>
>>
I merged changes for [1] to master. Next steps will be updating TC
javadoc to fail on a string "Javadoc Warnings"
[1] https://issues.apache.org/jira/browse/IGNITE-12644
Best regards,
Ivan Pavlukhin
сб, 8 февр. 2020 г. в 21:03, Ivan Pavlukhin :
>
> I created a ticket [1] and PR [2]. Please review
Вячеслав, Hi.
Even if previous behavior is controversial? It allows to erase data
suddenly. I would suggest to slightly change API of IgniteMXBean. It would
solve the problem of single implementation IgniteKernal#active(boolean).
But changing of API is prohibited. Another solution is to extract
im
Pavel Pereslegin created IGNITE-12683:
-
Summary:
BPlusTreeReuseListPageMemoryImplTest.testIterateConcurrentPutRemove_2 fails
with timeout on TC
Key: IGNITE-12683
URL: https://issues.apache.org/jira/browse/IGN
* The pr: https://github.com/apache/ignite/pull/7358
One can see the solution closer.
пт, 14 февр. 2020 г. в 15:57, Вячеслав Коптилин :
> Hello Vladimir,
>
> > adding a new method with force flag means old methods change their
> behavior:
> I don't think that changing the behavior of public API
Lev,
it's enough to comment corresponding JIRA ticket. It already contains
all needed info (links to PR, TC bot, etc) and also all changes to the
ticket will be sent to the dev list.
On Fri, Feb 14, 2020 at 1:31 PM Лев Киселев wrote:
>
> Hello everyone,
> I've fixed codestyle issues in my branch
Hello Nikolay,
> Should public java API continue to silently clear in-memory caches?
Let's assume that I have a mixed cluster with persistent cache and
in-memory cache which is backed by 3-rd party persistence. I see no reason
to throw an exception in that case at least.
Anyway, this fact should b
I couldn't find any usages too.
But value if this property is serialized in some places and we can't
remove this due to a backward compatibility.
I think we can safely remove it on 3.0. But for now it is better to
mark it as deprecated.
On Thu, Feb 13, 2020 at 5:42 PM Alexey Goncharuk
wrote:
>
No )
The reasons is serialization of this field. We can mark it as
deprecated and remove in 3.0.
On Thu, Feb 13, 2020 at 6:08 PM Alexei Scherbakov
wrote:
>
> I think yes.
>
> чт, 13 февр. 2020 г. в 16:52, Ivan Pavlukhin :
>
> > Hi,
> >
> > It seems I found some more unused configuration properti
Vyacheslav.
Let’s see what we got for now:
```
Ignite {
@Deprecated
public boolean active();
@Deprecated
public void active(boolean active);
}
IgniteMXBean {
@Deprecated
public boolean active();
public void active(boolean active); //Please, note, this method is no
Soory.
I forgot two more methods
IgniteMXBean {
@Deprecated
public String clusterState();
public void clusterState(String state);
}
> 14 февр. 2020 г., в 17:50, Nikolay Izhikov
> написал(а):
>
> Vyacheslav.
>
>
> Let’s see what we got for now:
>
> ```
> Ignite {
>
>@Depr
Vyacheslav,
>>> Let's assume that I have a mixed cluster with persistent cache and
in-memory cache which is backed by 3-rd party persistence. I see no reason
to throw an exception in that case at least.
if you have only persistent caches, no warning/confirmation is supposed at
all.
>>> Is i
Hi Vladimir,
> if you have only persistent caches, no warning/confirmation is supposed
at all.
I am talking about MIXED cluster with persistent cache and *in-memory*
cache which is backed by *3-rd party persistence*.
> I’m afraid this won’t stop anyone from using old deprecated
IgniteMXBean#activ
Vyacheslav,
>>> I am talking about MIXED cluster with persistent cache and *in-memory*
cache which is backed by *3-rd party persistence*.
We do not know what exactly does *3-rd party persistence*. It may store
only specific filtered data, small part of data. I think it is out of
responsibilit
Kirill Tkalenko created IGNITE-12684:
Summary: Optimize count of threads for rebuild indexes
Key: IGNITE-12684
URL: https://issues.apache.org/jira/browse/IGNITE-12684
Project: Ignite
Issu
25 matches
Mail list logo
