Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Denis, Currently, we have no blockers. I'm preparing the build. On Thu, 20 Feb 2020 at 21:10, Denis Magda wrote: > > Folks, > > Is there anything else apart from the open documentation tickets that > prevent us from starting the release vote? I think that it should take > around two weeks to run the release through the vote and announce it. The > top doc changes should be finished throughout that time already. > > - > Denis > > > On Wed, Feb 19, 2020 at 9:55 AM Maxim Muzafarov wrote: > > > Ilya, > > > > > > I think we must accept only blocker issues to the release branch. > > > > My previous experience tells me that even a small change which seems > > absolutely easy and clear can break everything. So, let's move this > > issue [1] to the next release. Currently, it doesn't look like a > > blocker. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12672 > > > > On Tue, 18 Feb 2020 at 13:51, Maxim Muzafarov wrote: > > > > > > Igniters, > > > > > > > > > I've prepared the issue [1] and PR [2] with removing @deprecate > > > annotation on DataRegionMetrics and adding @IgniteExperimental to the > > > new metrics API. > > > Can anyone review my changes? > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12690 > > > [2] https://github.com/apache/ignite/pull/7440 > > > > > > On Tue, 18 Feb 2020 at 13:42, Ilya Kasnacheev > > wrote: > > > > > > > > Hello! > > > > > > > > I have just merged a fix for embarrassing issue where you could UPDATE > > > > entries with Spring Data, but not "Update" or "update" them. > > > > > > > > I suggest adding this fix to the scope of 2.8, since Spring Data is > > popular > > > > and it does not in any way affect code outside of its modules. > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12672 > > > > > > > > WDYT? > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пн, 17 февр. 2020 г. в 12:44, Maxim Muzafarov : > > > > > > > > > Alexey, > > > > > > > > > > > > > > > Yes. I will remove @deprecation according to the vote results and > > will > > > > > go further with the release steps [1] since there no blockers left. > > > > > > > > > > > > > > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > > > > > > > > > On Mon, 17 Feb 2020 at 11:48, Alexey Goncharuk > > > > > wrote: > > > > > > > > > > > > Folks, > > > > > > > > > > > > I have merged IGNITE-12650 (mark MVCC as experimental) to master > > and > > > > > > ignite-2.8. What's left? Should we remove deprecation from the old > > > > > metrics > > > > > > and start the vote? > > > > > > >
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Hi, Pavel
This feature looks very interesting, can you add me as a reviewer please.
Or maybe I can contribute somehow?
Thanks,
Sergey.
On Tue, 18 Feb 2020 at 20:46, Pavel Tupitsyn wrote:
> Ilya, looks like there is a misunderstanding.
>
> We don't start near cache on a subset of server nodes. Let me explain
> again.
> Consider the following code, executed on any node (client or server - does
> not matter):
>
> ignite.createCache(new CacheConfiguration("c").setNearConfiguration(new
> NearCacheConfiguration()));
>
> As a result, cache "c" is started on all server nodes, and corresponding
> near cache is started on all server nodes,
> with the same config, eviction policy, and so on.
>
> Now, what do we do with .NET near cache in this situation?
> 1. Start .NET near cache as well on server nodes, always.
> 2. Introduce a config flag, and start .NET near cache only when the flag is
> set
>
> The problem with option (1) is that it changes the behavior of existing
> applications,
> increasing overhead for cache operations and increasing memory usage.
>
> As a user, I don't want some new features to be force-enabled on me
> silently in a new product version.
> That is why an opt-in config flag is required.
>
> Does this make sense?
>
> On Tue, Feb 18, 2020 at 6:42 PM Ilya Kasnacheev >
> wrote:
>
> > Hello!
> >
> > I'm not sure that we can/want to create near cache on a subset of server
> > nodes.
> >
> > If this is indeed possible, I would decouple that from .Net and introduce
> > as a separate feature.
> >
> > Ideally we should be able to start or stop near cache on any node, server
> > or client, and this should be the same cache for all platforms (including
> > Java). WDYT?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 18 февр. 2020 г. в 17:31, Pavel Tupitsyn :
> >
> > > Ilya, as noted above:
> > >
> > > > There are 2 kinds of Near Caches:
> > > > - On client nodes: created per-node by calling ignite.CreateNearCache
> > > > - On server nodes: created on all server nodes if
> > > CacheConfiguration.NearCacheConfiguration is not null
> > > >
> > > > When user says ignite.CreateCache(new CacheConfiguration
> > > {NearCacheConfiguration = ...}),
> > > > the whole config is sent to all server nodes, and .NET-specific flag
> > has
> > > to be included somehow.
> > >
> > >
> > >
> > > On Tue, Feb 18, 2020 at 5:10 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > Why would it waste additional memory? All nodes are also Java nodes
> so
> > > they
> > > > will start near caches all right.
> > > >
> > > > Don't we have near cache start-up on per-node basis for clients,
> > anyway?
> > > >
> > > > I'm not convinced why we need this flag. I have to admit my
> > understanding
> > > > of near caches is limited.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > вт, 18 февр. 2020 г. в 16:56, Pavel Tupitsyn :
> > > >
> > > > > Ilya, Aleksandr,
> > > > >
> > > > > The flag is called platformNearCacheEnabled, my idea is to have
> just
> > > one
> > > > > flag for all platforms.
> > > > >
> > > > > If some platform is present on the given node (.NET, C++) and it
> > > supports
> > > > > native near caching,
> > > > > then the flag is honored, otherwise it is ignored. We should not
> > throw
> > > > > exceptions,
> > > > > because mixed clusters are possible (.NET nodes along with Java
> > nodes).
> > > > >
> > > > > > Why would enabling it affect mixed`clusters?
> > > > > Initially the idea was to enable .NET near cache whenever
> > > > > NearCacheConfiguration is present.
> > > > > If we assume .NET-only clusters, it makes sense: existing code will
> > > work
> > > > > faster automatically.
> > > > >
> > > > > Mixed cluster is just one of the possible use cases when this may
> be
> > a
> > > > bad
> > > > > idea,
> > > > > e.g. users have enabled near caching to speed up their Java-based
> > > > > computations,
> > > > > and .NET nodes are used for something else, wasting memory on near
> > > > caching
> > > > > unnecessarily.
> > > > >
> > > > > On ue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin <
> lexw...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Pavel,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think it’s ok to add a new flag.
> > > > > >
> > > > > > Though we may change a name to something like
> > > > > #usePlatformCacheIfAvailable
> > > > > >
> > > > > >
> > > > > >
> > > > > > But it may vary depending on the implementation, i.e.
> > > > > >
> > > > > > should we throw an error if there is no native cache
> > > > > >
> > > > > > available for a platform or just ignore the configuration.
> > > > > >
> > > > > > вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > > >
> > > > > > > Igor,
> > > > > > >
> > > > > > > The problem is - we need to pass this flag around the
> cluster`for
> > > > > Server
> > > > > > > Near Caches,
> > > > > > > so that .NET near
[jira] [Created] (IGNITE-12710) Extension log in rebuild indexes to search problems
Sergey Antonov created IGNITE-12710: --- Summary: Extension log in rebuild indexes to search problems Key: IGNITE-12710 URL: https://issues.apache.org/jira/browse/IGNITE-12710 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 We should have the ability to get extended information about rebuild indexes: cache, cache id, cache group, cache group id, index name, index type, index size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Let's make BinaryObjectImpl and CacheKeyObject Comparable
Hi Ilya, We can oblige users to implement Comparable if they use BinaryObject keys. Ignite can print out a warning if BinaryObject keys passed to putAll methods don't do that. I also wonder how a similar task was solved for Ignite INSERTs. Our engine should use BinaryObjects for compound primary keys and insert them at patches. That implementation can suggest us some hints. - Denis On Thu, Feb 20, 2020 at 6:53 AM Ilya Kasnacheev wrote: > Hello! > > Since we have merged https://issues.apache.org/jira/browse/IGNITE-6804 we > have to face an embarrassing fact that BinaryObject is not Comparable, > i.e., when you do cache.withKeepBinary().putAll(), there are no obvious > ways to not get a deadlock (or at least warning) here. > > One can use LinkedHashMap, but they will have to sort BinaryObject's on > their side, which is not trivial. > > So my proposal is to make BinaryObjectImpl and KeyCacheObject (?) > Comparable, by their binary representation. We can't add this constraint to > BinaryObject since it is a public interface (can we), but we can do that > for the implementation types. What do you think? > > Regards, > -- > Ilya Kasnacheev >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Folks, Is there anything else apart from the open documentation tickets that prevent us from starting the release vote? I think that it should take around two weeks to run the release through the vote and announce it. The top doc changes should be finished throughout that time already. - Denis On Wed, Feb 19, 2020 at 9:55 AM Maxim Muzafarov wrote: > Ilya, > > > I think we must accept only blocker issues to the release branch. > > My previous experience tells me that even a small change which seems > absolutely easy and clear can break everything. So, let's move this > issue [1] to the next release. Currently, it doesn't look like a > blocker. > > [1] https://issues.apache.org/jira/browse/IGNITE-12672 > > On Tue, 18 Feb 2020 at 13:51, Maxim Muzafarov wrote: > > > > Igniters, > > > > > > I've prepared the issue [1] and PR [2] with removing @deprecate > > annotation on DataRegionMetrics and adding @IgniteExperimental to the > > new metrics API. > > Can anyone review my changes? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12690 > > [2] https://github.com/apache/ignite/pull/7440 > > > > On Tue, 18 Feb 2020 at 13:42, Ilya Kasnacheev > wrote: > > > > > > Hello! > > > > > > I have just merged a fix for embarrassing issue where you could UPDATE > > > entries with Spring Data, but not "Update" or "update" them. > > > > > > I suggest adding this fix to the scope of 2.8, since Spring Data is > popular > > > and it does not in any way affect code outside of its modules. > > > > > > https://issues.apache.org/jira/browse/IGNITE-12672 > > > > > > WDYT? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пн, 17 февр. 2020 г. в 12:44, Maxim Muzafarov : > > > > > > > Alexey, > > > > > > > > > > > > Yes. I will remove @deprecation according to the vote results and > will > > > > go further with the release steps [1] since there no blockers left. > > > > > > > > > > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > > > > > > > On Mon, 17 Feb 2020 at 11:48, Alexey Goncharuk > > > > wrote: > > > > > > > > > > Folks, > > > > > > > > > > I have merged IGNITE-12650 (mark MVCC as experimental) to master > and > > > > > ignite-2.8. What's left? Should we remove deprecation from the old > > > > metrics > > > > > and start the vote? > > > > >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Hello Maxim,
> Properties are not too important and we can remove unnecessary
> functionality reflecting them even, for 2.8 -> 2.9 releases for instance.
IMHO, we should preserve source, binary and behavioral compatibility.
Removing methods from public API may break all these requirements.
> As for rebalancing SYNC caches first like here [1], it breaks the
> meaning of currently used `rebalanceOrder` property. The ASYNC cache
> with the rebalance order `1` will be rebalanced after the SYNC cache
> with the rebalance order `2`.
> https://issues.apache.org/jira/browse/IGNITE-12705
This is not correct. Please take a look at javadoc:
Note that a cache with {@link CacheRebalanceMode#SYNC SYNC} rebalancing
mode always takes precedence over caches with {@link
CacheRebalanceMode#ASYNC ASYNC} rebalancing mode
in the group of caches with *the same rebalance order.*
This means that ASYNC cache with rebalance order '1' will be rebalanced *before
*the SYNC cache with the rebalance order '2' in your example.
Thanks,
Slava.
чт, 20 февр. 2020 г. в 17:18, Maxim Muzafarov :
> Slava,
>
> I don't know the right answer to this case, but I think what exactly
> compatibility is important:
>
> 1. PDS compatibility
> 2. Messaging compatibility
> 3. Rolling upgrades
> 4. Compile application on newer 2.x version
>
> Properties are not too important and we can remove unnecessary
> functionality reflecting them even, for 2.8 -> 2.9 releases for
> instance.
>
>
> As for rebalancing SYNC caches first like here [1], it breaks the
> meaning of currently used `rebalanceOrder` property. The ASYNC cache
> with the rebalance order `1` will be rebalanced after the SYNC cache
> with the rebalance order `2`. This will confuse users much more than
> removing rebalanceDelay\rebalanceOrder functionality.
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12705
>
> On Thu, 20 Feb 2020 at 16:49, Вячеслав Коптилин
> wrote:
> >
> > Hello Maxim,
> >
> > In general, we should not remove existing public APIs / properties until
> > the major version is released, even though the community has an agreement
> > that these properties are useless.
> > I fully support the idea that rebalanceOrder, rebalanceDelay, and
> > CacheRebalanceMode#NONE should be marked with @Deprecated right now and
> > should be removed in a major version of AI.
> >
> > Thanks,
> > S.
> >
> > чт, 20 февр. 2020 г. в 16:41, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > >
> > > Can we not only mark `rebalanceDelay` and `rebalanceOrder` with
> > > @deprecated annotation but also remove its support from the source
> > > code? For instance, for the next 2.9 release. I see the next
> > > advantages here:
> > >
> > > 1. It will greatly simplify the implementation of ExchageManager (It
> > > also overcomplicated for now).
> > > 2. We already have BLT support for persistence and in-memory caches,
> > > so from a user perspective, there are no changes (in general).
> > >
> > >
> > > Also, I think these properties were had meaning for Apache Ignite 1.x
> > > version, but not for 2.x.
> > > Are there any reasons to wait for removing them it 3.0?
> > >
> > > On Tue, 18 Feb 2020 at 12:21, Alexei Scherbakov
> > > wrote:
> > > >
> > > > Folks,
> > > >
> > > > Looks like we came to an agreement - rebalanceDelay and
> rebalanceOrder
> > > > should be deprecated.
> > > >
> > > > Anyone else has objections ?
> > > >
> > > >
> > > > чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov <
> > > > alexey.scherbak...@gmail.com>:
> > > >
> > > > > But in combination with BLT it will work as intended - no
> rebalancing
> > > > > under the cover.
> > > > >
> > > > > чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov <
> > > > > alexey.scherbak...@gmail.com>:
> > > > >
> > > > >> Of course, stable topology will be just a hint.
> > > > >>
> > > > >> Any node can leave at any moment.
> > > > >>
> > > > >> чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov <
> > > > >> alexey.scherbak...@gmail.com>:
> > > > >>
> > > > >>> 1. Yes
> > > > >>>
> > > > >>> 2. This is right but doesn't sound like a bug. The rebalancing
> will
> > > be
> > > > >>> finished before releasing syncFut and partitions will contain all
> > > necessary
> > > > >>> data (but are still in moving state).
> > > > >>>
> > > > >>> 3. No, local node doesn't wait the rebalancing on all grid nodes.
> > > > >>>
> > > > >>> Actually, I think SYNC mode should be dropped as well. Instead we
> > > must
> > > > >>> provide the convenient public API to wait for "stable" topology.
> > > > >>>
> > > > >>>
> > > > >>> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov >:
> > > > >>>
> > > > Pavel,
> > > >
> > > > It's still a big question regarding SYNC rebalance mode. Here
> is my
> > > > thoughts.
> > > >
> > > > 1. Yes, we must rebalance such caches prior to ASYNC one (if the
> > > > rebalanceOrder configuration will be removed).
> > > >
> > > > 2. When persistence is enabled and when WAL is disabled (on the
> > >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Slava, I don't know the right answer to this case, but I think what exactly compatibility is important: 1. PDS compatibility 2. Messaging compatibility 3. Rolling upgrades 4. Compile application on newer 2.x version Properties are not too important and we can remove unnecessary functionality reflecting them even, for 2.8 -> 2.9 releases for instance. As for rebalancing SYNC caches first like here [1], it breaks the meaning of currently used `rebalanceOrder` property. The ASYNC cache with the rebalance order `1` will be rebalanced after the SYNC cache with the rebalance order `2`. This will confuse users much more than removing rebalanceDelay\rebalanceOrder functionality. [1] https://issues.apache.org/jira/browse/IGNITE-12705 On Thu, 20 Feb 2020 at 16:49, Вячеслав Коптилин wrote: > > Hello Maxim, > > In general, we should not remove existing public APIs / properties until > the major version is released, even though the community has an agreement > that these properties are useless. > I fully support the idea that rebalanceOrder, rebalanceDelay, and > CacheRebalanceMode#NONE should be marked with @Deprecated right now and > should be removed in a major version of AI. > > Thanks, > S. > > чт, 20 февр. 2020 г. в 16:41, Maxim Muzafarov : > > > Folks, > > > > > > Can we not only mark `rebalanceDelay` and `rebalanceOrder` with > > @deprecated annotation but also remove its support from the source > > code? For instance, for the next 2.9 release. I see the next > > advantages here: > > > > 1. It will greatly simplify the implementation of ExchageManager (It > > also overcomplicated for now). > > 2. We already have BLT support for persistence and in-memory caches, > > so from a user perspective, there are no changes (in general). > > > > > > Also, I think these properties were had meaning for Apache Ignite 1.x > > version, but not for 2.x. > > Are there any reasons to wait for removing them it 3.0? > > > > On Tue, 18 Feb 2020 at 12:21, Alexei Scherbakov > > wrote: > > > > > > Folks, > > > > > > Looks like we came to an agreement - rebalanceDelay and rebalanceOrder > > > should be deprecated. > > > > > > Anyone else has objections ? > > > > > > > > > чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com>: > > > > > > > But in combination with BLT it will work as intended - no rebalancing > > > > under the cover. > > > > > > > > чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov < > > > > alexey.scherbak...@gmail.com>: > > > > > > > >> Of course, stable topology will be just a hint. > > > >> > > > >> Any node can leave at any moment. > > > >> > > > >> чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov < > > > >> alexey.scherbak...@gmail.com>: > > > >> > > > >>> 1. Yes > > > >>> > > > >>> 2. This is right but doesn't sound like a bug. The rebalancing will > > be > > > >>> finished before releasing syncFut and partitions will contain all > > necessary > > > >>> data (but are still in moving state). > > > >>> > > > >>> 3. No, local node doesn't wait the rebalancing on all grid nodes. > > > >>> > > > >>> Actually, I think SYNC mode should be dropped as well. Instead we > > must > > > >>> provide the convenient public API to wait for "stable" topology. > > > >>> > > > >>> > > > >>> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov : > > > >>> > > > Pavel, > > > > > > It's still a big question regarding SYNC rebalance mode. Here is my > > > thoughts. > > > > > > 1. Yes, we must rebalance such caches prior to ASYNC one (if the > > > rebalanceOrder configuration will be removed). > > > > > > 2. When persistence is enabled and when WAL is disabled (on the > > first > > > rebalance start), I think we should finish syncFuture only on > > > checkpoint like we are enabling the WAL state for cache group and > > > simultaneously owning all MOVING partitions. But currently, I've > > seen > > > that syncFuture finishes when there are no remaining partitions left > > > [1]. > > > Is it correct? Seems like a bug. > > > > > > 3. In my understanding, a new local node can start only when ALL > > SYNC > > > cache groups have been fully rebalanced on ALL nodes, right? But how > > > about late affinity assignment here? It seems that SYNC caches will > > be > > > rebalanced locally on the node, the node will start, but other nodes > > > still think this node is not operational (late affinity assignment > > not > > > occurred yet). > > > > > > > > > [1] > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1561 > > > > > > On Thu, 13 Feb 2020 at 12:57, Pavel Pereslegin > > > wrote: > > > > > > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > > > Meant to "rework related functionality" not "remove".
Re: Security Subject of thin client on remote nodes
> I just transmitted security subjects for rest requests. SecurityContext has an unlimited size so we can get significant overhead. And we do not solve problems with other thin clients. >If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old versions and new. I suggest removing ATTR_SECURITY_SUBJECT_V2 from Ignite's codebase, but for compatibility, it can be used by a security plugin like in PoC. чт, 20 февр. 2020 г. в 16:47, Maksim Stepachev : > Yes, I said about it at 07.19. > > http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708 > And in my solution, I just transmitted security subjects for rest requests. > > If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old > versions and new. > > чт, 20 февр. 2020 г. в 15:56, Denis Garus : > > > Hi, Igniters! > > > > > > At present, a security subject id is assumed to be node id. > > > > But when we are dealing with thin client, JDBC or REST subject id is > random > > UUID. In this case, we cannot get the subject information on a remote > node, > > and we get problems like these [1], [2]. > > > > To fix the problem, we should spread the client session to the whole > > cluster. > > > > > > I want to suggest a solution to the problem. > > > > > > First, we should get subject information using GridSecurityProcessor. > > > > How GridSecurityProcessor will retrieve a subject data, it is up to > plugin > > developers. > > > > > > Second, we should get rid of the assumption that a subject id is a node > id > > and remove the ATTR_SECURITY_SUBJECT_V2 attribute. > > > > > > I have prepared PoC PR [3] that: > > > > - places the existing logic of spreading security context to > > GridSecurityProcessor; > > > > - uses GridSecurityProcessor to get SecurityContext. > > > > > > > >1. > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html > >2. https://issues.apache.org/jira/browse/IGNITE-12589 > >3. https://github.com/apache/ignite/pull/7375 > > >
[jira] [Created] (IGNITE-12709) Server latch initialized after client latch in Zookeeper discovery
Anton Kalashnikov created IGNITE-12709:
--
Summary: Server latch initialized after client latch in Zookeeper
discovery
Key: IGNITE-12709
URL: https://issues.apache.org/jira/browse/IGNITE-12709
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
The coordinator node missed latch message from the client because it doesn't
receive a triggered message of exchange. So it leads to infinity wait of answer
from the coordinator.
{noformat}
[2019-10-23
12:49:42,110]\[ERROR]\[sys-#39470%continuous.GridEventConsumeSelfTest0%]\[GridIoManager]
An error occurred processing the message \[msg=GridIoMessage \[plc=2,
topic=TOPIC_EXCHANGE, topicOrd=31, ordered=fa
lse, timeout=0, skipOnTimeout=false,
msg=org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.LatchAckMessage@7699f4f2],
nodeId=857a40a8-f384-4740-816c-dd54d3a1].
class org.apache.ignite.IgniteException: Topology AffinityTopologyVersion
\[topVer=54, minorTopVer=0] not found in discovery history ; consider
increasing IGNITE_DISCOVERY_HISTORY_SIZE property. Current value is
-1
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.aliveNodesForTopologyVer(ExchangeLatchManager.java:292)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.getLatchCoordinator(ExchangeLatchManager.java:334)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.processAck(ExchangeLatchManager.java:379)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.lambda$new$0(ExchangeLatchManager.java:119)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1632)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1252)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:143)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1143)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[2019-10-23 12:50:02,106]\[WARN
]\[exchange-worker-#39517%continuous.GridEventConsumeSelfTest1%]\[GridDhtPartitionsExchangeFuture]
Unable to await partitions release latch within timeout: ClientLatch
\[coordinator=ZookeeperClusterNode \[id=760ca6b5-f30b-4c40-81b1-5b602c20,
addrs=\[127.0.0.1], order=1, loc=false, client=false], ackSent=true,
super=CompletableLatch \[id=CompletableLatchUid \[id=exchange,
topVer=AffinityTopologyVersion \[topVer=54, minorTopVer=0
[2019-10-23 12:50:02,192]\[WARN
]\[exchange-worker-#39469%continuous.GridEventConsumeSelfTest0%]\[GridDhtPartitionsExchangeFuture]
Unable to await partitions release latch within timeout: ServerLatch
\[permits=1, pendingAcks=HashSet \[06c3094b-c1f3-4fe8-81e8-22cb6602],
super=CompletableLatch \[id=CompletableLatchUid \[id=exchange,
topVer=AffinityTopologyVersion \[topVer=54, minorTopVer=0
{noformat}
Reproduced by
org.apache.ignite.internal.processors.continuous.GridEventConsumeSelfTest#testMultithreadedWithNodeRestart
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Hello Maxim, In general, we should not remove existing public APIs / properties until the major version is released, even though the community has an agreement that these properties are useless. I fully support the idea that rebalanceOrder, rebalanceDelay, and CacheRebalanceMode#NONE should be marked with @Deprecated right now and should be removed in a major version of AI. Thanks, S. чт, 20 февр. 2020 г. в 16:41, Maxim Muzafarov : > Folks, > > > Can we not only mark `rebalanceDelay` and `rebalanceOrder` with > @deprecated annotation but also remove its support from the source > code? For instance, for the next 2.9 release. I see the next > advantages here: > > 1. It will greatly simplify the implementation of ExchageManager (It > also overcomplicated for now). > 2. We already have BLT support for persistence and in-memory caches, > so from a user perspective, there are no changes (in general). > > > Also, I think these properties were had meaning for Apache Ignite 1.x > version, but not for 2.x. > Are there any reasons to wait for removing them it 3.0? > > On Tue, 18 Feb 2020 at 12:21, Alexei Scherbakov > wrote: > > > > Folks, > > > > Looks like we came to an agreement - rebalanceDelay and rebalanceOrder > > should be deprecated. > > > > Anyone else has objections ? > > > > > > чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov < > > alexey.scherbak...@gmail.com>: > > > > > But in combination with BLT it will work as intended - no rebalancing > > > under the cover. > > > > > > чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov < > > > alexey.scherbak...@gmail.com>: > > > > > >> Of course, stable topology will be just a hint. > > >> > > >> Any node can leave at any moment. > > >> > > >> чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov < > > >> alexey.scherbak...@gmail.com>: > > >> > > >>> 1. Yes > > >>> > > >>> 2. This is right but doesn't sound like a bug. The rebalancing will > be > > >>> finished before releasing syncFut and partitions will contain all > necessary > > >>> data (but are still in moving state). > > >>> > > >>> 3. No, local node doesn't wait the rebalancing on all grid nodes. > > >>> > > >>> Actually, I think SYNC mode should be dropped as well. Instead we > must > > >>> provide the convenient public API to wait for "stable" topology. > > >>> > > >>> > > >>> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov : > > >>> > > Pavel, > > > > It's still a big question regarding SYNC rebalance mode. Here is my > > thoughts. > > > > 1. Yes, we must rebalance such caches prior to ASYNC one (if the > > rebalanceOrder configuration will be removed). > > > > 2. When persistence is enabled and when WAL is disabled (on the > first > > rebalance start), I think we should finish syncFuture only on > > checkpoint like we are enabling the WAL state for cache group and > > simultaneously owning all MOVING partitions. But currently, I've > seen > > that syncFuture finishes when there are no remaining partitions left > > [1]. > > Is it correct? Seems like a bug. > > > > 3. In my understanding, a new local node can start only when ALL > SYNC > > cache groups have been fully rebalanced on ALL nodes, right? But how > > about late affinity assignment here? It seems that SYNC caches will > be > > rebalanced locally on the node, the node will start, but other nodes > > still think this node is not operational (late affinity assignment > not > > occurred yet). > > > > > > [1] > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1561 > > > > On Thu, 13 Feb 2020 at 12:57, Pavel Pereslegin > > wrote: > > > > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > > Meant to "rework related functionality" not "remove". > > > > > > чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin >: > > > > > > > > Hello, > > > > > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > > > should we create a separate ticket for this? > > > > > > > > Btw, as I understand, SYNC mode is only useful for in-memory > caches, > > > > because when persistence is enabled (and WAL is disabled during > > > > rebalancing), even "ignite-sys-cache" owns partitions only > after all > > > > cache groups are rebalanced. Thus, even utility cache is still > > > > inoperable after node startup when persistence is enabled. Do we > > > > really need to wait for SYNC caches when a node starts with > enabled > > > > persistence or should we enabled WAL for SYNC-caches? > > > > > > > > чт, 13 февр. 2020 г. в 11:13, Ivan Rakov >: > > > > > > > > > > Hello, > > > > > > > > > > +1 from me for rebalance delay deprecation. > > > > > I can
Re: Security Subject of thin client on remote nodes
Yes, I said about it at 07.19. http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708 And in my solution, I just transmitted security subjects for rest requests. If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility between old versions and new. чт, 20 февр. 2020 г. в 15:56, Denis Garus : > Hi, Igniters! > > > At present, a security subject id is assumed to be node id. > > But when we are dealing with thin client, JDBC or REST subject id is random > UUID. In this case, we cannot get the subject information on a remote node, > and we get problems like these [1], [2]. > > To fix the problem, we should spread the client session to the whole > cluster. > > > I want to suggest a solution to the problem. > > > First, we should get subject information using GridSecurityProcessor. > > How GridSecurityProcessor will retrieve a subject data, it is up to plugin > developers. > > > Second, we should get rid of the assumption that a subject id is a node id > and remove the ATTR_SECURITY_SUBJECT_V2 attribute. > > > I have prepared PoC PR [3] that: > > - places the existing logic of spreading security context to > GridSecurityProcessor; > > - uses GridSecurityProcessor to get SecurityContext. > > > >1. > > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html >2. https://issues.apache.org/jira/browse/IGNITE-12589 >3. https://github.com/apache/ignite/pull/7375 >
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Folks, Can we not only mark `rebalanceDelay` and `rebalanceOrder` with @deprecated annotation but also remove its support from the source code? For instance, for the next 2.9 release. I see the next advantages here: 1. It will greatly simplify the implementation of ExchageManager (It also overcomplicated for now). 2. We already have BLT support for persistence and in-memory caches, so from a user perspective, there are no changes (in general). Also, I think these properties were had meaning for Apache Ignite 1.x version, but not for 2.x. Are there any reasons to wait for removing them it 3.0? On Tue, 18 Feb 2020 at 12:21, Alexei Scherbakov wrote: > > Folks, > > Looks like we came to an agreement - rebalanceDelay and rebalanceOrder > should be deprecated. > > Anyone else has objections ? > > > чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > > > But in combination with BLT it will work as intended - no rebalancing > > under the cover. > > > > чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov < > > alexey.scherbak...@gmail.com>: > > > >> Of course, stable topology will be just a hint. > >> > >> Any node can leave at any moment. > >> > >> чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov < > >> alexey.scherbak...@gmail.com>: > >> > >>> 1. Yes > >>> > >>> 2. This is right but doesn't sound like a bug. The rebalancing will be > >>> finished before releasing syncFut and partitions will contain all > >>> necessary > >>> data (but are still in moving state). > >>> > >>> 3. No, local node doesn't wait the rebalancing on all grid nodes. > >>> > >>> Actually, I think SYNC mode should be dropped as well. Instead we must > >>> provide the convenient public API to wait for "stable" topology. > >>> > >>> > >>> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov : > >>> > Pavel, > > It's still a big question regarding SYNC rebalance mode. Here is my > thoughts. > > 1. Yes, we must rebalance such caches prior to ASYNC one (if the > rebalanceOrder configuration will be removed). > > 2. When persistence is enabled and when WAL is disabled (on the first > rebalance start), I think we should finish syncFuture only on > checkpoint like we are enabling the WAL state for cache group and > simultaneously owning all MOVING partitions. But currently, I've seen > that syncFuture finishes when there are no remaining partitions left > [1]. > Is it correct? Seems like a bug. > > 3. In my understanding, a new local node can start only when ALL SYNC > cache groups have been fully rebalanced on ALL nodes, right? But how > about late affinity assignment here? It seems that SYNC caches will be > rebalanced locally on the node, the node will start, but other nodes > still think this node is not operational (late affinity assignment not > occurred yet). > > > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1561 > > On Thu, 13 Feb 2020 at 12:57, Pavel Pereslegin > wrote: > > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > Meant to "rework related functionality" not "remove". > > > > чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin : > > > > > > Hello, > > > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > > should we create a separate ticket for this? > > > > > > Btw, as I understand, SYNC mode is only useful for in-memory caches, > > > because when persistence is enabled (and WAL is disabled during > > > rebalancing), even "ignite-sys-cache" owns partitions only after all > > > cache groups are rebalanced. Thus, even utility cache is still > > > inoperable after node startup when persistence is enabled. Do we > > > really need to wait for SYNC caches when a node starts with enabled > > > persistence or should we enabled WAL for SYNC-caches? > > > > > > чт, 13 февр. 2020 г. в 11:13, Ivan Rakov : > > > > > > > > Hello, > > > > > > > > +1 from me for rebalance delay deprecation. > > > > I can imagine only one actual case for this option: prevent > excessive load > > > > on the cluster in case of temporary short-term topology changes > (e.g. node > > > > is stopped for a while and then returned back). > > > > Now it's handled by baseline auto adjustment in a much more > correct way: > > > > partitions are not reassigned within a maintenance interval > (unlike with > > > > the rebalance delay). > > > > I also don't think that ability to configure rebalance delay per > cache is > > > > crucial. > > > > > > > > > rebalanceOrder is also useless, agreed. > > > > +1 > > > > Except for one case:
Security Subject of thin client on remote nodes
Hi, Igniters! At present, a security subject id is assumed to be node id. But when we are dealing with thin client, JDBC or REST subject id is random UUID. In this case, we cannot get the subject information on a remote node, and we get problems like these [1], [2]. To fix the problem, we should spread the client session to the whole cluster. I want to suggest a solution to the problem. First, we should get subject information using GridSecurityProcessor. How GridSecurityProcessor will retrieve a subject data, it is up to plugin developers. Second, we should get rid of the assumption that a subject id is a node id and remove the ATTR_SECURITY_SUBJECT_V2 attribute. I have prepared PoC PR [3] that: - places the existing logic of spreading security context to GridSecurityProcessor; - uses GridSecurityProcessor to get SecurityContext. 1. http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html 2. https://issues.apache.org/jira/browse/IGNITE-12589 3. https://github.com/apache/ignite/pull/7375
Let's make BinaryObjectImpl and CacheKeyObject Comparable
Hello! Since we have merged https://issues.apache.org/jira/browse/IGNITE-6804 we have to face an embarrassing fact that BinaryObject is not Comparable, i.e., when you do cache.withKeepBinary().putAll(), there are no obvious ways to not get a deadlock (or at least warning) here. One can use LinkedHashMap, but they will have to sort BinaryObject's on their side, which is not trivial. So my proposal is to make BinaryObjectImpl and KeyCacheObject (?) Comparable, by their binary representation. We can't add this constraint to BinaryObject since it is a public interface (can we), but we can do that for the implementation types. What do you think? Regards, -- Ilya Kasnacheev
[jira] [Created] (IGNITE-12708) Calcite integration. Expressions factory base implementation.
Igor Seliverstov created IGNITE-12708: - Summary: Calcite integration. Expressions factory base implementation. Key: IGNITE-12708 URL: https://issues.apache.org/jira/browse/IGNITE-12708 Project: Ignite Issue Type: New Feature Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov We need to implement basic environment for expressions evaluation. Expressions should exist in two types - compiled and interpreted. Expressions should be compiled in dedicated thread pull and eventually replace interpreted ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12707) Update release branch version for 2.8
Maxim Muzafarov created IGNITE-12707: Summary: Update release branch version for 2.8 Key: IGNITE-12707 URL: https://issues.apache.org/jira/browse/IGNITE-12707 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.8 The following need to be done: 1. Update pom.xml version to 2.8.0 2. Update Linux package version to 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite downloads are redirecting from https to http
Thanks, Ilya! > On 19 Feb 2020, at 15:26, Ilya Kasnacheev wrote: > > Hello! > > I have fixed these links, now they point to HTTPS. Please check that it > would work now. > > Regards, > -- > Ilya Kasnacheev > > > ср, 19 февр. 2020 г. в 16:49, Denis Magda : > >> Peter, >> >> Would you mind checking this issue and suggest a proper solution? >> >> Dmitry, >> >> Might this be somehow related to the RPM changes ASF INFRA suggested to >> make? >> >> - >> Denis >> >> >>> On Wed, Feb 19, 2020 at 4:33 AM Stephen Darlington < >>> stephen.darling...@gridgain.com> wrote: >>> >>> As seen in the user mailing list. Looks like there’s a redirect from a >>> https on apache.org to a non-https link. Is there anyone who can fi >> this? >>> >>> Regards, >>> Stephen >>> Begin forwarded message: From: Devin Anderson Subject: Apache Ignite downloads are redirecting from https to http Date: 18 February 2020 at 01:42:14 GMT To: Reply-To: u...@ignite.apache.org Hi all, I'm not sure if this is the correct mailing list to bring up this >>> issue. If I'm writing the wrong mailing list, please let me know and >> I'll >>> gladly send my message to a more appropriate list/person. When I attempt to run `apt-get update` on Ubuntu 18.04 with the Apache >>> Ignite repository in /etc/apt/sources.list, the update fails due to an >>> https to http redirect. Here's the output from stdout: -- Hit:1 http://us.archive.ubuntu.com/ubuntu < >>> http://us.archive.ubuntu.com/ubuntu> bionic InRelease Hit:2 http://security.ubuntu.com/ubuntu < >>> http://security.ubuntu.com/ubuntu> bionic-security InRelease Hit:3 http://us.archive.ubuntu.com/ubuntu < >>> http://us.archive.ubuntu.com/ubuntu> bionic-updates InRelease Ign:4 https://downloads.apache.org/ignite/deb < >>> https://downloads.apache.org/ignite/deb> apache-ignite InRelease Err:5 https://downloads.apache.org/ignite/deb < >>> https://downloads.apache.org/ignite/deb> apache-ignite Release Redirection from https to ' >>> http://dl.bintray.com/apache/ignite-deb/dists/apache-ignite/Release < >>> http://dl.bintray.com/apache/ignite-deb/dists/apache-ignite/Release>' is >>> forbidden [IP: 88.99.95.219 443] Reading package lists... -- ... and stderr: -- E: The repository 'http://apache.org/dist/ignite/deb < >>> http://apache.org/dist/ignite/deb> apache-ignite Release' does not have >> a >>> Release file. -- You can see the redirect for yourself by visiting: https://downloads.apache.org/ignite/deb < >>> https://downloads.apache.org/ignite/deb> ... and noting that your browser is redirected to: http://dl.bintray.com/apache/ignite-deb/ < >>> http://dl.bintray.com/apache/ignite-deb/> I found one or two other places on downloads.apache.org that >> redirected >>> to dl.bintray.com, and those instances appear to redirect to an https >>> URI, so this looks like a problem specific to the way redirects are >>> configured for Apache Ignite assets. Any ideas? Thanks, -- Devin >>> >>> >>> >>
Re: [DISCUSS] Relevance of CacheConfiguration.DefaultLockTimeout
Merged to master. Best regards, Ivan Pavlukhin пн, 17 февр. 2020 г. в 20:08, Ivan Pavlukhin : > > Ticket [1] is ready for review. Comments about deprecation statements > and overall approach are highly appreciated. > > [1] https://issues.apache.org/jira/browse/IGNITE-12686 > > Best regards, > Ivan Pavlukhin > > вс, 16 февр. 2020 г. в 15:02, Ivan Pavlukhin : > > > > Andrey, > > > > Good that we care about compatibility! > > > > A note for a careful reader: nobody told about removal in this thread ;-) > > > > Created a ticket for this and a neighbor thread [1]. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12686 > > > > Best regards, > > Ivan Pavlukhin > > > > пт, 14 февр. 2020 г. в 17:40, Andrey Gura : > > > > > > 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: > > > > > > > > Ivan, > > > > > > > > Nothing from my side as well - looks like the property is not used.
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Hooray-hooray! ))) Thank you, Ivan! BR, S. ср, 19 февр. 2020 г. в 08:38, Ivan Pavlukhin : > Hooray! > > Best regards, > Ivan Pavlukhin > > ср, 19 февр. 2020 г. в 00:28, Dmitriy Govorukhin < > dmitriy.govoruk...@gmail.com>: > > > > My congratulations, Slava! > > > > On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov > wrote: > > > > > Congratulations, Slava! > > > > > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > > > > > Hello Ignite Community, > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Vyacheslav Koptilin to become a committer and we are pleased to > announce > > > > that he has accepted. > > > > > > > > Vyacheslav investigated and fixed a number of non-trivial issues in > the > > > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > > > Consistency Check). > > > > > > > > Being a committer enables easier contribution to the project since > there > > > is > > > > no need to go via the patch submission process. This should enable > better > > > > productivity. > > > > > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > > > > > > > > > > -- > > > Best regards, > > > Andrey Kuznetsov. > > > >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Hi Pavel, > Don't let the bad code occupy master :) I will do my best! :) Thanks, S. ср, 19 февр. 2020 г. в 12:58, Pavel Kovalenko : > Congratulations, Slava! > Don't let the bad code occupy master :) > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Vyacheslav Koptilin to become a committer and we are pleased to announce > > that he has accepted. > > > > Vyacheslav investigated and fixed a number of non-trivial issues in the > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > Consistency Check). > > > > Being a committer enables easier contribution to the project since there > is > > no need to go via the patch submission process. This should enable better > > productivity. > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC > > >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Thank you, Andrey! Glad to hear from you! :) Thanks, S. вт, 18 февр. 2020 г. в 23:33, Andrey Kuznetsov : > Congratulations, Slava! > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Vyacheslav Koptilin to become a committer and we are pleased to announce > > that he has accepted. > > > > Vyacheslav investigated and fixed a number of non-trivial issues in the > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > Consistency Check). > > > > Being a committer enables easier contribution to the project since there > is > > no need to go via the patch submission process. This should enable better > > productivity. > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC > > > > > -- > Best regards, > Andrey Kuznetsov. >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Hello folks, Thanks a lot all of you! I really appreciate it. Best regards, Slava. ср, 19 февр. 2020 г. в 21:32, Saikat Maitra : > Congratulations!!! > > Regards > Saikat > > On Wed, 19 Feb 2020 at 6:28 AM, Alexei Scherbakov < > alexey.scherbak...@gmail.com> wrote: > > > Congrats, keep up a good work! > > > > ср, 19 февр. 2020 г. в 13:20, Pavel Kovalenko : > > > > > Congratulations Slava! > > > > > > On Tue 18. Feb 2020 at 22.20, Dmitriy Pavlov > wrote: > > > > > > > Hello Ignite Community, > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Vyacheslav Koptilin to become a committer and we are pleased to > > announce > > > > that he has accepted. > > > > > > > > Vyacheslav investigated and fixed a number of non-trivial issues in > the > > > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > > > Consistency Check). > > > > > > > > Being a committer enables easier contribution to the project since > > there > > > is > > > > no need to go via the patch submission process. This should enable > > better > > > > productivity. > > > > > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > > > > > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > >
Re: Ignite 2.8 documentation
Yes, there are a lot of changes in ML from 2.7, I'm going to prepare new documentation and create documentation related tickets for the ML component. After some consultation and review from Artem side I'll add new documentation on readme.io. чт, 20 февр. 2020 г. в 02:34, Denis Magda : > Artem, > > Thanks for stepping in and preparing the list of top priority > documentation tasks! How about labeling those tickets somehow and creating > a filter similar to this one [1] but for "Required & Unresolved > Documentation Tasks"? I would simply add this as a new section to the > Ignite 2.8 release wiki page for ease of tracking and start working with > the guys contributed improvements directly. Will see the names of the > authors who need to be involved ;) > > *Alexey Zinoviev*, there are many ML related changes coming in the > release. Could you check existing ML docs and suggest any changes? > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolveddocumentationtasks > > - > Denis > > > On Wed, Feb 19, 2020 at 11:14 AM Artem Budnikov < > a.budnikov.ign...@gmail.com> wrote: > >> Maxim, >> >> One note from my side, I think we can move disk page compression [1] >> > to the 2-nd priority, but definitely must document WAL page >> > compression first [2] >> >> >> OK, good to know. >> >> On Wed, Feb 19, 2020 at 6:48 PM Maxim Muzafarov >> wrote: >> >> > Artem, >> > >> > >> > Thank you for starting this thread. >> > One note from my side, I think we can move disk page compression [1] >> > to the 2-nd priority, but definitely must document WAL page >> > compression first [2] >> > >> > >> > The list of important tasks [3]. >> > The list of documentation tasks [4]. >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-10330 >> > [2] https://issues.apache.org/jira/browse/IGNITE-11336 >> > [3] >> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Themostimportantreleasetasks >> > [4] >> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolveddocumentationtasks >> > >> > On Wed, 19 Feb 2020 at 18:15, Artem Budnikov >> > wrote: >> > > >> > > Hi everyone, >> > > >> > > As the release of Ignite 2.8 is getting closer, let's discuss which >> > features should be documented. I created a list of features based on the >> > release notes and the documentation tickets in jira (see below). Much >> more >> > has been added, but these seemed to have first priority. It's not to say >> > that other features are not important, but given the limited resources a >> > list of high-priority task would help to schedule the time of those who >> > will help with the docs. >> > > >> > > Here is the list of features: >> > > >> > > Disk page compression >> > > Metrics and System Views documentation >> > > Default Ignite work dir location >> > > Baseline auto-adjust feature >> > > Cluster (de)activation events documentation >> > > Remove SqlQuery documentation >> > > Partition awareness for thin clients >> > > Transactions support in thin clients >> > > KILL QUERY command >> > > Move rebalance configuration properties to the IgniteConfiguration >> level >> > > Renamed IGNITE schema to SYS >> > > JDBC: Support for query cancellation >> > > JDBC: Support for query timeout >> > > suspend/resume for pessimistic transactions >> > > >> > > Now, two really big questions here: >> > > >> > > If you want to add anything else to the documentation, please let us >> > know in this thread. >> > > If you are the author of any of the features listed above, please >> share >> > the details on the feature. You can do it by creating a documentation >> > ticket. If you want to contribute a page or section to the existing >> docs, >> > you can write directly on apacheignite.readme.io (send me a note if you >> > don't have an account there). Any help is greatly appreciated. >> > > >> > > -Artem >> > > >> > > >> > >> >
