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
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
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
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
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 {
>
>
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 )
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
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:
>
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
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
* 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
Pavel Pereslegin created IGNITE-12683:
-
Summary:
BPlusTreeReuseListPageMemoryImplTest.testIterateConcurrentPutRemove_2 fails
with timeout on TC
Key: IGNITE-12683
URL:
Вячеслав, 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
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
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,
>
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 февр.
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
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
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
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
Alexey Goncharuk created IGNITE-12681:
-
Summary: IgniteShutdownOnSupplyMessageFailureTest
Key: IGNITE-12681
URL: https://issues.apache.org/jira/browse/IGNITE-12681
Project: Ignite
Issue
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:
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
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
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
25 matches
Mail list logo
