Mikhail,
Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?
пн, 2 дек.
Pavel Tupitsyn created IGNITE-12413:
---
Summary: .NET: XMLDoc does not work when using Ignite NuGet from
.NET Core
Key: IGNITE-12413
URL: https://issues.apache.org/jira/browse/IGNITE-12413
Project:
Hi Ivan.
No other lifecycle events are needed in my case.
We can register a listener in the security component's
GridComponent#onKernalStart method and listen locally to every failed
joining attempt. Am I missing something?
Regards,
Mikhail.
On 03.12.2019 8:48, Ivan Pavlukhin wrote:
Maxim,
I think it would be safer to revert
https://issues.apache.org/jira/browse/IGNITE-11704 from 2.8 release if
there are questions regarding its impact on TC stability. The fix just
provides better approach for handling conflicts with removes (instead of
in-memory deferred deletes queue). It
Alexey Goncharuk created IGNITE-12412:
-
Summary: Incomplete check for ABA problem in
PageMemoryImpl#PagePool
Key: IGNITE-12412
URL: https://issues.apache.org/jira/browse/IGNITE-12412
Project:
Hi Guys,
We have one live cluster(2.6 native persistence) which serving read and
write continuously. Want to setup new cluster using existing cluster data
without stopping.
After coping the existing cluster data files, removed metastorage, wal, wal
archive and cp data. And then started the all
Dear Igniters,
I’m happy to announce that Apache Ignite trademark is registered in the US.
Our website was updated to use "Apache Ignite®" instead of "Apache
Ignite™". Similar updates were applied to some groups in social networks,
and to Russian Local meetups groups at meetup.com. If you
And is the problem specific to range queries or not?
пн, 2 дек. 2019 г. в 11:12, Ivan Pavlukhin :
>
> Yuriy,
>
> Thank you for investigating the problem [1]. Still cannot realize how
> the problem relates to introduced "limit"? Is it right that there were
> no duplicates before "limit" support?
Hi, Ivan.
Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
Hello!
The problem is NOT specific to range queries. Range queries were broken
previously and they are broken now, but now even a simple "token in field
with limit" returns duplicates.
Before limits were introduced, any tested use cases were unaffected by
duplicates, but now they are.
Regards,
Alexey Zinoviev created IGNITE-12411:
Summary: [ML] Finish ML API and fix typos in method names
Key: IGNITE-12411
URL: https://issues.apache.org/jira/browse/IGNITE-12411
Project: Ignite
Yuriy,
Thank you for investigating the problem [1]. Still cannot realize how
the problem relates to introduced "limit"? Is it right that there were
no duplicates before "limit" support? After that support is introduced
are only limited queries contain duplicates, or unlimited, or both?
[1]
Hi, Andrey.
It doesn't influence on authentication or authorization process. There
is a security requirement that demands to notify some outer security
subsystems in a specific way when joining node validation failed in any
Ignite component (e.g. GridCacheProcessor) not only in
Ilya,
I checked your test on a revision before "limit" and it fails there as
well. Could you please double check?
пн, 2 дек. 2019 г. в 13:21, Ilya Kasnacheev :
>
> Hello!
>
> The problem is NOT specific to range queries. Range queries were broken
> previously and they are broken now, but now
Mikhail,
I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?
On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov wrote:
>
> Hi,
Igniters,
I've found a scary error [1] with `CorruptedTreeException: B+Tree is
corrupted` on TC in the master branch. It seems that the issue is
related to a [2] tombstone implementation (probably not).
Can anyone confirm that the problem is still actual?
If it is true, do we have time for
Hi Gangaiah,
Not sure that removal of WAL and cp is a good idea as long as those can
keep info about changes that were not applied checkpointed or applied to
persistence files yet.
A safe way to copy the data is to turn off the write workloads to the
primary cluster, ensure that checkpointing is
17 matches
Mail list logo
