Re: [ANNOUNCE] Welcome Vladislav Pyatkov as a new committer
Congratulations, Vlad! You deserve it! чт, 23 дек. 2021 г. в 14:58, Roman Kondakov : > Congratulations, Vlad! > > -- > Roman Kondakov > > > On 23.12.2021 20:13, Kseniya Romanova wrote: > > Congrats and welcome, Vlad! > > > > чт, 23 дек. 2021 г. в 12:36, Вячеслав Коптилин >: > > > >> Hi, > >> > >> Congratulations, Vlad! > >> > >> Thanks, > >> S. > >> > >> чт, 23 дек. 2021 г. в 11:59, Anton Vinogradov : > >> > >>> Welcome aboard! > >>> > >>> On Thu, Dec 23, 2021 at 10:24 AM Ivan Pavlukhin > >>> wrote: > >>> > >>>> Congrats, Vlad! > >>>> > >>>> 2021-12-22 20:48 GMT+03:00, Ivan Daschinsky : > >>>>> Vlad, congrats! You have definitely deserved it! > >>>>> > >>>>> ср, 22 дек. 2021 г. в 20:40, Andrey Mashenkov < > >>>> andrey.mashen...@gmail.com>: > >>>>>> Congrats, Vlad! > >>>>>> > >>>>>> ср, 22 дек. 2021 г., 20:23 Valentin Kulichenko < > >>>>>> valentin.kuliche...@gmail.com>: > >>>>>> > >>>>>>> The Apache Ignite Project Management Committee (PMC) has invited > >>>>>> Vladislav > >>>>>>> Pyatkov to become a new committer and are happy to announce that > >> he > >>>> has > >>>>>>> accepted. > >>>>>>> > >>>>>>> Vladislav is a veteran of the Apache Ignite project. He joined the > >>>>>>> community in 2016. > >>>>>>> He participated in the development of Ignite 1.x, 2.x and he is > >>>>>>> actively > >>>>>>> working on a new Apache Ignite 3.0 release. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> Please join me in welcoming Vlad, and congratulating him on the > >> new > >>>>>>> role > >>>>>>> in the Apache Ignite Community. > >>>>>>> > >>>>>>> -Val > >>>>>>> > >>>>> > >>>>> -- > >>>>> Sincerely yours, Ivan Daschinskiy > >>>>> > >>>> > >>>> -- > >>>> > >>>> Best regards, > >>>> Ivan Pavlukhin > >>>> > -- BR, Sergey Antonov
Re: New Committer: Sergey Chugunov
Congratulations, Sergey! сб, 18 июл. 2020 г., 0:24 Andrey Mashenkov : > Congratulations, Sergey. > > пт, 17 июл. 2020 г., 15:06 Вячеслав Коптилин : > > > Hi, > > > > Well deserved! Keep it up, Sergey! > > > > Thanks, > > S. > > > > пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin : > > > > > Sergey, congratulations! > > > > > > 2020-07-17 14:25 GMT+03:00, Petr Ivanov : > > > > Congratulations! > > > > > > > > > > > >> On 17 Jul 2020, at 14:14, Roman Kondakov > > > > >> wrote: > > > >> > > > >> Sergey, congratulations! > > > >> > > > >> -- > > > >> Roman Kondakov > > > >> > > > >> On 17.07.2020 12:32, Dmitriy Pavlov wrote: > > > >>> Dear Ignite Community, > > > >>> The Project Management Committee (PMC) for Apache Ignite has > invited > > > >>> Sergey > > > >>> Chugunov to become a committer and we are pleased to announce that > he > > > >>> has > > > >>> accepted. > > > >>> Sergey has a long story of Ignite contributions. Besides the code > > > >>> contributions, Sergey has contributed the TCP Discovery Under The > > Hood > > > >>> wiki > > > >>> page, posted a blog post about running Apache Ignite on AWS, and > also > > > >>> mentors newcomer contributors. > > > >>> 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. > > > >>> Sergey, congratulations on a new role in the Apache Ignite > Community. > > > >>> Best Regards, > > > >>> Dmitriy Pavlov > > > >>> on behalf of Apache Ignite PMC > > > >>> P.S. this announce is a little bit overdue, but I guess Sergey's > new > > > >>> role > > > >>> was not announced to the community. > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Ivan Pavlukhin > > > > > >
Re: Can't build project/run java tests in Intellij IDEA.
Hi! Please uncheck java-9+ profile in the maven profiles in idea. It could help you. вс, 21 июн. 2020 г., 22:05 Guru Stron : > Dear Igniters, > > I filled instructions from > https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup - checked > out project, opened it in Intellij IDEA and trying to build/run tests and > getting "Error:java: invalid flag: --add-exports". JIC my environment is > Win 10 + Java 1.8. > > Thank you. >
[TeamCity Bot] Dependency problem: [424]: Service https://ci.ignite.apache.org/app/rest/buildQueue returned forbidden error.
Hello, Igniters! I can't rerun possible blockers from the visa page [2]. I get a message " Dependency problem: [424]: Service https://ci.ignite.apache.org/app/rest/buildQueue returned forbidden error." when I try to rerun blockers. Can you help me with this problem? I can't use TC Bot for getting a visa. [1] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/7924/head=Latest [2] https://ibb.co/m8rW74L -- BR, Sergey Antonov
Re: Reviewer request: [IGNITE-13144] Improve ClusterState enum and other minor improvements for the cluster read-only mode.
Guys, could someone review my patch, please? вт, 16 июн. 2020 г. в 10:50, Sergey Antonov : > Hello, Igniters! > > I'd like to get a review of the ticket [1]. The patch is ready [2]. > Can someone look at it, please? > > [1] https://issues.apache.org/jira/browse/IGNITE-13144 > [2] https://github.com/apache/ignite/pull/7924 > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Reviewer request: [IGNITE-13144] Improve ClusterState enum and other minor improvements for the cluster read-only mode.
Hello, Igniters! I'd like to get a review of the ticket [1]. The patch is ready [2]. Can someone look at it, please? [1] https://issues.apache.org/jira/browse/IGNITE-13144 [2] https://github.com/apache/ignite/pull/7924 -- BR, Sergey Antonov
Reviewer request: [IGNITE-13138] Add REST tests for the new cluster state change API
Hello, Igniters! I'd like to get a review of the ticket [1]. The patch is ready [2]. Can someone look at it, please? [1] https://issues.apache.org/jira/browse/IGNITE-13138 [2] https://github.com/apache/ignite/pull/7918/files -- BR, Sergey Antonov
Re: [DISCUSS] Add flag methods to ClusterState enum
Igniters, the patch [1] is ready for the review. Can someone look at it, please? [1] https://github.com/apache/ignite/pull/7924 ср, 10 июн. 2020 г. в 23:42, Sergey Antonov : > Pavel, Alexei thank you for your replays. > > > is this one special in some way? > Yes. We have two "active" cluster states: ACTIVE, ACTIVE_READ_ONLY. > Probably, I chose the wrong method's name, but I mean that in "active" > state the caches must be started. > > > But it looks like we do not need methods *readOnly *and *inactive*. > I agree. > > ср, 10 июн. 2020 г. в 21:17, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> But it looks like we do not need methods *readOnly *and *inactive*. >> What is the point in adding them ? >> >> >> ср, 10 июн. 2020 г. в 21:05, Alexei Scherbakov < >> alexey.scherbak...@gmail.com >> >: >> >> > Sergey Antonov, >> > >> > The proposal looks good to me. >> > Use of org.apache.ignite.cluster.ClusterState#active adds a >> > boilerplate code (a lot of static imports) and does an unnecessary state >> > check. >> > >> > >> > >> > >> > ср, 10 июн. 2020 г. в 19:02, Pavel Tupitsyn : >> > >> >> Sergey, >> >> >> >> I disagree - looks weird. >> >> We have lots of enums, is this one special in some way? >> >> >> >> Thanks, >> >> Pavel >> >> >> >> On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov < >> antonovserge...@gmail.com >> >> > >> >> wrote: >> >> >> >> > Igniters, I'd like to propose a small improvement in ClusterState >> >> class. I >> >> > want to remove the static method boolean ClusterState#active and add >> >> > methods to the enum: >> >> > >> >> >- boolean active() >> >> >- boolean readOnly() >> >> >- boolean inactive() >> >> > >> >> > From my point of view these methods more useful than comparing with >> >> > specific enum's value. >> >> > >> >> > I'm going to do that on the ticket [1]. >> >> > >> >> > Any objections? >> >> > >> >> > [1] https://issues.apache.org/jira/browse/IGNITE-13144 >> >> > -- >> >> > BR, Sergey Antonov >> >> > >> >> >> > >> > >> > -- >> > >> > Best regards, >> > Alexei Scherbakov >> > >> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: [DISCUSS] Add flag methods to ClusterState enum
Pavel, Alexei thank you for your replays. > is this one special in some way? Yes. We have two "active" cluster states: ACTIVE, ACTIVE_READ_ONLY. Probably, I chose the wrong method's name, but I mean that in "active" state the caches must be started. > But it looks like we do not need methods *readOnly *and *inactive*. I agree. ср, 10 июн. 2020 г. в 21:17, Alexei Scherbakov : > But it looks like we do not need methods *readOnly *and *inactive*. > What is the point in adding them ? > > > ср, 10 июн. 2020 г. в 21:05, Alexei Scherbakov < > alexey.scherbak...@gmail.com > >: > > > Sergey Antonov, > > > > The proposal looks good to me. > > Use of org.apache.ignite.cluster.ClusterState#active adds a > > boilerplate code (a lot of static imports) and does an unnecessary state > > check. > > > > > > > > > > ср, 10 июн. 2020 г. в 19:02, Pavel Tupitsyn : > > > >> Sergey, > >> > >> I disagree - looks weird. > >> We have lots of enums, is this one special in some way? > >> > >> Thanks, > >> Pavel > >> > >> On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov < > antonovserge...@gmail.com > >> > > >> wrote: > >> > >> > Igniters, I'd like to propose a small improvement in ClusterState > >> class. I > >> > want to remove the static method boolean ClusterState#active and add > >> > methods to the enum: > >> > > >> >- boolean active() > >> >- boolean readOnly() > >> >- boolean inactive() > >> > > >> > From my point of view these methods more useful than comparing with > >> > specific enum's value. > >> > > >> > I'm going to do that on the ticket [1]. > >> > > >> > Any objections? > >> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-13144 > >> > -- > >> > BR, Sergey Antonov > >> > > >> > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > > > > -- > > Best regards, > Alexei Scherbakov > -- BR, Sergey Antonov
[DISCUSS] Add flag methods to ClusterState enum
Igniters, I'd like to propose a small improvement in ClusterState class. I want to remove the static method boolean ClusterState#active and add methods to the enum: - boolean active() - boolean readOnly() - boolean inactive() >From my point of view these methods more useful than comparing with specific enum's value. I'm going to do that on the ticket [1]. Any objections? [1] https://issues.apache.org/jira/browse/IGNITE-13144 -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13144) Add attribute methods to ClusterState enum
Sergey Antonov created IGNITE-13144:
---
Summary: Add attribute methods to ClusterState enum
Key: IGNITE-13144
URL: https://issues.apache.org/jira/browse/IGNITE-13144
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.9
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}. Also I'd like to add
methods {{boolean inactive()}} and {{boolean readOnly()}} to {{ClusterState}}
class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13138) Add REST tests for the new cluster state change API
Sergey Antonov created IGNITE-13138: --- Summary: Add REST tests for the new cluster state change API Key: IGNITE-13138 URL: https://issues.apache.org/jira/browse/IGNITE-13138 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 I didn't find tests for a new REST commands introduced in an IGNITE-12225. We must fix them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Extra test coverage for ACTIVE_READ_ONLY cluster state
Igniters, I faced several problems during write tests for the read-only mode: 1. You can create/destroy cache on the read-only cluster. Fixed in [1]. 2. The read-only mode doesn't affect LOCAL caches. Ticket created [2]. 3. IgniteCache#isClosed() doesn't work on server nodes. Ticket created [3]. Also, I wrote tests for: 1. IgniteCache API (including create(), destroy(), invoke()) 2. Near caches. 3. 3rd party CacheStore. 4. Services (deploy, execution, cancel) 5. Datastructures (IgniteAtomicLong, IgniteAtomicReference, IgniteAtomicSequence, IgniteAtomicStamped, IgniteCountDownLatch, IgniteQueue, IgniteSet) 6. Updates to meta storage. The patch [4] ready for review. [1] https://issues.apache.org/jira/browse/IGNITE-13071 [2] https://issues.apache.org/jira/browse/IGNITE-13076 [3] https://issues.apache.org/jira/browse/IGNITE-13102 [4] https://github.com/apache/ignite/pull/7853/files вт, 26 мая 2020 г. в 20:28, Sergey Antonov : > Maxim, I've created a ticket [1] for this change. > > [1] https://issues.apache.org/jira/browse/IGNITE-13079 > > вт, 26 мая 2020 г. в 20:09, Sergey Antonov : > >> Maxim, I'd prefer to do this with a separate ticket. >> >> вт, 26 мая 2020 г. в 19:59, Maxim Muzafarov : >> >>> Sergey, >>> >>> Sounds good! >>> Should we consider removing the deprecated methods `active()`, >>> `active(boolean active)` from tests also? >>> >>> On Tue, 26 May 2020 at 12:18, Sergey Antonov >>> wrote: >>> > >>> > Hello, Igniters. >>> > >>> > I introduced cluster read-only mode [1] and a new API for cluster state >>> > change [2]. At the moment we don't have good test coverage for this >>> > feature. I'm going to fix it and write tests and check that operations >>> > are *denied >>> > *in read-only mode: >>> > >>> >- data structures usage >>> >- cache create/clear/destroy >>> >- DDL requests >>> >- cache updates by task's execution / deployed service >>> > >>> > And the following operations are *allowed *in read-only mode: >>> > >>> >- update of metastorage / distributed metastorage >>> >- updates to ignite-sys-cache >>> >- task's execution, but updates must be rejected >>> >- service deploy/undeploy, but updates must be rejected >>> >- data recovery on node join >>> > >>> > I'll work under these tests in ticket [3]. >>> > Any objections? >>> > >>> > [1] https://issues.apache.org/jira/browse/IGNITE-11256 >>> > [2] https://issues.apache.org/jira/browse/IGNITE-12225 >>> > [3] https://issues.apache.org/jira/browse/IGNITE-13071 >>> > -- >>> > BR, Sergey Antonov >>> >> >> >> -- >> BR, Sergey Antonov >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]
Cluster read-only mode and new cluster state change API. ср, 3 июн. 2020 г. в 16:10, Ilya Kasnacheev : > Hello! > > Can you please clarify what is the scope of 2.9 release? > > I have a feeling that we don't really have any big features in the current > 2.9 code base. No Calcite, etc. > > So I'm asking whether it is worth it. > > Regards, > -- > Ilya Kasnacheev > > > ср, 3 июн. 2020 г. в 14:45, Alex Plehanov : > > > Hello Igniters, > > > > AI 2.8.1 is finally released and as we discussed here [1] its time to > start > > the discussion about 2.9 release. > > > > I want to propose myself to be the release manager of the 2.9 release. > > > > What about release time, I agree with Maxim that we should deliver > features > > as frequently as possible. If some feature doesn't fit into release dates > > we should better include it into the next release and schedule the next > > release earlier then postpone the current release. > > > > I propose the following dates for 2.9 release: > > > > Scope Freeze: June 26, 2020 > > Code Freeze: July 10, 2020 > > Voting Date: July 31, 2020 > > Release Date: August 7, 2019 > > > > WDYT? > > > > [1] : > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575 > > > -- BR, Sergey Antonov
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Andrey, > And why we should try System.exit()? Why we try to stop the node before invoke Runtime#halt()?) By the same reasons we should try to stop the process with shutdown hooks invocation before Runtime#halt(). вт, 2 июн. 2020 г. в 17:51, Andrey Gura : > > Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method > > doesn't cause shutdown hooks. Why we don't try to stop the node by > > System#exit() before Runtime#halt()? > > And why we should try System.exit()? > > We invoke halt() because we don't want to invoke any code in shutdown > hook. We don't know what shut down will try to do and we can't sure > that node will actually terminated. halt() gives such guarantee. > > On Tue, Jun 2, 2020 at 5:35 PM Sergey Antonov > wrote: > > > > Andrey, Alexey, I can't agree with your position. > > > > Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method > > doesn't cause shutdown hooks. Why we don't try to stop the node by > > System#exit() before Runtime#halt()? > > > > > > вт, 2 июн. 2020 г. в 17:18, Andrey Gura : > > > > > Sergey, Anton, Kirill, > > > > > > I think we have to do not change anything in FH. At least without > > > enough motivation. > > > > > > Now I see only assumption that it "could be helpful for administration > > > purposes". It isn't enough, I believe. > > > > > > On Tue, Jun 2, 2020 at 4:59 PM ткаленко кирилл > > > wrote: > > > > > > > > Hello, Alexey! > > > > > > > > I didn't quite understand about merge. > > > > > > > > If we use StopNodeOrHaltFailureHandler with tryStop=true, then if we > > > don't stop node by timeout, we will terminate jvm. > > > > > > > > Or do you suggest only stopping the node in StopNodeFailureHandler > and > > > terminate jvm in StopNodeOrHaltFailureHandler? or leave it as it is? > > > > > > > > 02.06.2020, 16:46, "Alexey Goncharuk" : > > > > >> > How exactly do you want to change the StopNodeFH? > > > > >> I want to stop JVM with KILL_EXIT_CODE and add an option > (constructor > > > > >> argument of JVM option) for disabling JVM termination. > > > > > > > > > > When the flag is enabled, the behavior is identical to > StopNodeOrHaltFH > > > > > with tryStop=false. In other words, > > > > > StopNodeFH with enabled JVM termination === StopNodeOrHaltFH with > > > > > tryStop=false > > > > > StopNodeFG with disabled JVM termination ~ StopNodeOrHaltFH with > > > > > tryStop=true > > > > > > > > > > Why have two different failure handlers with identical behavior? > > > Perhaps, > > > > > there is confusion and we should consider merging these classes > into > > > one? > > > > > > > > > -- > > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Andrey, Alexey, I can't agree with your position. Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method doesn't cause shutdown hooks. Why we don't try to stop the node by System#exit() before Runtime#halt()? вт, 2 июн. 2020 г. в 17:18, Andrey Gura : > Sergey, Anton, Kirill, > > I think we have to do not change anything in FH. At least without > enough motivation. > > Now I see only assumption that it "could be helpful for administration > purposes". It isn't enough, I believe. > > On Tue, Jun 2, 2020 at 4:59 PM ткаленко кирилл > wrote: > > > > Hello, Alexey! > > > > I didn't quite understand about merge. > > > > If we use StopNodeOrHaltFailureHandler with tryStop=true, then if we > don't stop node by timeout, we will terminate jvm. > > > > Or do you suggest only stopping the node in StopNodeFailureHandler and > terminate jvm in StopNodeOrHaltFailureHandler? or leave it as it is? > > > > 02.06.2020, 16:46, "Alexey Goncharuk" : > > >> > How exactly do you want to change the StopNodeFH? > > >> I want to stop JVM with KILL_EXIT_CODE and add an option (constructor > > >> argument of JVM option) for disabling JVM termination. > > > > > > When the flag is enabled, the behavior is identical to StopNodeOrHaltFH > > > with tryStop=false. In other words, > > > StopNodeFH with enabled JVM termination === StopNodeOrHaltFH with > > > tryStop=false > > > StopNodeFG with disabled JVM termination ~ StopNodeOrHaltFH with > > > tryStop=true > > > > > > Why have two different failure handlers with identical behavior? > Perhaps, > > > there is confusion and we should consider merging these classes into > one? > -- BR, Sergey Antonov
Re: [DISCUSSION] Add autocompletion for commands in control.sh
It would be a great usability improvement! +1 From me. вт, 2 июн. 2020 г. в 15:54, Zhenya Stanilovsky : > > > good catch ! it`s a little bit pain for now to working with it. > > > >Hi, Igniters! > > > >At the moment to work with the control.sh we need to know exactly what > the name of the command and its options are and so the user can often make > mistakes when using it. So I think it would be useful to do control.sh more > user-friendly by adding autocomplete as in modern command-line utilities. > > > >For this purpose, I suggest using framework [1] and to do this, take out > control.sh together with its associated classes in a separate module such > as "modules/control-utility". > > > >Comments, suggestions? > > > >[1] - https://picocli.info/ > > > > -- BR, Sergey Antonov
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Alexey, > How exactly do you want to change the StopNodeFH? I want to stop JVM with KILL_EXIT_CODE and add an option (constructor argument of JVM option) for disabling JVM termination. вт, 2 июн. 2020 г. в 12:54, Alexey Goncharuk : > Sergey, > > How exactly do you want to change the StopNodeFH? The current behavior does > not terminate the JVM and its exit code is totally out of our control; one > of the use-cases we had in mind for this failure handler is that a user may > have other processes running in the same JVM, so we do not want Ignite to > affect them. > > For me, the exit code makes sense only for StopNodeOrHaltFH with > tryStop=false (otherwise, the JVM exit is not guaranteed as well), but we > already use the KILL_EXIT_CODE there. > > пн, 1 июн. 2020 г. в 23:19, Sergey Antonov : > > > Hello, Kirill! > > > > I'd prefer to don't create a new implementation of a failure handler. We > > already have 4 different failure handlers. We will have 6 FH (StopNodeFH > > with exit code, StopNodeOrHaltFH with exit code), if we go your way. It > > won't make our product simpler and easier. > > > > I think, we must notify a user if the cluster node had been stopped by a > > failure handler. We can't achieve this goal without changing current FH > > behavior. So I propose to change it and stop the process with > > KILL_EXIT_CODE. > > But it would be nice if users will have a flag for avoiding process stop > > after a node failure. We can introduce a new JVM option or FH parameter > for > > that reason. Of course, we must highlight this change in the release > notes. > > > > пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл : > > > > > I think that [1] and [2] should not be changed, because we can kill > > > another client code in this jvm. > > > I suggest for these purposes to create a new [3] which will be like [1] > > > but with a call [4] after node stop. > > > Objections or comments? > > > > > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > > > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > > > [3] - org.apache.ignite.failure.FailureHandler > > > [4] - java.lang.System#exit > > > > > > 25.05.2020, 22:09, "Dmitriy Pavlov" : > > > > It seems reasonable to me. Also I would like to propose adding value > of > > > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > > > without > > > > going to Java code. > > > > > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > > > : > > > > > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > > > >> > > > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > > > >> antonovserge...@gmail.com>: > > > >> > > > > >> >I've created the Ignite ticket for this improvement [1]. > > > >> > > > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > > > >> > > > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > > > antonovserge...@gmail.com >: > > > >> > > > > >> >> Hello, Igniters! > > > >> >> > > > >> >> I'd like to discuss behaviour of Ignite process exit code if the > > > node > > > >> was > > > >> >> stopped by failure handler [1][2]. At the moment ignite process > > > returns > > > >> >> exit code 0 after the stop in all scenarios, except runtime halt > > by > > > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 > [3] > > > >> >> > > > >> >> My proposal: always finish Ignite process with code [3], if a > node > > > was > > > >> >> stopped by FH. It could be helpful for administration purposes, > > you > > > can > > > >> >> distinguish normal node stop from node stop by FH on OS level. > > > >> >> > > > >> >> WDYT? > > > >> >> > > > >> >> [1] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > > >> >> > > > >> >> [2] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > > >> >> > > > >> >> [3] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > > > >> >> -- > > > >> >> BR, Sergey Antonov > > > >> >> > > > >> > > > > >> >-- > > > >> >BR, Sergey Antonov > > > >> > > > > > > > > > > -- > > BR, Sergey Antonov > > > -- BR, Sergey Antonov
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
Hello, Kirill! I'd prefer to don't create a new implementation of a failure handler. We already have 4 different failure handlers. We will have 6 FH (StopNodeFH with exit code, StopNodeOrHaltFH with exit code), if we go your way. It won't make our product simpler and easier. I think, we must notify a user if the cluster node had been stopped by a failure handler. We can't achieve this goal without changing current FH behavior. So I propose to change it and stop the process with KILL_EXIT_CODE. But it would be nice if users will have a flag for avoiding process stop after a node failure. We can introduce a new JVM option or FH parameter for that reason. Of course, we must highlight this change in the release notes. пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл : > I think that [1] and [2] should not be changed, because we can kill > another client code in this jvm. > I suggest for these purposes to create a new [3] which will be like [1] > but with a call [4] after node stop. > Objections or comments? > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > [3] - org.apache.ignite.failure.FailureHandler > [4] - java.lang.System#exit > > 25.05.2020, 22:09, "Dmitriy Pavlov" : > > It seems reasonable to me. Also I would like to propose adding value of > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > without > > going to Java code. > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > : > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > >> > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > >> antonovserge...@gmail.com>: > >> > > >> >I've created the Ignite ticket for this improvement [1]. > >> > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >> > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > antonovserge...@gmail.com >: > >> > > >> >> Hello, Igniters! > >> >> > >> >> I'd like to discuss behaviour of Ignite process exit code if the > node > >> was > >> >> stopped by failure handler [1][2]. At the moment ignite process > returns > >> >> exit code 0 after the stop in all scenarios, except runtime halt by > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > >> >> > >> >> My proposal: always finish Ignite process with code [3], if a node > was > >> >> stopped by FH. It could be helpful for administration purposes, you > can > >> >> distinguish normal node stop from node stop by FH on OS level. > >> >> > >> >> WDYT? > >> >> > >> >> [1] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > >> >> > >> >> [2] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > >> >> > >> >> [3] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > >> >> -- > >> >> BR, Sergey Antonov > >> >> > >> > > >> >-- > >> >BR, Sergey Antonov > >> > > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had closed before.
Sergey Antonov created IGNITE-13102:
---
Summary: IgniteCache#isClosed() returns false on server node even
if the cache had closed before.
Key: IGNITE-13102
URL: https://issues.apache.org/jira/browse/IGNITE-13102
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1, 2.8
Reporter: Sergey Antonov
Fix For: 2.9
IgniteCache#isClosed() still returns {{false}} even after
{{IgniteCache#close()}}. Only server nodes affect by this problem.
Simple reproducer:
{code:java}
@Test
public void test() throws Exception {
IgniteEx node = startGrid(0);
IgniteCache cache =
node.getOrCreateCache(DEFAULT_CACHE_NAME);
assertFalse(cache.isClosed());
cache.close();
// java.lang.AssertionError
assertTrue(cache.isClosed());
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13091) Cluster read-only mode allows to create caches
Sergey Antonov created IGNITE-13091:
---
Summary: Cluster read-only mode allows to create caches
Key: IGNITE-13091
URL: https://issues.apache.org/jira/browse/IGNITE-13091
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Sergey Antonov
Fix For: 2.9
You can create a cache if cluster in a read-only mode.
See {{CacheCreateDestroyClusterReadOnlyModeTest#testCacheCreateDenied}} test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Extra test coverage for ACTIVE_READ_ONLY cluster state
Maxim, I've created a ticket [1] for this change. [1] https://issues.apache.org/jira/browse/IGNITE-13079 вт, 26 мая 2020 г. в 20:09, Sergey Antonov : > Maxim, I'd prefer to do this with a separate ticket. > > вт, 26 мая 2020 г. в 19:59, Maxim Muzafarov : > >> Sergey, >> >> Sounds good! >> Should we consider removing the deprecated methods `active()`, >> `active(boolean active)` from tests also? >> >> On Tue, 26 May 2020 at 12:18, Sergey Antonov >> wrote: >> > >> > Hello, Igniters. >> > >> > I introduced cluster read-only mode [1] and a new API for cluster state >> > change [2]. At the moment we don't have good test coverage for this >> > feature. I'm going to fix it and write tests and check that operations >> > are *denied >> > *in read-only mode: >> > >> >- data structures usage >> >- cache create/clear/destroy >> >- DDL requests >> >- cache updates by task's execution / deployed service >> > >> > And the following operations are *allowed *in read-only mode: >> > >> >- update of metastorage / distributed metastorage >> >- updates to ignite-sys-cache >> >- task's execution, but updates must be rejected >> >- service deploy/undeploy, but updates must be rejected >> >- data recovery on node join >> > >> > I'll work under these tests in ticket [3]. >> > Any objections? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-11256 >> > [2] https://issues.apache.org/jira/browse/IGNITE-12225 >> > [3] https://issues.apache.org/jira/browse/IGNITE-13071 >> > -- >> > BR, Sergey Antonov >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13079) Replace deprecated cluster activation methods in tests.
Sergey Antonov created IGNITE-13079:
---
Summary: Replace deprecated cluster activation methods in tests.
Key: IGNITE-13079
URL: https://issues.apache.org/jira/browse/IGNITE-13079
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
After we IGNITE-12225 we have a new API for a changing cluster state. We must
replace deprecated methods ({{IgniteCluster#active()}},
{{IgniteCluster#active(boolean)}} and etc) to a new API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Extra test coverage for ACTIVE_READ_ONLY cluster state
Maxim, I'd prefer to do this with a separate ticket. вт, 26 мая 2020 г. в 19:59, Maxim Muzafarov : > Sergey, > > Sounds good! > Should we consider removing the deprecated methods `active()`, > `active(boolean active)` from tests also? > > On Tue, 26 May 2020 at 12:18, Sergey Antonov > wrote: > > > > Hello, Igniters. > > > > I introduced cluster read-only mode [1] and a new API for cluster state > > change [2]. At the moment we don't have good test coverage for this > > feature. I'm going to fix it and write tests and check that operations > > are *denied > > *in read-only mode: > > > >- data structures usage > >- cache create/clear/destroy > >- DDL requests > >- cache updates by task's execution / deployed service > > > > And the following operations are *allowed *in read-only mode: > > > >- update of metastorage / distributed metastorage > >- updates to ignite-sys-cache > >- task's execution, but updates must be rejected > >- service deploy/undeploy, but updates must be rejected > >- data recovery on node join > > > > I'll work under these tests in ticket [3]. > > Any objections? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > [2] https://issues.apache.org/jira/browse/IGNITE-12225 > > [3] https://issues.apache.org/jira/browse/IGNITE-13071 > > -- > > BR, Sergey Antonov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
Sergey Antonov created IGNITE-13076:
---
Summary: Cluster read-only mode doesn't affect LOCAL caches
Key: IGNITE-13076
URL: https://issues.apache.org/jira/browse/IGNITE-13076
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Sergey Antonov
Fix For: 2.9
You can make data modification operations with LOCAL cache even if cluster in a
{{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[DISCUSS] Extra test coverage for ACTIVE_READ_ONLY cluster state
Hello, Igniters. I introduced cluster read-only mode [1] and a new API for cluster state change [2]. At the moment we don't have good test coverage for this feature. I'm going to fix it and write tests and check that operations are *denied *in read-only mode: - data structures usage - cache create/clear/destroy - DDL requests - cache updates by task's execution / deployed service And the following operations are *allowed *in read-only mode: - update of metastorage / distributed metastorage - updates to ignite-sys-cache - task's execution, but updates must be rejected - service deploy/undeploy, but updates must be rejected - data recovery on node join I'll work under these tests in ticket [3]. Any objections? [1] https://issues.apache.org/jira/browse/IGNITE-11256 [2] https://issues.apache.org/jira/browse/IGNITE-12225 [3] https://issues.apache.org/jira/browse/IGNITE-13071 -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13071) Improve test coverage for read-only cluster state
Sergey Antonov created IGNITE-13071: --- Summary: Improve test coverage for read-only cluster state Key: IGNITE-13071 URL: https://issues.apache.org/jira/browse/IGNITE-13071 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
I've created the Ignite ticket for this improvement [1]. [1] https://issues.apache.org/jira/browse/IGNITE-13047 чт, 21 мая 2020 г. в 00:46, Sergey Antonov : > Hello, Igniters! > > I'd like to discuss behaviour of Ignite process exit code if the node was > stopped by failure handler [1][2]. At the moment ignite process returns > exit code 0 after the stop in all scenarios, except runtime halt by > StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > > My proposal: always finish Ignite process with code [3], if a node was > stopped by FH. It could be helpful for administration purposes, you can > distinguish normal node stop from node stop by FH on OS level. > > WDYT? > > [1] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > [2] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > [3] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13047) Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler
Sergey Antonov created IGNITE-13047: --- Summary: Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler Key: IGNITE-13047 URL: https://issues.apache.org/jira/browse/IGNITE-13047 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Ignite process must be finished with exit code 130 [1] if the node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHanlder. [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[DISCUSS] Ignite process exit code on node stop by failure handler
Hello, Igniters! I'd like to discuss behaviour of Ignite process exit code if the node was stopped by failure handler [1][2]. At the moment ignite process returns exit code 0 after the stop in all scenarios, except runtime halt by StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] My proposal: always finish Ignite process with code [3], if a node was stopped by FH. It could be helpful for administration purposes, you can distinguish normal node stop from node stop by FH on OS level. WDYT? [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html [2] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html [3] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE -- BR, Sergey Antonov
Re: Proposal: set default transaction timeout to 5 minutes
+1 пн, 18 мая 2020 г. в 21:26, Andrey Mashenkov : > +1 > > On Mon, May 18, 2020 at 9:19 PM Ivan Rakov wrote: > > > Hi Igniters, > > > > I have a very simple proposal. Let's set default TX timeout to 5 minutes > > (right now it's 0 = no timeout). > > Pros: > > 1. Deadlock detection procedure is triggered on timeout. In case user > will > > get into key-level deadlock, he'll be able to discover root cause from > the > > logs (even though load will hang for a while) and skip step with googling > > and debugging. > > 2. Almost every system with transactions has timeout enabled by default. > > > > WDYT? > > > > -- > > Best Regards, > > Ivan Rakov > > > > > -- > Best regards, > Andrey V. Mashenkov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-13004) Fix wrong comparison in TcpCommunicationSpi#closeConnections(UUID)
Sergey Antonov created IGNITE-13004:
---
Summary: Fix wrong comparison in
TcpCommunicationSpi#closeConnections(UUID)
Key: IGNITE-13004
URL: https://issues.apache.org/jira/browse/IGNITE-13004
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9, 2.8.1
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.9
In IGNITE-12774 was introduced a bug in comparison:
{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey))
continue;
{code}
The right code is:
{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey.nodeId()))
continue;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Moving binary metadata to PDS storage folder
Hello Semyon, This is a good idea! вт, 12 мая 2020 г. в 15:53, Вячеслав Коптилин : > Hello Semyon, > > This is a good and long-awaited improvement! Thank you for your efforts! > > Thanks, > S. > > вт, 12 мая 2020 г. в 15:11, Данилов Семён : > > > Hello! > > > > I would like to propose moving /binary_meta and /marshaller folders to > the > > PDS folder. > > > > Motivation: data, directly related to the persistence, is stored outside > > the persistence dir, which can lead to various issues and also is not > very > > convenient to use. In particular, with k8s, deployment disk that is > > attached to a container can not be accessed from other containers or > > outside of k8s. In case if support will need to drop persistence except > > data, there will be no way to recover due to binary metadata is required > to > > process PDS files. > > > > I created an issue (https://issues.apache.org/jira/browse/IGNITE-12994) > and a > > pull request(https://github.com/apache/ignite/pull/7792) that fixes the > > issue. > > > > In that PR I made the following: > > > > > > * store binary meta and marshaller data inside db/ folder > > * if binary meta of marshaller are found in "legacy" locations -- > > safely move them to new locations during the node startup > > > > > > Kind regards, > > > > Semyon Danilov. > > > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
Sergey Antonov created IGNITE-12985:
---
Summary: Fix unguarded log.info/log.debug/log.trace usages
Key: IGNITE-12985
URL: https://issues.apache.org/jira/browse/IGNITE-12985
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
There are multiple places in code where {{log.info()/log.debug()/log.trace()}}
is called without checking {{if (log.isInfoEnabled)}}. This leads to polluted
logs when INFO/DEBUG/TRACE is disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Check indexes inline size tool
Hi, the ticket is ready for review. [1] https://github.com/apache/ignite/pull/7728 вт, 28 апр. 2020 г. в 14:39, Sergey Antonov : > Maxim, I'm talking about cluster upgrade through cluster stop -> binary > update -> cluster start. > > вт, 28 апр. 2020 г. в 14:37, Maxim Muzafarov : > >> Sergey, >> >> Are you talking about a cluster rolling upgrade feature? AFAIK, Apache >> Ignite doesn't support this feature, so why we should care about it? >> >> On Tue, 28 Apr 2020 at 14:32, Sergey Antonov >> wrote: >> > >> > Maxim, >> > >> > > should we _reject_ joining nodes which have different >> > From my point of view, it's a breaking change on cluster update. >> > >> > We can get a different inline size in other scenarios too: as I know we >> did >> > some improvements in calculation effective (actual) index inline size. >> > Let's imagine, we have PDS cluster created on the "old" apache ignite >> > version. We decided to upgrade Ignite version and after that, join a new >> > node to the cluster. On a new node, effective inline sizes will be >> > calculated by the optimized algorithm. On the old nodes, the inline size >> > will not be recalculated. It can lead to a difference in inline sizes >> > without IGNITE_MAX_INDEX_PAYLOAD_SIZE option. >> > >> > >> > >> > вт, 28 апр. 2020 г. в 14:22, Maxim Muzafarov : >> > >> > > Sergey, Ilya, >> > > >> > > >> > > Since inline size for the `create table` clause not supported yet and >> > > the IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option, should we >> > > _reject_ joining nodes which have different >> > > IGNITE_MAX_INDEX_PAYLOAD_SIZE value instead for allowing and printing >> > > warning message? Thus we will force users to have the same values of >> > > IGNITE_MAX_INDEX_PAYLOAD_SIZE property. >> > > >> > > >> > > On Tue, 28 Apr 2020 at 14:01, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> > > wrote: >> > > > >> > > > Hello! >> > > > >> > > > Unfortunately and embarrassingly, we still do not support passing >> > > > INLINE_SIZE to CREATE TABLE, at least in 2.8.0. >> > > > This means IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option to >> create an >> > > > implicit primary key index with specified inline size. >> > > > >> > > > Regards, >> > > > -- >> > > > Ilya Kasnacheev >> > > > >> > > > >> > > > вт, 28 апр. 2020 г. в 02:31, Denis Magda : >> > > > >> > > > > Hi Sergey, >> > > > > >> > > > > Your changes look useful from the application developer >> perspective. >> > > > > However, I'm curious why would the one change some low-level >> > > > > IGNITE_MAX_INDEX_PAYLOAD_SIZE parameter when it's advised to pass >> > > > > INLINE_SIZE to CREATE TABLE to change the index size cluster-wide. >> > > > > >> > > > > - >> > > > > Denis >> > > > > >> > > > > >> > > > > On Mon, Apr 27, 2020 at 5:38 AM Sergey Antonov < >> > > antonovserge...@gmail.com> >> > > > > wrote: >> > > > > >> > > > > > Hi, Igniters! >> > > > > > >> > > > > > I'd like to share a new small feature in AI [1]. >> > > > > > >> > > > > > For different reasons, the cluster could have a different SQL >> index >> > > > > inline >> > > > > > size [2] on cluster nodes. For example due to >> > > > > > different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster >> nodes. >> > > > > > >> > > > > > The difference in index inline size may lead to performance >> > > degradation. >> > > > > > I think we must compare inline sizes on node join and warn if >> > > difference >> > > > > > found. Also, We should have the ability to check inline sizes on >> > > demand. >> > > > > > >> > > > > > I've implemented this check on node join and new command in >> > > control.sh >> > > > > > >> > > > > > Look at warning message and utili
Re: Check indexes inline size tool
Maxim, I'm talking about cluster upgrade through cluster stop -> binary update -> cluster start. вт, 28 апр. 2020 г. в 14:37, Maxim Muzafarov : > Sergey, > > Are you talking about a cluster rolling upgrade feature? AFAIK, Apache > Ignite doesn't support this feature, so why we should care about it? > > On Tue, 28 Apr 2020 at 14:32, Sergey Antonov > wrote: > > > > Maxim, > > > > > should we _reject_ joining nodes which have different > > From my point of view, it's a breaking change on cluster update. > > > > We can get a different inline size in other scenarios too: as I know we > did > > some improvements in calculation effective (actual) index inline size. > > Let's imagine, we have PDS cluster created on the "old" apache ignite > > version. We decided to upgrade Ignite version and after that, join a new > > node to the cluster. On a new node, effective inline sizes will be > > calculated by the optimized algorithm. On the old nodes, the inline size > > will not be recalculated. It can lead to a difference in inline sizes > > without IGNITE_MAX_INDEX_PAYLOAD_SIZE option. > > > > > > > > вт, 28 апр. 2020 г. в 14:22, Maxim Muzafarov : > > > > > Sergey, Ilya, > > > > > > > > > Since inline size for the `create table` clause not supported yet and > > > the IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option, should we > > > _reject_ joining nodes which have different > > > IGNITE_MAX_INDEX_PAYLOAD_SIZE value instead for allowing and printing > > > warning message? Thus we will force users to have the same values of > > > IGNITE_MAX_INDEX_PAYLOAD_SIZE property. > > > > > > > > > On Tue, 28 Apr 2020 at 14:01, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > > Hello! > > > > > > > > Unfortunately and embarrassingly, we still do not support passing > > > > INLINE_SIZE to CREATE TABLE, at least in 2.8.0. > > > > This means IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option to > create an > > > > implicit primary key index with specified inline size. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > вт, 28 апр. 2020 г. в 02:31, Denis Magda : > > > > > > > > > Hi Sergey, > > > > > > > > > > Your changes look useful from the application developer > perspective. > > > > > However, I'm curious why would the one change some low-level > > > > > IGNITE_MAX_INDEX_PAYLOAD_SIZE parameter when it's advised to pass > > > > > INLINE_SIZE to CREATE TABLE to change the index size cluster-wide. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Mon, Apr 27, 2020 at 5:38 AM Sergey Antonov < > > > antonovserge...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi, Igniters! > > > > > > > > > > > > I'd like to share a new small feature in AI [1]. > > > > > > > > > > > > For different reasons, the cluster could have a different SQL > index > > > > > inline > > > > > > size [2] on cluster nodes. For example due to > > > > > > different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster > nodes. > > > > > > > > > > > > The difference in index inline size may lead to performance > > > degradation. > > > > > > I think we must compare inline sizes on node join and warn if > > > difference > > > > > > found. Also, We should have the ability to check inline sizes on > > > demand. > > > > > > > > > > > > I've implemented this check on node join and new command in > > > control.sh > > > > > > > > > > > > Look at warning message and utility command output: > > > > > > > > > > > > Warn message on a node in the cluster during new node join: > > > > > > > > > > > > [2020-04-27 15:36:21,185][WARN ][tcp-disco-msg-worker-[6ba0b823 > > > > > > 127.0.0.1:47502 > > > > > > > crd]-#17%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > > > Inline > > > > > > sizes on local node and node > 5bf6ca48-34a0-4
Re: Check indexes inline size tool
Maxim, > should we _reject_ joining nodes which have different >From my point of view, it's a breaking change on cluster update. We can get a different inline size in other scenarios too: as I know we did some improvements in calculation effective (actual) index inline size. Let's imagine, we have PDS cluster created on the "old" apache ignite version. We decided to upgrade Ignite version and after that, join a new node to the cluster. On a new node, effective inline sizes will be calculated by the optimized algorithm. On the old nodes, the inline size will not be recalculated. It can lead to a difference in inline sizes without IGNITE_MAX_INDEX_PAYLOAD_SIZE option. вт, 28 апр. 2020 г. в 14:22, Maxim Muzafarov : > Sergey, Ilya, > > > Since inline size for the `create table` clause not supported yet and > the IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option, should we > _reject_ joining nodes which have different > IGNITE_MAX_INDEX_PAYLOAD_SIZE value instead for allowing and printing > warning message? Thus we will force users to have the same values of > IGNITE_MAX_INDEX_PAYLOAD_SIZE property. > > > On Tue, 28 Apr 2020 at 14:01, Ilya Kasnacheev > wrote: > > > > Hello! > > > > Unfortunately and embarrassingly, we still do not support passing > > INLINE_SIZE to CREATE TABLE, at least in 2.8.0. > > This means IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option to create an > > implicit primary key index with specified inline size. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 28 апр. 2020 г. в 02:31, Denis Magda : > > > > > Hi Sergey, > > > > > > Your changes look useful from the application developer perspective. > > > However, I'm curious why would the one change some low-level > > > IGNITE_MAX_INDEX_PAYLOAD_SIZE parameter when it's advised to pass > > > INLINE_SIZE to CREATE TABLE to change the index size cluster-wide. > > > > > > - > > > Denis > > > > > > > > > On Mon, Apr 27, 2020 at 5:38 AM Sergey Antonov < > antonovserge...@gmail.com> > > > wrote: > > > > > > > Hi, Igniters! > > > > > > > > I'd like to share a new small feature in AI [1]. > > > > > > > > For different reasons, the cluster could have a different SQL index > > > inline > > > > size [2] on cluster nodes. For example due to > > > > different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster nodes. > > > > > > > > The difference in index inline size may lead to performance > degradation. > > > > I think we must compare inline sizes on node join and warn if > difference > > > > found. Also, We should have the ability to check inline sizes on > demand. > > > > > > > > I've implemented this check on node join and new command in > control.sh > > > > > > > > Look at warning message and utility command output: > > > > > > > > Warn message on a node in the cluster during new node join: > > > > > > > > [2020-04-27 15:36:21,185][WARN ][tcp-disco-msg-worker-[6ba0b823 > > > > 127.0.0.1:47502 > > > > crd]-#17%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > Inline > > > > sizes on local node and node 5bf6ca48-34a0-4aff-8db2-c0b6df303d3f are > > > > different. Please drop and create again these indexes to avoid > > > performance > > > > problems with SQL queries. Problem indexes: > > > > > > > > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > > > > > > > Warn messages on a joining node, if difference found: > > > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > > > 127.0.0.1:47501 > > > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > > Inline sizes on local node and node > a86e9cea-63e8-42af-a897-cec4be51 > > > > are different. Please drop and create again these indexes to avoid > > > > performance problems with SQL queries. Problem indexes: > > > > > > > > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > > > 127.0.0.1:47501 > > > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > > Inline sizes on local node and node > a08de16d-df05-48af-a0b9-5596d9c2 &
Re: Check indexes inline size tool
Hello! Unfortunately, that's true. But the user can restart cluster after tables creation and create secondary indexes (CREATE INDEX) after restart. My workaround has a lot of limitations: it doesn't work with in-memory clusters, it's unuseful. вт, 28 апр. 2020 г. в 14:01, Ilya Kasnacheev : > Hello! > > Unfortunately and embarrassingly, we still do not support passing > INLINE_SIZE to CREATE TABLE, at least in 2.8.0. > This means IGNITE_MAX_INDEX_PAYLOAD_SIZE is the only option to create an > implicit primary key index with specified inline size. > > Regards, > -- > Ilya Kasnacheev > > > вт, 28 апр. 2020 г. в 02:31, Denis Magda : > > > Hi Sergey, > > > > Your changes look useful from the application developer perspective. > > However, I'm curious why would the one change some low-level > > IGNITE_MAX_INDEX_PAYLOAD_SIZE parameter when it's advised to pass > > INLINE_SIZE to CREATE TABLE to change the index size cluster-wide. > > > > - > > Denis > > > > > > On Mon, Apr 27, 2020 at 5:38 AM Sergey Antonov < > antonovserge...@gmail.com> > > wrote: > > > > > Hi, Igniters! > > > > > > I'd like to share a new small feature in AI [1]. > > > > > > For different reasons, the cluster could have a different SQL index > > inline > > > size [2] on cluster nodes. For example due to > > > different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster nodes. > > > > > > The difference in index inline size may lead to performance > degradation. > > > I think we must compare inline sizes on node join and warn if > difference > > > found. Also, We should have the ability to check inline sizes on > demand. > > > > > > I've implemented this check on node join and new command in control.sh > > > > > > Look at warning message and utility command output: > > > > > > Warn message on a node in the cluster during new node join: > > > > > > [2020-04-27 15:36:21,185][WARN ][tcp-disco-msg-worker-[6ba0b823 > > > 127.0.0.1:47502 > > > crd]-#17%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > Inline > > > sizes on local node and node 5bf6ca48-34a0-4aff-8db2-c0b6df303d3f are > > > different. Please drop and create again these indexes to avoid > > performance > > > problems with SQL queries. Problem indexes: > > > > > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > > > > > Warn messages on a joining node, if difference found: > > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > > 127.0.0.1:47501 > > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > Inline sizes on local node and node > a86e9cea-63e8-42af-a897-cec4be51 > > > are different. Please drop and create again these indexes to avoid > > > performance problems with SQL queries. Problem indexes: > > > > > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > > 127.0.0.1:47501 > > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > > Inline sizes on local node and node > a08de16d-df05-48af-a0b9-5596d9c2 > > > are different. Please drop and create again these indexes to avoid > > > performance problems with SQL queries. Problem indexes: > > > > > > > > > PUBLIC#TEST_TABLE#L_IDX(1,3),PUBLIC#TEST_TABLE#S1_IDX(1,3),PUBLIC#TEST_TABLE#I_IDX(1,3) > > > > > > > > > Utility output, if a difference in inline sizes was found: > > > > > > Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:DEV] > > > 2020 Copyright(C) Apache Software Foundation > > > User: santonov > > > Time: 2020-04-27T15:32:25.759 > > > Command [CACHE] started > > > Arguments: --cache check_index_inline_sizes --yes > > > > > > > > > > > > Found 4 secondary indexes. > > > 3 index(es) have different effective inline size on nodes. It can lead > to > > > performance degradation in SQL queries. > > > Index(es): > > > Full index name: PUBLIC#TEST_TABLE#L_IDX nodes: > > > [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: > > > [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 > > > Full index name: PUBLIC#TEST
Re: Check indexes inline size tool
Hi Denis, The problem could be shown when you invoke CREATE INDEX without the INLINE_SIZE parameter. You don't face with described problem If index creates by CREATE_INDEX with explicit INLINE SIZE value. вт, 28 апр. 2020 г. в 02:31, Denis Magda : > Hi Sergey, > > Your changes look useful from the application developer perspective. > However, I'm curious why would the one change some low-level > IGNITE_MAX_INDEX_PAYLOAD_SIZE parameter when it's advised to pass > INLINE_SIZE to CREATE TABLE to change the index size cluster-wide. > > - > Denis > > > On Mon, Apr 27, 2020 at 5:38 AM Sergey Antonov > wrote: > > > Hi, Igniters! > > > > I'd like to share a new small feature in AI [1]. > > > > For different reasons, the cluster could have a different SQL index > inline > > size [2] on cluster nodes. For example due to > > different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster nodes. > > > > The difference in index inline size may lead to performance degradation. > > I think we must compare inline sizes on node join and warn if difference > > found. Also, We should have the ability to check inline sizes on demand. > > > > I've implemented this check on node join and new command in control.sh > > > > Look at warning message and utility command output: > > > > Warn message on a node in the cluster during new node join: > > > > [2020-04-27 15:36:21,185][WARN ][tcp-disco-msg-worker-[6ba0b823 > > 127.0.0.1:47502 > > crd]-#17%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > Inline > > sizes on local node and node 5bf6ca48-34a0-4aff-8db2-c0b6df303d3f are > > different. Please drop and create again these indexes to avoid > performance > > problems with SQL queries. Problem indexes: > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > > > Warn messages on a joining node, if difference found: > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > 127.0.0.1:47501 > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > Inline sizes on local node and node a86e9cea-63e8-42af-a897-cec4be51 > > are different. Please drop and create again these indexes to avoid > > performance problems with SQL queries. Problem indexes: > > > > > PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) > > [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea > > 127.0.0.1:47501 > > ]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] > > Inline sizes on local node and node a08de16d-df05-48af-a0b9-5596d9c2 > > are different. Please drop and create again these indexes to avoid > > performance problems with SQL queries. Problem indexes: > > > > > PUBLIC#TEST_TABLE#L_IDX(1,3),PUBLIC#TEST_TABLE#S1_IDX(1,3),PUBLIC#TEST_TABLE#I_IDX(1,3) > > > > > > Utility output, if a difference in inline sizes was found: > > > > Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:DEV] > > 2020 Copyright(C) Apache Software Foundation > > User: santonov > > Time: 2020-04-27T15:32:25.759 > > Command [CACHE] started > > Arguments: --cache check_index_inline_sizes --yes > > > > > > > Found 4 secondary indexes. > > 3 index(es) have different effective inline size on nodes. It can lead to > > performance degradation in SQL queries. > > Index(es): > > Full index name: PUBLIC#TEST_TABLE#L_IDX nodes: > > [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: > > [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 > > Full index name: PUBLIC#TEST_TABLE#S1_IDX nodes: > > [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: > > [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 > > Full index name: PUBLIC#TEST_TABLE#I_IDX nodes: > > [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: > > [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 > > > > Recommendations: > > Check that value of property IGNITE_MAX_INDEX_PAYLOAD_SIZE are the same > > on all nodes. > > Recreate indexes (execute DROP INDEX, CREATE INDEX commands) with > > different inline size. > > Command [CACHE] finished with code: 0 > > Control utility has completed execution at: 2020-04-27T15:32:28.025 > > Execution time: 2266 ms > > > > Utility output, if all indexes have the same inline size: > > > > Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:DEV] > > 2020 Copyrig
[jira] [Created] (IGNITE-12955) Document a new command control.sh --cache check_index_inline_sizes
Sergey Antonov created IGNITE-12955: --- Summary: Document a new command control.sh --cache check_index_inline_sizes Key: IGNITE-12955 URL: https://issues.apache.org/jira/browse/IGNITE-12955 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Fix For: 2.9 Please look at IGNITE-12942 and devlist discussion linked to IGNITE-12942 for all information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Check indexes inline size tool
Hi, Igniters! I'd like to share a new small feature in AI [1]. For different reasons, the cluster could have a different SQL index inline size [2] on cluster nodes. For example due to different IGNITE_MAX_INDEX_PAYLOAD_SIZE [3] value on cluster nodes. The difference in index inline size may lead to performance degradation. I think we must compare inline sizes on node join and warn if difference found. Also, We should have the ability to check inline sizes on demand. I've implemented this check on node join and new command in control.sh Look at warning message and utility command output: Warn message on a node in the cluster during new node join: [2020-04-27 15:36:21,185][WARN ][tcp-disco-msg-worker-[6ba0b823 127.0.0.1:47502 crd]-#17%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] Inline sizes on local node and node 5bf6ca48-34a0-4aff-8db2-c0b6df303d3f are different. Please drop and create again these indexes to avoid performance problems with SQL queries. Problem indexes: PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) Warn messages on a joining node, if difference found: [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea 127.0.0.1:47501]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] Inline sizes on local node and node a86e9cea-63e8-42af-a897-cec4be51 are different. Please drop and create again these indexes to avoid performance problems with SQL queries. Problem indexes: PUBLIC#TEST_TABLE#L_IDX(1,2),PUBLIC#TEST_TABLE#S1_IDX(1,2),PUBLIC#TEST_TABLE#I_IDX(1,2) [2020-04-27 15:35:17,326][WARN ][tcp-disco-msg-worker-[a86e9cea 127.0.0.1:47501]-#11%cache.CheckIndexesInlineSizeOnNodeJoinMultiJvmTest0%][root] Inline sizes on local node and node a08de16d-df05-48af-a0b9-5596d9c2 are different. Please drop and create again these indexes to avoid performance problems with SQL queries. Problem indexes: PUBLIC#TEST_TABLE#L_IDX(1,3),PUBLIC#TEST_TABLE#S1_IDX(1,3),PUBLIC#TEST_TABLE#I_IDX(1,3) Utility output, if a difference in inline sizes was found: Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:DEV] 2020 Copyright(C) Apache Software Foundation User: santonov Time: 2020-04-27T15:32:25.759 Command [CACHE] started Arguments: --cache check_index_inline_sizes --yes Found 4 secondary indexes. 3 index(es) have different effective inline size on nodes. It can lead to performance degradation in SQL queries. Index(es): Full index name: PUBLIC#TEST_TABLE#L_IDX nodes: [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 Full index name: PUBLIC#TEST_TABLE#S1_IDX nodes: [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 Full index name: PUBLIC#TEST_TABLE#I_IDX nodes: [ca1d2bae-89d4-4e8d-ae11-6c68f390] inline size: 1, nodes: [8327abd1-df08-4b97-8720-de95e363e745] inline size: 2 Recommendations: Check that value of property IGNITE_MAX_INDEX_PAYLOAD_SIZE are the same on all nodes. Recreate indexes (execute DROP INDEX, CREATE INDEX commands) with different inline size. Command [CACHE] finished with code: 0 Control utility has completed execution at: 2020-04-27T15:32:28.025 Execution time: 2266 ms Utility output, if all indexes have the same inline size: Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:DEV] 2020 Copyright(C) Apache Software Foundation User: santonov Time: 2020-04-27T15:30:20.950 Command [CACHE] started Arguments: --cache check_index_inline_sizes --yes Found 2 secondary indexes. All secondary indexes have the same effective inline size on all cluster nodes. Command [CACHE] finished with code: 0 Control utility has completed execution at: 2020-04-27T15:30:23.428 Execution time: 2478 ms Any objections? [1] https://issues.apache.org/jira/browse/IGNITE-12942 [2] https://apacheignite-sql.readme.io/docs/create-index [3] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteSystemProperties.html#IGNITE_MAX_INDEX_PAYLOAD_SIZE -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
Sergey Antonov created IGNITE-12942: --- Summary: control.sh add command for checking that inline size is same on all cluster nodes Key: IGNITE-12942 URL: https://issues.apache.org/jira/browse/IGNITE-12942 Project: Ignite Issue Type: New Feature Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 We should check that the inline size is the same for the index on all nodes in the cluster. 1. Check inline_size of secondary indexes on node join. Warn to log if they differ and propose a recreate problem index. 2. Introduce a new command to control.sh (control.sh --cache check_index_inline_sizes). The command will check inline sizes of secondary indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] `static final` code-style constant naming rules
Maxim, It's a good idea! Please don't forget to update out code style guidelines too. Thank you for keeping the code cleaner! пт, 24 апр. 2020 г. в 19:49, Maxim Muzafarov : > Igniters, > > > It is not directly mentioned through the Apache Ignite Coding > Guidelines [1] about naming the `static final` class fields using only > upper-case letters. I'd like to suggest to fill this gap. > > > Constants should all be upper-case. > But what exactly is `constant` means?! I'd suggest applying this rule > to all class fields with `static final` modifiers without any clauses. > (check Java Naming convention [2] paragraph 3.3). > > > I've prepared PR [3] with capitalizing letters on all of the constant > names simultaneously with supporting the standard ConstantName > checkstyle [4] rule. > > Can we proceed with this change? > WDYT? > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Naming > [2] > https://web.archive.org/web/20120911192801/developers.sun.com/sunstudio/products/archive/whitepapers/java-style.pdf > [3] https://github.com/apache/ignite/pull/7662 > [4] https://issues.apache.org/jira/browse/IGNITE-12888 > -- BR, Sergey Antonov
Re: Get rid of @Nullable and @NotNull
I disagree. Intellij idea IDE has a static code analysis, which uses that annotation too. IDE highlights possible problems. It helps to make our code more stable and bugless. пт, 27 мар. 2020 г. в 12:06, Pavel Tupitsyn : > I disagree, it would be a step back. > > > What's the reason for using it? > Null was a billion dollar mistake [1]. > NullPointerExceptions happen quite a lot in Ignite, and annotations provide > some clues to avoid those. > > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions > > On Fri, Mar 27, 2020 at 10:58 AM Anton Vinogradov wrote: > > > Folks, > > > > Found we still use @Nullable annotation. > > > > What's the reason for using it? > > Everything is Object and Nullable :) > > > > How about get rid of @Nullable usages and restrict its usage by > checkstyle > > plugin? > > > > BTW, We already "do not use @NotNull annotation" (с) Coding Guidelines > [1] > > which may have some cense in contrast to @Nullable. > > But I see a lot of usages at code. > > > > How about to get rid of @NotNull too and to add such check to checkstyle > > plugin too? > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-@Annotations > > > -- BR, Sergey Antonov
Re: Re[2]: Discuss idle_verify with moving partitions changes.
Zhenya, Vlad's message looks incorrectly. How about something like: "Not all partitions were checked. Check of partitions was skipped due to rebalancing is in progress. Please rerun idle_verify after finish rebalancing." пн, 23 мар. 2020 г. в 12:47, Zhenya Stanilovsky : > > Guys thank for quick response, Ivan what do you think about Vlad`s > proposal to add additional info like : > "Possible results are not consistent due to rebalance still in progress" ? > Thanks ! > > >Понедельник, 23 марта 2020, 12:30 +03:00 от Ivan Rakov < > ivan.glu...@gmail.com>: > > > >Zhenya, > > > >As for me, the current behavior of idle_verify looks correct. > >There's no sense in checking MOVING partitions (on which we explicitly > >inform user), however checking consistency between the rest of owners > still > >makes sense: they still can diverge and we can be aware of the presence of > >the conflicts sooner. > >In case cluster is not idle (in terms of user activities, not in terms of > >internal cluster processes like rebalancing), utility will fail as > expected. > > > >On Mon, Mar 23, 2020 at 11:23 AM Vladislav Pyatkov < > vpyat...@gridgain.com > > >wrote: > > > >> Hi Zhenya, > >> > >> I see your point. Need to show some message, because cluster is not idle > >> (rebalance is going). > >> When cluster not idle we cannot validate partitions honestly. After > several > >> minutes we can to get absolutely different result, without any client's > >> operation of cache happened. > >> > >> May be enough showing some message more clear for end user. For example: > >> "Result has not valid, rebalance is going." > >> > >> Another thing you meaning - issue in indexes, when rebalance is > following. > >> I think idex_validate should fail in this case, because indexes always > in > >> load during rebalance. > >> > >> > >> On Mon, Mar 23, 2020 at 10:20 AM Zhenya Stanilovsky > >> < arzamas...@mail.ru.invalid > wrote: > >> > >> > > >> > Igniters, i found that near idle check commands only shows partitions > in > >> > MOVING states as info in log and not take into account this fact as > >> > erroneous idle cluster state. > >> > control.sh --cache idle_verify, control.sh --cache validate_indexes > >> > --check-crc > >> > > >> > for example command would show something like : > >> > > >> > Arguments: --cache idle_verify --yes > >> > > >> > > >> > > >> > idle_verify task was executed with the following args: caches=[], > >> > excluded=[], cacheFilter=[DEFAULT] > >> > idle_verify check has finished, no conflicts have been found. > >> > Verification was skipped for 21 MOVING partitions: > >> > Skipped partition: PartitionKeyV2 [grpId=1544803905, grpName=default, > >> > partId=7] > >> > Partition instances: [PartitionHashRecordV2 [isPrimary=false, > >> > consistentId=gridCommandHandlerTest2, updateCntr=3, > >> partitionState=MOVING, > >> > state=MOVING]] .. and so on > >> > > >> > I found this erroneous and can lead to further cluster index > corruption, > >> > for example in case when only command OK result checked. > >> > > >> > If no objections would be here, i plan to inform about moving states > as > >> > not OK exit code too. > >> > > >> > > >> > >> > >> > >> -- > >> Vladislav Pyatkov > >> Architect-Consultant "GridGain Rus" Llc. > >> +7-929-537-79-60 > >> > > > > -- BR, Sergey Antonov
Re: Apache Ignite 2.8.1 RELEASE [Time, Scope, Manager]
Folks, I'd like to add ticket IGNITE-12774 Transaction hangs after too many open files NIO exception [1] to ignite-2.8.1 scope. [1] https://issues.apache.org/jira/browse/IGNITE-12774 ср, 18 мар. 2020 г. в 16:53, Maxim Muzafarov : > Folks, > > Can we add ignite-2.8.1 [2] branch under TC.Bot protection [1]? > > > [1] https://mtcga.gridgain.com/guard.html > [2] https://github.com/apache/ignite/tree/ignite-2.8.1 > > On Mon, 16 Mar 2020 at 16:32, Alexey Goncharuk > wrote: > > > > Folks, > > > > I've walked through all the commits to master since 2.8 branch was cut > and > > filtered some tickets that in my opinion are worth including to 2.8.1 > > release below (note that they are ready end the effort of including them > to > > the release should be low as long as there are no implicit dependencies > > between tickets). Please share your opinion on whether we should include > > them to the 2.8.1. > > > > IGNITE-12717 SQL: index creation refactoring > > IGNITE-12590 MERGE INTO query is failing on Ignite client node > > IGNITE-12671 Update of partition's states can stuck when rebalance > > completed during exchange > > IGNITE-11798 Memory leak on unstable topology caused by partition > > reservation > > IGNITE-12665 SQL: Potential race on MapResult close. > > IGNITE-12605 Historical (WAL) rebalance can start on a cleared partition > if > > some baseline node leaves the cluster and then joins back. > > IGNITE-12654 Some of rentingFutures in GridDhtPartitionTopologyImpl may > > accumulate a huge number of eviction callbacks > > IGNITE-12631 Incorrect rewriting wal record type in marshalled mode > during > > iteration > > IGNITE-12621 Node leave may cause NullPointerException during IO message > > processing if security is enabled > > IGNITE-12636 Full rebalance instead of a historical one > > IGNITE-12618 Affinity cache for version of last server event can be wiped > > from history > > IGNITE-12013 NullPointerException is thrown by ExchangeLatchManager > during > > cache creation > > IGNITE-11797 Fix consistency issues for atomic and mixed tx-atomic cache > > groups. > > IGNITE-12557 Destroy of big cache which is not only cache in cache group > > causes IgniteOOME > > IGNITE-12567 H2Tree goes into illegal state when non-indexed columns are > > dropped > > IGNITE-12569 Can't set serialized enum to a BinaryObject's field > > IGNITE-12460 Cluster fails to find the node by consistent ID > > IGNITE-12459 Searching checkpoint record in WAL doesn't work with segment > > compaction > > IGNITE-12548 Possible tx desync during recovery on near node left. > > IGNITE-12546 Prevent partitions owned by other nodes switch their state > to > > MOVING due to counter difference on node join. > > IGNITE-12551 Partition desync if a partition is evicted then owned again > > and historically rebalanced > > IGNITE-12536 Inconsistency between cache data and indexes when cache > > operation is interrupted > > IGNITE-12403 Throttle page difference output in PageMemoryTracker > > IGNITE-12523 Continuously generated thread dumps in failure processor > slow > > down the whole system > > IGNITE-12489 Error during purges by expiration: Unknown page type > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12803) Investigate exception message on too many open files in different OS.
Sergey Antonov created IGNITE-12803: --- Summary: Investigate exception message on too many open files in different OS. Key: IGNITE-12803 URL: https://issues.apache.org/jira/browse/IGNITE-12803 Project: Ignite Issue Type: Task Environment: In IGNITE-12774 we introduced node failing if we got "too many open files" during open connection. I'm not sure that in all OS we will get that message. We need to investigate it. Reporter: Sergey Antonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12774) Transaction hungs after too many open files NIO exception
Sergey Antonov created IGNITE-12774:
---
Summary: Transaction hungs after too many open files NIO exception
Key: IGNITE-12774
URL: https://issues.apache.org/jira/browse/IGNITE-12774
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Transaction hung after “Open too many files” error and never been finished.
{code:java}
import java.net.SocketException;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.ignite.cluster.ClusterNode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.lang.IgniteInClosure;
import org.apache.ignite.plugin.extensions.communication.Message;
import org.apache.ignite.spi.IgniteSpiException;
import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.apache.ignite.transactions.Transaction;
import org.apache.ignite.transactions.TransactionConcurrency;
import org.apache.ignite.transactions.TransactionIsolation;
import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheMode.PARTITIONED;
public class TooManyOpenFilesTest extends GridCommonAbstractTest {
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setFailureHandler(new StopNodeOrHaltFailureHandler())
.setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
.setConsistentId(igniteInstanceName);
}
@Override protected void beforeTest() throws Exception {
super.beforeTest();
stopAllGrids();
cleanPersistenceDir();
}
@Override protected void afterTest() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.afterTest();
}
public void test() throws Exception {
IgniteEx crd = startGrids(3);
crd.cluster().active(true);
crd.getOrCreateCache(new
CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
TooManyOpenFilesTcpCommunicationSpi spi =
(TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
try (Transaction tx =
grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
TransactionIsolation.REPEATABLE_READ)) {
IgniteCache cache =
grid(1).cache(DEFAULT_CACHE_NAME);
cache.put(1, 1);
spi.throwException.set(true);
cache.put(2, 2);
cache.put(3, 2);
cache.put(4, 2);
// hungs here.
tx.commit();
}
for (int i=0; i < 3 ; i++) {
assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
}
}
private static class TooManyOpenFilesTcpCommunicationSpi extends
TcpCommunicationSpi {
private final AtomicBoolean throwException = new AtomicBoolean();
/** {@inheritDoc} */
@Override public void sendMessage(ClusterNode node, Message msg) throws
IgniteSpiException {
if (throwException.get())
throw getException(node);
super.sendMessage(node, msg);
}
/** {@inheritDoc} */
@Override public void sendMessage(
ClusterNode node,
Message msg,
IgniteInClosure ackC
) throws IgniteSpiException {
if (throwException.get())
throw getException(node);
super.sendMessage(node, msg, ackC);
}
private IgniteSpiException getException(ClusterNode node) {
String checkedExceptionMsg = "Failed to connect to node (is node
still alive?). " +
"Make sure that each ComputeTask and cache Transaction has a
timeout set " +
"in order to prevent parties from waiting forever in case of
network issues " +
"[nodeId=" + node.id() + ", addrs=null]";
return new IgniteSpiException("Failed to send message to remote
node: " + node.id(), new IgniteCheckedException(checkedExceptionMsg, new
SocketException("Too many open files")));
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [VOTE] Release Apache Ignite 2.8.0 RC1
0. Still can't get access to teamcity links. пн, 2 мар. 2020 г., 17:24 Alexey Zinoviev : > +1 (binding) > I've downloaded the binary archive, run it, checked the ML examples and > JavaDocs. > > > > вс, 1 мар. 2020 г. в 13:49, Ivan Pavlukhin : > > > +1 (binding) > > > > Downloaded binary distribution archive, launched a cluster of 2 nodes, > > created/filled/queried a table using sqlline. > > > > A couple of minor problems along the way (nothing critical to block > > the release): > > 1. Shell scripts in bin directory (ignite.sh, sqlline.sh, etc.) have > > no "execute" permission after extracting. Had to call "chmod +x" > > manually. > > 2. Query syntax errors with stacktraces are written to default console > > output. > > > > Best regards, > > Ivan Pavlukhin > > > > вс, 1 мар. 2020 г. в 11:23, Pavel Tupitsyn : > > > > > > +1 (binding) > > > > > > Started .NET nodes and examples, installed NuGet packages and started > > > Ignite from there > > > > > > On Sat, Feb 29, 2020 at 11:28 PM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > Hello! > > > > > > > > 0 (binding) > > > > > > > > I have checked deb package, built and run C++, ran dotnet example and > > > > sqlline. > > > > > > > > It is unfortunate that we still haven't improved release layout: we > > still > > > > do not ship automake-processed C++, and provide no slim binary > > > > redistributable. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > сб, 29 февр. 2020 г. в 13:18, Anton Vinogradov : > > > > > > > > > +1 (binding) > > > > > > > > > > Checked > > > > > - TC usage completeness and results, > > > > > - Urls correctness and content > > > > > > > > > > On Fri, Feb 28, 2020 at 7:50 PM Denis Magda > > wrote: > > > > > > > > > > > +1 (binding) > > > > > > > > > > > > Downloaded, started a cluster, ran several examples pulling Maven > > > > > > artifacts from the staging. > > > > > > > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Fri, Feb 28, 2020 at 7:09 AM Maxim Muzafarov < > mmu...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > > Dear Community, > > > > > > > > > > > > > > > > > > > > > I have uploaded a release candidate to: > > > > > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > > > > > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > > > > > > > > > The following staging can be used for testing: > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > > > > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > > > > > > Release 2.8 contains a lot of changes, please refer to the > > > > > RELEASE_NOTES: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8 > > > > > > > > > > > > > > Complete list of resolved issues: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated > > > > > > > > > > > > > > DEVNOTES > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8 > > > > > > > > > > > > > > > > > > > > > Additional checks have been performed (available for users > > included > > > > > > > into the release group on TeamCity). > > > > > > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv > > > > > > > > > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv > > > > > > > > > > > > > > TC [2] Compare w/ Previous Release > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv > > > > > > > > > > > > > > > > > > > > > The vote is formal, see voting guidelines > > > > > > > https://www.apache.org/foundation/voting.html > > > > > > > > > > > > > > +1 - to accept Apache Ignite 2.8.0-rc1 > > > > > > > 0 - don't care either way > > > > > > > -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why) > > > > > > > > > > > > > > See notes on how to verify release here > > > > > > > https://www.apache.org/info/verification.html > > > > > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, I get 404 code for all TC links [1][2][3] in your email, not only TC [Check RC: Licenses, compile, chksum]. [1] [1] https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv [2] https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv [3] https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv пт, 28 февр. 2020 г. в 16:41, Maxim Muzafarov : > Sergey, > > > It seems these links ([4] Check RC: Licenses, compile, checksum) [1] > is only accessed for users included into the release group on the > TeamCity. > Sorry for not mentioned it before. > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv > > On Thu, 27 Feb 2020 at 23:17, Sergey Antonov > wrote: > > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts > should I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by > installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > >> Pa
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, can somebody check those links from TC account different from @ apache.org domain? пт, 28 февр. 2020 г. в 11:58, Pavel Tupitsyn : > Sergey, can't confirm, those links work for me > > On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov > > wrote: > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > > wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts > should > > I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by > installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet > > verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > >> Pavel, > > > > >> > > > > >> > > > > >> Thank you for your help. > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > >> > > > > >> > > > > >> Can you also provide some details - which exactly artefacts > should I > > > > >> check on staging resource after the [1] suite execution? > > > > >> > > > > >> [1] > > > > >> > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPa
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
>> > > >> > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because > > >> >> it does not exist. > > >> >> > > >> >> Step 3: > > >> >> Cannot find path > > >> >> > > >> > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll' > > >> >> because it does not exist. > > >> >> At > > >> > C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283 > > >> >> char:47 > > >> >> > > >> >> pack: invalid arguments. > > >> >> > > >> >> > > >> >> [1] > > >> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.4.2.PrepareNuGetstaging > > >> >> [2] > > >> > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > >> >> [3] > > >> > https://ci.ignite.apache.org/viewLog.html?buildId=5080553=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages=buildLog > > >> >> [4] https://issues.apache.org/jira/browse/IGNITE-12604 > > >> >> > > >> >> On Fri, 21 Feb 2020 at 10:36, Maxim Muzafarov > > >> wrote: > > >> >> > > > >> >> > 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 < > mmu...@apache.org> > > >> 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 < > mmu...@apache.org> > > >> 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 < > > >> ilya.kasnach...@gmail.com> > > >> >> > > > 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 < > > >> mmu...@apache.org>: > > >> >> > > > > > > > >> >> > > > > > > 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? > > >> >> > > > > > > > > >> >> > > > > > >> > > > > -- BR, Sergey Antonov
[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: [VOTE] Allow or prohibit a joint use of @deprecated and @IgniteExperimental
-1 Prohibit, We can't deprecate old API while a new API isn't stable. пн, 10 февр. 2020 г. в 11:14, Vyacheslav Daradur : > +1 Allow, because once the community has made a decision to introduce > new APIs instead of an old one - stabilization is just a matter of > time. > > On Mon, Feb 10, 2020 at 11:02 AM Alexey Goncharuk > wrote: > > > > Dear Apache Ignite community, > > > > We would like to conduct a formal vote on the subject of whether to allow > > or prohibit a joint existence of @deprecated annotation for an old API > > and @IgniteExperimental [1] for a new (replacement) API. The result of > this > > vote will be formalized as an Apache Ignite development rule to be used > in > > future. > > > > The discussion thread where you can address all non-vote messages is [2]. > > > > The votes are: > > *[+1 Allow]* Allow to deprecate the old APIs even when new APIs are > marked > > with @IgniteExperimental to explicitly notify users that an old APIs will > > be removed in the next major release AND new APIs are available. > > *[-1 Prohibit]* Never deprecate the old APIs unless the new APIs are > stable > > and released without @IgniteExperimental. The old APIs javadoc may be > > updated with a reference to new APIs to encourage users to evaluate new > > APIs. The deprecation and new API release may happen simultaneously if > the > > new API is not marked with @IgniteExperimental or the annotation is > removed > > in the same release. > > > > Neither of the choices prohibits deprecation of an API without a > > replacement if community decides so. > > > > The vote will hold for 72 hours and will end on February 13th 2020 08:00 > > UTC: > > > https://www.timeanddate.com/countdown/to?year=2020=2=13=8=0=0=utc-1 > > > > All votes count, there is no binding/non-binding status for this. > > > > [1] > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/lang/IgniteExperimental.java > > [2] > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Public-API-deprecation-rules-td45647.html > > > > Thanks, > > --AG > > > > -- > Best Regards, Vyacheslav D. > -- BR, Sergey Antonov
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, Conflicts in pr [1] are resolved. TC Run all is started. [1] https://github.com/apache/ignite/pull/7238 пт, 17 янв. 2020 г. в 16:04, Sergey Antonov : > Maxim, > > I will do that on monday (20/01). > > пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov : > >> Sergey, >> >> >> Can you, please, resolve the PR conflicts [1] [2]? >> >> [1] https://github.com/apache/ignite/pull/7238 >> [2] https://issues.apache.org/jira/browse/IGNITE-11256 >> >> On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev >> wrote: >> > >> > Hello! >> > >> > I have bumped beanutils and re-ran Cassandra Store tests. Can you please >> > comment on the ticket? >> > >> > I think that fixing ZooKeeper is too much effort (there's chaos with >> > jackson vs. jackson-asl), maybe it should be split up as a separate >> ticket >> > to be done later. >> > >> > Regards, >> > -- >> > Ilya Kasnacheev >> > >> > >> > ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin : >> > >> > > Thanks, Ilya. It would be really great to have your patch included >> into 2.8 >> > > scope. >> > > I'd like to give my two cent as well. For example we have vulnerable >> > > dependencies here: >> > > modules/cassandra/store/pom.xml - commons-beanutils >> > > modules/zookeeper/pom.xml - transitive Jackson from Curator >> > > >> > > I'd suggest to uprgrade commons-beanutils:commons-beanutils to 1.9.4 >> and >> > > override com.fasterxml.jackson.core:jackson-databind to our common >> jackson >> > > version from other modules. >> > > >> > > >> > > >> > > -- >> > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> > > >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, I will do that on monday (20/01). пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov : > Sergey, > > > Can you, please, resolve the PR conflicts [1] [2]? > > [1] https://github.com/apache/ignite/pull/7238 > [2] https://issues.apache.org/jira/browse/IGNITE-11256 > > On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev > wrote: > > > > Hello! > > > > I have bumped beanutils and re-ran Cassandra Store tests. Can you please > > comment on the ticket? > > > > I think that fixing ZooKeeper is too much effort (there's chaos with > > jackson vs. jackson-asl), maybe it should be split up as a separate > ticket > > to be done later. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin : > > > > > Thanks, Ilya. It would be really great to have your patch included > into 2.8 > > > scope. > > > I'd like to give my two cent as well. For example we have vulnerable > > > dependencies here: > > > modules/cassandra/store/pom.xml - commons-beanutils > > > modules/zookeeper/pom.xml - transitive Jackson from Curator > > > > > > I'd suggest to uprgrade commons-beanutils:commons-beanutils to 1.9.4 > and > > > override com.fasterxml.jackson.core:jackson-databind to our common > jackson > > > version from other modules. > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > -- BR, Sergey Antonov
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Igniters, I got green TC Bit visas [1] [2] for patch and commit revert. [1] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=ignite-2.8=pull%2F7238%2Fhead=Latest [2] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=ignite-2.8=pull%2F7239%2Fhead=Latest пн, 13 янв. 2020 г., 17:51 Maxim Muzafarov : > Sergey, > > Thank you. I also do not support @IgniteExperemental annotation only > for solving the current case of compatibility issues. > > I like your second suggestion to revert the issue [2] from 2.8 release > by applying [1] PR. I'm going to apply this patch [1] within the next > three days. > > Any objections? > > [1] https://github.com/apache/ignite/pull/7238 > [2] https://issues.apache.org/jira/browse/IGNITE-11256 > > On Sat, 11 Jan 2020 at 17:59, Sergey Antonov > wrote: > > > > Guys, I created two pull requests [1] [2] for 2.8 release. > > > > First of them [1] is a patch with ticket [3] for ignite-2.8 branch. > > Second [2] is a revert of ticket [4] from 2.8 release. > > > > I'm waiting TC run all nightly results for both PRs. I'll write update > when > > TC runs will be ok. > > I'm okay with both proposals (add ticket [1] to release, remove read-only > > feature from 2.8 release scope). But I'm not okay with > @IgniteExperemental > > annotation. > > > > [1] https://github.com/apache/ignite/pull/7239 > > [2] https://github.com/apache/ignite/pull/7238 > > [3] https://issues.apache.org/jira/browse/IGNITE-12225 > > [4] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > > > пт, 10 янв. 2020 г. в 14:21, Zhenya Stanilovsky > > >: > > > > > > > > Ivan, if i correctly understand, you suggest additional «expiremental» > > > stuff only for hiding already leaked RO interface ? > > > poor approach as for me. > > > > > > >Folks, > > > > > > > >Some thoughts: > > > >* Releasing an API with known fallacies sounds really bad thing to me. > > > >It can have a negative consequences for a whole project for years. My > > > >opinion here that we should resolve the problem with this API somehow > > > >before release. > > > >* We can mark cluster read-only API (without enum) as experimental and > > > >change the API in e.g. 2.8.1. > > > >* We can try to exclude read-only API from 2.8 at all. > > > > > > > >What do you think? > > > > > > > >пт, 10 янв. 2020 г. в 11:20, Alex Plehanov < plehanov.a...@gmail.com > >: > > > >> > > > >> Guys, > > > >> > > > >> There is also an issue with cluster activation by thin clients. This > > > >> feature (.NET thin client API change and protocol change) was added > by > > > [1] > > > >> without any discussion on dev-list. Sergey's patch [2] deprecate > methods > > > >> "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > > > didn't do > > > >> this for thin clients. If we want to include IGNITE-12225 to 2.8 we > also > > > >> should not forget about thin client changes, since it will be > strange > > > if we > > > >> introduce some methods to thin client API and protocol and in the > same > > > >> Ignite version deprecate these methods for servers and thick > clients. > > > >> > > > >> [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > > >> [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > >> > > > >> > > > >> пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky < > > > arzamas...@mail.ru.invalid > > > >> >: > > > >> > > > >> > > > > >> > > > > >> > Agree with Nikolay, -1 from me, too. > > > >> > > > > >> > >Hello, Igniters. > > > >> > > > > > >> > >I’m -1 to include the read-only patch to 2.8. > > > >> > >I think we shouldn’t accept any patches to 2.8 except bug fixes > for > > > >> > blockers and major issues. > > > >> > > > > > >> > >Guys, we don’t release Apache Ignite for 13 months! > > > >> > >We should focus on the release and make it ASAP. > > > >> > > > > > >> > >We can’t extend the scope anymore. > > > >> > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, I created two pull requests [1] [2] for 2.8 release. First of them [1] is a patch with ticket [3] for ignite-2.8 branch. Second [2] is a revert of ticket [4] from 2.8 release. I'm waiting TC run all nightly results for both PRs. I'll write update when TC runs will be ok. I'm okay with both proposals (add ticket [1] to release, remove read-only feature from 2.8 release scope). But I'm not okay with @IgniteExperemental annotation. [1] https://github.com/apache/ignite/pull/7239 [2] https://github.com/apache/ignite/pull/7238 [3] https://issues.apache.org/jira/browse/IGNITE-12225 [4] https://issues.apache.org/jira/browse/IGNITE-11256 пт, 10 янв. 2020 г. в 14:21, Zhenya Stanilovsky : > > Ivan, if i correctly understand, you suggest additional «expiremental» > stuff only for hiding already leaked RO interface ? > poor approach as for me. > > >Folks, > > > >Some thoughts: > >* Releasing an API with known fallacies sounds really bad thing to me. > >It can have a negative consequences for a whole project for years. My > >opinion here that we should resolve the problem with this API somehow > >before release. > >* We can mark cluster read-only API (without enum) as experimental and > >change the API in e.g. 2.8.1. > >* We can try to exclude read-only API from 2.8 at all. > > > >What do you think? > > > >пт, 10 янв. 2020 г. в 11:20, Alex Plehanov < plehanov.a...@gmail.com >: > >> > >> Guys, > >> > >> There is also an issue with cluster activation by thin clients. This > >> feature (.NET thin client API change and protocol change) was added by > [1] > >> without any discussion on dev-list. Sergey's patch [2] deprecate methods > >> "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > didn't do > >> this for thin clients. If we want to include IGNITE-12225 to 2.8 we also > >> should not forget about thin client changes, since it will be strange > if we > >> introduce some methods to thin client API and protocol and in the same > >> Ignite version deprecate these methods for servers and thick clients. > >> > >> [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > >> [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > >> > >> > >> пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky < > arzamas...@mail.ru.invalid > >> >: > >> > >> > > >> > > >> > Agree with Nikolay, -1 from me, too. > >> > > >> > >Hello, Igniters. > >> > > > >> > >I’m -1 to include the read-only patch to 2.8. > >> > >I think we shouldn’t accept any patches to 2.8 except bug fixes for > >> > blockers and major issues. > >> > > > >> > >Guys, we don’t release Apache Ignite for 13 months! > >> > >We should focus on the release and make it ASAP. > >> > > > >> > >We can’t extend the scope anymore. > >> > > > >> > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > antonovserge...@gmail.com > > >> > написал(а): > >> > >> > >> > >> Hello, Maxim! > >> > >> > >> > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > >> > >> changed. > >> > >> Yes, PR is huge, but I wrote a lot of new tests and reworked > already > >> > >> presented. Changes in product code are minimal - only 30 changed > files > >> > in > >> > >> /src/main/ part. And most of them are new control.sh commands and > >> > >> configuration. > >> > >> > >> > >>> Do we have customer requests for this feature or maybe users who > are > >> > >> waiting for exactly that ENUM values exactly in 2.8 release (not > the > >> > 2.8.1 > >> > >> for instance)? > >> > >> Can we introduce in new features in maintanance release (2.8.1)? > Cluster > >> > >> read-only mode will be new feature, if we remove > IgniteCluster#readOnly > >> > in > >> > >> 2.8 release. If all ok with that, lets remove > IgniteCluster#readOnly and > >> > >> move ticket [1] to 2.8.1 release. > >> > >> > >> > >>> Do we have extended test results report (on just only TC.Bot green > >> > visa) > >> > >> on this feature to be sure that we will not add any blocker issues > to > >> > the > >> &g
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, what we do with control.sh commands? We can't set experimental annotation on those commands. пт, 10 янв. 2020 г., 17:47 Alexey Zinoviev : > Support the idea with the annotation > > пт, 10 янв. 2020 г., 13:11 Вячеслав Коптилин : > > > Hello, > > > > * We can mark cluster read-only API (without enum) as experimental and > > > change the API in e.g. 2.8.1. > > > * We can try to exclude read-only API from 2.8 at all. > > > > both approaches look good to me. > > > > By the way, I think it would be a good idea to introduce a new > annotation - > > @IgniteExperimental for instance, > > The package, class or method that is marked by @IgniteExperimental should > > clearly state that this API, class or method can be changed or removed > in a > > future release. > > > > Thanks, > > S. > > > > пт, 10 янв. 2020 г. в 13:02, Ilya Kasnacheev >: > > > > > Hello! > > > > > > I think the third option (exclude publicly-accessible API) is > preferable. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 10 янв. 2020 г. в 12:26, Ivan Pavlukhin : > > > > > > > Folks, > > > > > > > > Some thoughts: > > > > * Releasing an API with known fallacies sounds really bad thing to > me. > > > > It can have a negative consequences for a whole project for years. My > > > > opinion here that we should resolve the problem with this API somehow > > > > before release. > > > > * We can mark cluster read-only API (without enum) as experimental > and > > > > change the API in e.g. 2.8.1. > > > > * We can try to exclude read-only API from 2.8 at all. > > > > > > > > What do you think? > > > > > > > > пт, 10 янв. 2020 г. в 11:20, Alex Plehanov >: > > > > > > > > > > Guys, > > > > > > > > > > There is also an issue with cluster activation by thin clients. > This > > > > > feature (.NET thin client API change and protocol change) was added > > by > > > > [1] > > > > > without any discussion on dev-list. Sergey's patch [2] deprecate > > > methods > > > > > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > > > didn't > > > > do > > > > > this for thin clients. If we want to include IGNITE-12225 to 2.8 we > > > also > > > > > should not forget about thin client changes, since it will be > strange > > > if > > > > we > > > > > introduce some methods to thin client API and protocol and in the > > same > > > > > Ignite version deprecate these methods for servers and thick > clients. > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > > > > > > > > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Agree with Nikolay, -1 from me, too. > > > > > > > > > > > > >Hello, Igniters. > > > > > > > > > > > > > >I’m -1 to include the read-only patch to 2.8. > > > > > > >I think we shouldn’t accept any patches to 2.8 except bug fixes > > for > > > > > > blockers and major issues. > > > > > > > > > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > > > > > >We should focus on the release and make it ASAP. > > > > > > > > > > > > > >We can’t extend the scope anymore. > > > > > > > > > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > > > > antonovserge...@gmail.com > > > > > > > написал(а): > > > > > > >> > > > > > > >> Hello, Maxim! > > > > > > >> > > > > > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 > files > > > > > > >> changed. > > > > > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked > > > already > > > > > > >> presented. Changes in
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello, Maxim! > This PR [2] doesn't look a very simple +5,517 −2,038, 111 files changed. Yes, PR is huge, but I wrote a lot of new tests and reworked already presented. Changes in product code are minimal - only 30 changed files in /src/main/ part. And most of them are new control.sh commands and configuration. > Do we have customer requests for this feature or maybe users who are waiting for exactly that ENUM values exactly in 2.8 release (not the 2.8.1 for instance)? Can we introduce in new features in maintanance release (2.8.1)? Cluster read-only mode will be new feature, if we remove IgniteCluster#readOnly in 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and move ticket [1] to 2.8.1 release. > Do we have extended test results report (on just only TC.Bot green visa) on this feature to be sure that we will not add any blocker issues to the release? I'm preparing patch for 2.8 release and I will get new TC Bot visa vs release branch. [1] https://issues.apache.org/jira/browse/IGNITE-12225 чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov : > Folks, > > > Let me remind you that we are working on the 2.8 release branch > stabilization currently (please, keep it in mind). > > > Do we have a really STRONG reason for adding such a change [1] to the > ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > −2,038, 111 files changed. > Do we have customer requests for this feature or maybe users who are > waiting for exactly that ENUM values exactly in 2.8 release (not the > 2.8.1 for instance)? > Can we just simply remove IgniteCluster#readOnly to eliminate any > backward compatibility issues between 2.8 and 2.9 releases? > Do we have extended test results report (on just only TC.Bot green > visa) on this feature to be sure that we will not add any blocker > issues to the release? For instance, on pre-production environment. > > I'd like to notice that we also have more than enough the release > blocker issues [3] which are still `in progress` and such a release > run becomes endless. Such changes without strong reasons looks too > scary for me a special after scope and code freeze dates. > > Please, dispel my doubts. > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > [2] https://github.com/apache/ignite/pull/7194 > [3] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) > > On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev > wrote: > > > > +1 > > > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov : > > > > > +1 > > > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch > will be > > > at 13 Jan > > > > > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > > > > > > > +1 > > > > > > > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > > > > > > > Maxim M. and anyone who is interested, > > > > > > > > > > I suggest to include this fix to 2.8 release: > > > > > https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > Basically, it's a result of the following discussion: > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > > > > > > > The fix affects public API: IgniteCluster#readOnly methods that > work > > > with > > > > > boolean are replaced with ones that work with enum. > > > > > If we include it, we won't be obliged to keep deprecated boolean > > > version > > > > of > > > > > API in the code (which is currently present in 2.8 branch) as it > wasn't > > > > > published in any release. > > > > > > > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-urideploy: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring: > > > > > > One or more dependencies were identified with known > vulnerabilities > > > in > > > > > > ignite-spring-data: >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
+1 I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch will be at 13 Jan чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin : > +1 > > чт, 9 янв. 2020 г. в 16:38, Ivan Rakov : > > > > Maxim M. and anyone who is interested, > > > > I suggest to include this fix to 2.8 release: > > https://issues.apache.org/jira/browse/IGNITE-12225 > > Basically, it's a result of the following discussion: > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > > > > The fix affects public API: IgniteCluster#readOnly methods that work with > > boolean are replaced with ones that work with enum. > > If we include it, we won't be obliged to keep deprecated boolean version > of > > API in the code (which is currently present in 2.8 branch) as it wasn't > > published in any release. > > > > On Tue, Dec 31, 2019 at 3:54 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > I have ran dependency checker plugin and quote the following: > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-urideploy: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring-data: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-aop: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-visor-console: > > > > > > spring-core-4.3.18.RELEASE.jar > > > (pkg:maven/org.springframework/spring-core@4.3.18.RELEASE, > > > > cpe:2.3:a:pivotal_software:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:springsource:spring_framework:4.3.18.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:vmware:springsource_spring_framework:4.3.18:*:*:*:*:*:*:*) : > > > CVE-2018-15756 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-spring-data_2.0: > > > > > > spring-core-5.0.8.RELEASE.jar > > > (pkg:maven/org.springframework/spring-core@5.0.8.RELEASE, > > > > cpe:2.3:a:pivotal_software:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:springsource:spring_framework:5.0.8.release:*:*:*:*:*:*:*, > > > cpe:2.3:a:vmware:springsource_spring_framework:5.0.8:*:*:*:*:*:*:*) : > > > CVE-2018-15756 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-rest-http: > > > > > > jetty-server-9.4.11.v20180605.jar > > > (pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605, > > > cpe:2.3:a:eclipse:jetty:9.4.11:20180605:*:*:*:*:*:*, > > > cpe:2.3:a:jetty:jetty:9.4.11.v20180605:*:*:*:*:*:*:*, > > > cpe:2.3:a:mortbay_jetty:jetty:9.4.11:20180605:*:*:*:*:*:*) : > > > CVE-2018-12545, CVE-2019-10241, CVE-2019-10247 > > > jackson-databind-2.9.6.jar > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-kubernetes: > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-aws: > > > > > > jackson-databind-2.9.6.jar > > > (pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6, > > > cpe:2.3:a:fasterxml:jackson:2.9.6:*:*:*:*:*:*:*, > > > cpe:2.3:a:fasterxml:jackson-databind:2.9.6:*:*:*:*:*:*:*) : > > > CVE-2018-1000873, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, > > > CVE-2018-14721, CVE-2018-19360, CVE-2018-19361, CVE-2018-19362, > > > CVE-2019-12086, CVE-2019-12384, CVE-2019-12814, CVE-2019-14379, > > > CVE-2019-14439, CVE-2019-14540, CVE-2019-16335, CVE-2019-16942, > > > CVE-2019-16943, CVE-2019-17267, CVE-2019-17531 > > > bcprov-ext-jdk15on-1.54.jar > > > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.54) : CVE-2015-6644, > > > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, CVE-2016-1000341, > > > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, CVE-2016-1000345, > > > CVE-2016-1000346, CVE-2016-1000352, CVE-2016-2427, CVE-2017-13098, > > > CVE-2018-1000180, CVE-2018-1000613 > > > > > > One or more dependencies were identified with known vulnerabilities in > > > ignite-gce: > > > > > > httpclient-4.0.1.jar > (pkg:maven/org.apache.httpcomponents/httpclient@4.0.1 > > > , > > > cpe:2.3:a:apache:httpclient:4.0.1:*:*:*:*:*:*:*) : CVE-2011-1498, > > > CVE-2014-3577, CVE-2015-5262 > > > guava-jdk5-17.0.jar (pkg:maven/com.google.guava/guava-jdk5@17.0, > > > cpe:2.3:a:google:guava:17.0:*:*:*:*:*:*:*) : CVE-2018-10237 > > > >
Re: [MTCGA]: new failures in builds [4898469] needs to be handled
Igniters, I prepared PR with fix [1]. Can someone merge it? [1] https://github.com/apache/ignite/pull/7224/files сб, 4 янв. 2020 г. в 12:08, Sergey Antonov : > Hi! > > I'll fix failures under ticket [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-12520 > > чт, 2 янв. 2020 г. в 15:01, : > >> Hi Igniters, >> >> I've detected some new issue on TeamCity to be handled. You are more >> than welcomed to help. >> >> *New stable failure of a flaky test in master >> GridCommandHandlerClusterByClassTest.testHelp >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails >> >> *New stable failure of a flaky test in master >> GridCommandHandlerClusterByClassTest.testCacheHelp >> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails >> No changes in the build >> >> - Here's a reminder of what contributors were agreed to do >> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute >> - Should you have any questions please contact >> dev@ignite.apache.org >> >> Best Regards, >> Apache Ignite TeamCity Bot >> https://github.com/apache/ignite-teamcity-bot >> Notification generated at 15:01:08 02-01-2020 >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: [MTCGA]: new failures in builds [4898469] needs to be handled
Hi! I'll fix failures under ticket [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12520 чт, 2 янв. 2020 г. в 15:01, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > *New stable failure of a flaky test in master > GridCommandHandlerClusterByClassTest.testHelp > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails > > *New stable failure of a flaky test in master > GridCommandHandlerClusterByClassTest.testCacheHelp > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails > No changes in the build > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 15:01:08 02-01-2020 > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12520) Wrong year in copyright in correct output of control utility.
Sergey Antonov created IGNITE-12520: --- Summary: Wrong year in copyright in correct output of control utility. Key: IGNITE-12520 URL: https://issues.apache.org/jira/browse/IGNITE-12520 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: IGNITE-12356 Migrate Flink module to ignite-extensions
Hi, Saikat! The suite is green now. Thanks! ср, 1 янв. 2020 г. в 00:08, Saikat Maitra : > Hi Sergey, > > I have updated the streamers testsuite. > > > https://ci.ignite.apache.org/viewLog.html?buildId=4897409=IgniteTests24Java8_Streamers > > Regards, > Saikat > > On Tue, Dec 31, 2019 at 2:43 PM Saikat Maitra > wrote: > > > Hello Sergey, > > > > Thank you for your email. Yes, I will update the streamers testsuite. > > > > I had removed flink module from the ignite main repo and I will need to > > update the streamers testsuite to accommodate the change. > > > > Regards, > > Saikat > > > > On Tue, Dec 31, 2019 at 10:39 AM Sergey Antonov < > antonovserge...@gmail.com> > > wrote: > > > >> Hello, Saikat, Ilya. > >> > >> After merge IGNITE-12365 streamers suite is broken in master [1]. Can > your > >> fix it? > >> > >> [1] > >> > >> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Streamers_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv > >> > >> вт, 31 дек. 2019 г. в 18:18, Saikat Maitra : > >> > >> > Hello Ilya, > >> > > >> > Thank you, much appreciate it. > >> > > >> > Regards, > >> > Saikat > >> > > >> > On Tue, 31 Dec 2019 at 3:44 AM, Ilya Kasnacheev < > >> ilya.kasnach...@gmail.com > >> > > > >> > wrote: > >> > > >> > > Hello! > >> > > > >> > > Done! > >> > > > >> > > Regards, > >> > > -- > >> > > Ilya Kasnacheev > >> > > > >> > > > >> > > вт, 31 дек. 2019 г. в 00:16, Saikat Maitra >: > >> > > > >> > > > Hi, > >> > > > > >> > > > I have raised a PR for removal of flink module from ignite main > >> repo. I > >> > > > have already moved flink module in ignite-extensions repo ( > >> > > > https://github.com/apache/ignite-extensions). > >> > > > > >> > > > PR https://github.com/apache/ignite/pull/7222 > >> > > > > >> > > > jira : IGNITE-12356 Migrate Flink module to ignite-extensions > >> > > > > >> > > > https://issues.apache.org/jira/browse/IGNITE-12356 > >> > > > > >> > > > Please review and share feedback. > >> > > > > >> > > > Regards, > >> > > > Saikat > >> > > > > >> > > > >> > > >> > >> > >> -- > >> BR, Sergey Antonov > >> > > > -- BR, Sergey Antonov
Re: IGNITE-12356 Migrate Flink module to ignite-extensions
Hello, Saikat, Ilya. After merge IGNITE-12365 streamers suite is broken in master [1]. Can your fix it? [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Streamers_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv вт, 31 дек. 2019 г. в 18:18, Saikat Maitra : > Hello Ilya, > > Thank you, much appreciate it. > > Regards, > Saikat > > On Tue, 31 Dec 2019 at 3:44 AM, Ilya Kasnacheev > > wrote: > > > Hello! > > > > Done! > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > вт, 31 дек. 2019 г. в 00:16, Saikat Maitra : > > > > > Hi, > > > > > > I have raised a PR for removal of flink module from ignite main repo. I > > > have already moved flink module in ignite-extensions repo ( > > > https://github.com/apache/ignite-extensions). > > > > > > PR https://github.com/apache/ignite/pull/7222 > > > > > > jira : IGNITE-12356 Migrate Flink module to ignite-extensions > > > > > > https://issues.apache.org/jira/browse/IGNITE-12356 > > > > > > Please review and share feedback. > > > > > > Regards, > > > Saikat > > > > > > -- BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
Igniters, ticket[1] in patch available state. Anybody want to review changes? [1] https://issues.apache.org/jira/browse/IGNITE-12225 пн, 25 нояб. 2019 г. в 14:56, Sergey Antonov : > Alexei Scherbakov, > > > After activation (in read-only mode or not) rebalancing is possible to > begin and the grid will not be free of updates until it's finished. So the > grid will not be in truly read-only mode even if cache updates are > prohibited. Probably it would be enough just wait until rebalancing is > finished before releasing future. > I'm afraid, we can't guarantee truly read-only mode due to TTL on cache > entries > > > I do not understand the necessity of handling states comparison on > transition. Why not just return current(previous) state ? Could you give > more detailed explanation for this ? > User could face the unexpected behaviour, If we always return current > state (target state of transition) or previous state (initial state of > transition). For example, transition from INACTIVE to ACTIVE and we return > current state. User gets cluster state (ACTIVE) and tries to get cache, but > activation has not been completed yet. User will get exception, but cluster > state returns ACTIVE value. So, we can't always return current state. > Another example: transition from ACTIVE to READ_ONLY and we return > previous state. User gets cluster state (ACTIVE) and tries to update value > in cache. User could get ClusterReadOnlyModeException in this case. > So we should return state with lower functionality from previous and > current states for avoiding unexpected behaviour. > > > > чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> Sergey Antonov, >> >> > Read-only mode doesn't affects rebalance process. >> After activation (in read-only mode or not) rebalancing is possible to >> begin and the grid will not be free of updates until it's finished. >> So the grid will not be in truly read-only mode even if cache updates are >> prohibited. Probably it would be enough just wait until rebalancing is >> finished before releasing future. >> >> > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> INACTIVE, READ_WRITE, READ_ONLY seems more appropriate for ClusterState. >> >> I do not understand the necessity of handling states comparison on >> transition. Why not just return current(previous) state ? Could you give >> more detailed explanation for this ? >> >> вт, 29 окт. 2019 г. в 14:25, Sergey Antonov : >> >> > He, Igniters! >> > >> > I'd like to share some points encountered during work on ticket [1]: >> > >> >- I added property clusterStateOnStart with type ClusterState to >> >IgniteConfiguration. The property will be analogue of activeOnStart. >> >Default value of the property will be ACTIVE for keeping defalut >> value >> >consistency. Also I marked property activeOnStart as deprecated. >> >- I introduced order on values of ClusterState. It needs for user >> >friendly behaviour during cluster state transition. If cluster is >> > changing >> >state from state_A to state_B and user is requesting current cluster >> >state without waiting end of transition we must return lesser of two >> >states: state_A and state_B. I think the order must be: ACTIVE > >> >READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the >> >users cluster state request during transition): >> > - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) >> > - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) >> > - ACTIVE -> READ_ONLY = READ_ONLY >> > - READ_ONLY -> ACTIVE = READ_ONLY >> > - READ_ONLY -> INACTIVE = INACTIVE >> > - INACTIVE -> READ_ONLY = INACTIVE >> > >> > I'd like to know your opinion about my points. What do you think about >> it? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> > >> > вт, 15 окт. 2019 г. в 14:56, Sergey Antonov > >: >> > >> > > Hi, Alexei! >> > > >> > > Thank you for reply! >> > > >> > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually >> > > read-only cluster is active too. >> > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> > > >> > > > Also it would be useful to allow users wait for re-balance which >> could >> > > happen after activation in read-only mode to
Re: [DISCUSSION] Single point in API for changing cluster state.
Alexei Scherbakov, > After activation (in read-only mode or not) rebalancing is possible to begin and the grid will not be free of updates until it's finished. So the grid will not be in truly read-only mode even if cache updates are prohibited. Probably it would be enough just wait until rebalancing is finished before releasing future. I'm afraid, we can't guarantee truly read-only mode due to TTL on cache entries > I do not understand the necessity of handling states comparison on transition. Why not just return current(previous) state ? Could you give more detailed explanation for this ? User could face the unexpected behaviour, If we always return current state (target state of transition) or previous state (initial state of transition). For example, transition from INACTIVE to ACTIVE and we return current state. User gets cluster state (ACTIVE) and tries to get cache, but activation has not been completed yet. User will get exception, but cluster state returns ACTIVE value. So, we can't always return current state. Another example: transition from ACTIVE to READ_ONLY and we return previous state. User gets cluster state (ACTIVE) and tries to update value in cache. User could get ClusterReadOnlyModeException in this case. So we should return state with lower functionality from previous and current states for avoiding unexpected behaviour. чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov : > Sergey Antonov, > > > Read-only mode doesn't affects rebalance process. > After activation (in read-only mode or not) rebalancing is possible to > begin and the grid will not be free of updates until it's finished. > So the grid will not be in truly read-only mode even if cache updates are > prohibited. Probably it would be enough just wait until rebalancing is > finished before releasing future. > > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? > INACTIVE, READ_WRITE, READ_ONLY seems more appropriate for ClusterState. > > I do not understand the necessity of handling states comparison on > transition. Why not just return current(previous) state ? Could you give > more detailed explanation for this ? > > вт, 29 окт. 2019 г. в 14:25, Sergey Antonov : > > > He, Igniters! > > > > I'd like to share some points encountered during work on ticket [1]: > > > >- I added property clusterStateOnStart with type ClusterState to > >IgniteConfiguration. The property will be analogue of activeOnStart. > >Default value of the property will be ACTIVE for keeping defalut value > >consistency. Also I marked property activeOnStart as deprecated. > >- I introduced order on values of ClusterState. It needs for user > >friendly behaviour during cluster state transition. If cluster is > > changing > >state from state_A to state_B and user is requesting current cluster > >state without waiting end of transition we must return lesser of two > >states: state_A and state_B. I think the order must be: ACTIVE > > >READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the > >users cluster state request during transition): > > - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) > > - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) > > - ACTIVE -> READ_ONLY = READ_ONLY > > - READ_ONLY -> ACTIVE = READ_ONLY > > - READ_ONLY -> INACTIVE = INACTIVE > > - INACTIVE -> READ_ONLY = INACTIVE > > > > I'd like to know your opinion about my points. What do you think about > it? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > вт, 15 окт. 2019 г. в 14:56, Sergey Antonov : > > > > > Hi, Alexei! > > > > > > Thank you for reply! > > > > > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually > > > read-only cluster is active too. > > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? > > > > > > > Also it would be useful to allow users wait for re-balance which > could > > > happen after activation in read-only mode to achieve really idle grid. > > > Read-only mode doesn't affects rebalance process. > > > > > > > I would suggest adding new property to Ignite configuration like > > > setActivationOptions(ActivationOption... options) which should be > mutable > > > in runtime. > > > I'm not sure that it's good idea. @Alexey Goncharuk > > > I'd like to know your opinion about activation > > > option and storing them on PDS. > > > > > > > This proposal also better regarding backward compatibility. > > > Which kind of c
Re: Re[2]: [VOTE] Apache Ignite PMC Chair
+1 Dmitry Pavlov чт, 31 окт. 2019 г. в 13:59, Вячеслав Коптилин : > +1 Dmitry Pavlov > > Thanks, > S. > > чт, 31 окт. 2019 г. в 12:31, Алексей Платонов : > > > +1 for Dmitry Pavlov > > > > чт, 31 окт. 2019 г. в 01:23, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > > > +1 Dmitry Pavlov (binding) > > > > > > On Wed, Oct 30, 2019 at 12:55 PM Alex Plehanov < > plehanov.a...@gmail.com> > > > wrote: > > > > > > > + 1 Dmitry Pavlov > > > > > > > > ср, 30 окт. 2019 г. в 20:50, Pavel Kovalenko : > > > > > > > > > +1 for Dmitry Pavlov > > > > > > > > > > ср, 30 окт. 2019 г. в 18:46, Alexei Scherbakov < > > > > > alexey.scherbak...@gmail.com > > > > > >: > > > > > > > > > > > +1 for Dmitry Pavlov > > > > > > > > > > > > ср, 30 окт. 2019 г. в 18:22, aealexsandrov < > > aealexsand...@gmail.com > > > >: > > > > > > > > > > > > > +1 Alexey Goncharuk > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sent from: > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Best regards, > > > > > > Alexei Scherbakov > > > > > > > > > > > > > > > > > > > > > -- BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
He, Igniters! I'd like to share some points encountered during work on ticket [1]: - I added property clusterStateOnStart with type ClusterState to IgniteConfiguration. The property will be analogue of activeOnStart. Default value of the property will be ACTIVE for keeping defalut value consistency. Also I marked property activeOnStart as deprecated. - I introduced order on values of ClusterState. It needs for user friendly behaviour during cluster state transition. If cluster is changing state from state_A to state_B and user is requesting current cluster state without waiting end of transition we must return lesser of two states: state_A and state_B. I think the order must be: ACTIVE > READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the users cluster state request during transition): - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) - ACTIVE -> READ_ONLY = READ_ONLY - READ_ONLY -> ACTIVE = READ_ONLY - READ_ONLY -> INACTIVE = INACTIVE - INACTIVE -> READ_ONLY = INACTIVE I'd like to know your opinion about my points. What do you think about it? [1] https://issues.apache.org/jira/browse/IGNITE-12225 вт, 15 окт. 2019 г. в 14:56, Sergey Antonov : > Hi, Alexei! > > Thank you for reply! > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually > read-only cluster is active too. > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? > > > Also it would be useful to allow users wait for re-balance which could > happen after activation in read-only mode to achieve really idle grid. > Read-only mode doesn't affects rebalance process. > > > I would suggest adding new property to Ignite configuration like > setActivationOptions(ActivationOption... options) which should be mutable > in runtime. > I'm not sure that it's good idea. @Alexey Goncharuk > I'd like to know your opinion about activation > option and storing them on PDS. > > > This proposal also better regarding backward compatibility. > Which kind of compatibility did you mean? New cluster mode doesn't affects > PDS compatibility. > > ср, 25 сент. 2019 г. в 13:26, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> Sergey Antonov, >> >> The states ACTIVE, INACTIVE, READ-ONLY look confusing. >> Actually read-only cluster is active too. >> >> I would suggest adding new property to Ignite configuration like >> setActivationOptions(ActivationOption... options) which should be mutable >> in runtime. >> >> For control.sh should be the same options for activate command. >> >> Also it would be useful to allow users wait for re-balance which could >> happen after activation in read-only mode to achieve really idle grid. >> >> So, available options list in my opinion: READ_ONLY, WAIT_FOR_REBALANCE. >> >> This proposal also better regarding backward compatibility. >> >> вт, 24 сент. 2019 г. в 20:35, Sergey Antonov : >> >> > Maxim, >> > >> > > I think from the user point the INACTIVE -> READ-ONLY transition [1] >> > should be allowed prior to adding a new `state` command [2] to avoid >> > unnecessary error messages. >> > Yes. I plan complete both tickets till the code freeze of 2.8 release. >> > >> > > I also think we can avoid the word 'set` in this command. >> > I don't think so. We already have command control.sh --state command for >> > getting current state. I think we shouldn't "overload" commands in >> > control.sh. >> > >> > > What about cluster deactivation confirmation? Will it be used for all >> the >> > cluster state changes? >> > Yes. I think we should confirm any cluster state transition. >> > >> > вт, 24 сент. 2019 г. в 19:07, Maxim Muzafarov : >> > >> > > Sergey, >> > > >> > > +1, I like your idea. >> > > >> > > I think from the user point the INACTIVE -> READ-ONLY transition [1] >> > > should be allowed prior to adding a new `state` command [2] to avoid >> > > unnecessary error messages. I also think we can avoid the word 'set` >> > > in this command. >> > > >> > > Example: control.sh --state ACTIVE [--yes] >> > > >> > > >> > > What about cluster deactivation confirmation? Will it be used for all >> > > the cluster state changes? >> > > Deactivate cluster: >> > > control.(sh|bat) --deactivate [--yes] >> > > >> > > >> &g
Re: [DISCUSSION] Single point in API for changing cluster state.
Hi, Alexei! Thank you for reply! > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually read-only cluster is active too. How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? > Also it would be useful to allow users wait for re-balance which could happen after activation in read-only mode to achieve really idle grid. Read-only mode doesn't affects rebalance process. > I would suggest adding new property to Ignite configuration like setActivationOptions(ActivationOption... options) which should be mutable in runtime. I'm not sure that it's good idea. @Alexey Goncharuk I'd like to know your opinion about activation option and storing them on PDS. > This proposal also better regarding backward compatibility. Which kind of compatibility did you mean? New cluster mode doesn't affects PDS compatibility. ср, 25 сент. 2019 г. в 13:26, Alexei Scherbakov < alexey.scherbak...@gmail.com>: > Sergey Antonov, > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. > Actually read-only cluster is active too. > > I would suggest adding new property to Ignite configuration like > setActivationOptions(ActivationOption... options) which should be mutable > in runtime. > > For control.sh should be the same options for activate command. > > Also it would be useful to allow users wait for re-balance which could > happen after activation in read-only mode to achieve really idle grid. > > So, available options list in my opinion: READ_ONLY, WAIT_FOR_REBALANCE. > > This proposal also better regarding backward compatibility. > > вт, 24 сент. 2019 г. в 20:35, Sergey Antonov : > > > Maxim, > > > > > I think from the user point the INACTIVE -> READ-ONLY transition [1] > > should be allowed prior to adding a new `state` command [2] to avoid > > unnecessary error messages. > > Yes. I plan complete both tickets till the code freeze of 2.8 release. > > > > > I also think we can avoid the word 'set` in this command. > > I don't think so. We already have command control.sh --state command for > > getting current state. I think we shouldn't "overload" commands in > > control.sh. > > > > > What about cluster deactivation confirmation? Will it be used for all > the > > cluster state changes? > > Yes. I think we should confirm any cluster state transition. > > > > вт, 24 сент. 2019 г. в 19:07, Maxim Muzafarov : > > > > > Sergey, > > > > > > +1, I like your idea. > > > > > > I think from the user point the INACTIVE -> READ-ONLY transition [1] > > > should be allowed prior to adding a new `state` command [2] to avoid > > > unnecessary error messages. I also think we can avoid the word 'set` > > > in this command. > > > > > > Example: control.sh --state ACTIVE [--yes] > > > > > > > > > What about cluster deactivation confirmation? Will it be used for all > > > the cluster state changes? > > > Deactivate cluster: > > > control.(sh|bat) --deactivate [--yes] > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 > > > [2] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > > > > > > > On Tue, 24 Sep 2019 at 16:50, Sergey Antonov < > antonovserge...@gmail.com> > > > wrote: > > > > > > > > Andrey, > > > > > > > > > What are state transitions valid? > > > > Now all transitions are valid, except INACTIVE -> READ-ONLY. This > > > > transition will be fixed under [1] > > > > > > > > > Regarding state names, as I understand, all transitions are valid > > from > > > > any to any of 3 states. > > > > Yes, see my comment above. > > > > > > > > > But, regarding on console.sh command it is not obvious. > > > > Yes. It's one of points why we should have single command in > > control.sh. > > > > > > > > > What effect will --read-only-on and --read-only-off commands have > if > > > > current state is INACTIVE ? > > > > --read-only-on - cluster will be activated in read-only mode > > > > --read-only-off - cluster will be activated. I.e --read-only-off will > > > have > > > > the same effect as --activate > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11866 > > > > > > > > вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov < > > > andrey.mashen...@gmail.com>: > > > > > > > > > Sergey, > > > > > > > > &g
Re: [DISCUSSION] Single point in API for changing cluster state.
Andrey, > What are state transitions valid? Now all transitions are valid, except INACTIVE -> READ-ONLY. This transition will be fixed under [1] > Regarding state names, as I understand, all transitions are valid from any to any of 3 states. Yes, see my comment above. > But, regarding on console.sh command it is not obvious. Yes. It's one of points why we should have single command in control.sh. > What effect will --read-only-on and --read-only-off commands have if current state is INACTIVE ? --read-only-on - cluster will be activated in read-only mode --read-only-off - cluster will be activated. I.e --read-only-off will have the same effect as --activate [1] https://issues.apache.org/jira/browse/IGNITE-11866 вт, 24 сент. 2019 г. в 16:40, Andrey Mashenkov : > Sergey, > > What are state transitions valid? > For now we have only 2 states (active and inactive) and possible > transitions are obvious Active <--> Inactive. > > Regarding state names, as I understand, all transitions are valid from any > to any of 3 states. > But, regarding on console.sh command it is not obvious. > What effect will --read-only-on and --read-only-off commands have if > current state is INACTIVE ? > > > On Tue, Sep 24, 2019 at 4:23 PM Sergey Antonov > wrote: > > > Also, I would add IGNITE-12225 > > <https://issues.apache.org/jira/browse/IGNITE-12225> ticket to 2.8 > release > > scope. > > > > вт, 24 сент. 2019 г. в 16:18, Sergey Antonov >: > > > > > Hi, Igniters! > > > > > > We have 3 cluster states at the moment: inactive, active, read-only. > > > > > > For getting current cluster state and changing them IgniteCluster has > > > methods: > > > > > >- boolean active(), void active(boolean active) - for cluster > > >activation/deactivation > > >- boolean readOnly(), void readOnly(boolean readOnly) - for > > >enabling/disabling read-only mode. > > > > > > Also we have control.sh commans for changing cluster state: > > > > > >- --activate > > >- --deactivate > > >- --read-only-on > > >- --read-only-off > > > > > > For me current API looks unuseful. My proposal: > > > > > >1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY. > > >2. Add methods to IgniteCluster: > > > - ClusterState state() returns current cluster state > > > - void state(ClusterState newState) changes cluster state to > > > newState state > > >3. Mark as deprecated the following methods in IgniteCluster: > boolean > > >active(), void active(boolean active), > > >4. Add new command to control.sh: control.sh --set-state > > >(ACTIVE|INACTIVE|READ-ONLY) > > >5. Add warn message that command is depricated in control.sh. > > >Commands: --activate, --deactivate, --read-only-on, --read-only-off > > > > > > > > > I created ticket [1] in Jira for it. > > > > > > What do you think about my proposal? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > -- > > > BR, Sergey Antonov > > > > > > > > > -- > > BR, Sergey Antonov > > > > > -- > Best regards, > Andrey V. Mashenkov > -- BR, Sergey Antonov
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
t; > > > > > > > > year? > > > > > > > > > > > > > > > > > > > > > > 3. What do you think about that we will make the huge > 2.8 > > > > > > release in > > > > > > > > > > > November with long period of branch stabilization and > an > > > > > > additional > > > > > > > > > > > 2.8.1 release with ML component in January? Such an > > > > > > approach have some > > > > > > > > > > > advantages like we will not rush the development of ML > > > > > > components. > > > > > > > > > > > > > > > > > > > > > > On Fri, 20 Sep 2019 at 17:24, Alexey Zinoviev < > > > > > > zaleslaw@gmail.com> > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > I wrote about code freeze at December 18, 2019, ok, > we > > > > > > can move one > > > > > > > > > > > > > > > > > > > > week > > > > > > > > > > > > earlier to 11 December > > > > > > > > > > > > Voting + Release could be after 10th January. > > > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 15:43, Maxim Muzafarov < > > > > > > mmu...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > > > > > > > > > It is not a problem to shift release a bit later or > > > > > > earlier, but I'm > > > > > > > > > > > > > strictly against having `code freeze` stage on > > > > > > holidays (the > > > > > > > > > > > > > > > > > > > > Christmas > > > > > > > > > > > > > holidays at the end of December and New Year > holidays > > > > > > at the > > > > > > > > > > > > > > > > > > > > beginning > > > > > > > > > > > > > of January). From my point, it's better to have it > > > > > > completed `code > > > > > > > > > > > > > freeze` stage before December 23th or started after > > > > > > 10th January. > > > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 20 Sep 2019 at 15:09, Dmitriy Pavlov < > > > > > > dpav...@apache.org> > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 For Maxim as release manager. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is a good thing that you have committer > rights, > > > > > > and most of > > > > > > > > > > > > > > > > > > > > the steps > > > > > > > > > > > > > > you will be able to complete yourself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > But please engage one from PMC member to complete > > > > > > steps from the > > > > > > > > > > > > > > > > > > > > release > > > > > > > > > > > > > > process where PMC rights are required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process At > > > > > > > > > > > > > > least, access to docker and nuget creds requires > PMC > > > > > > membership. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feel free to ping me, I will assist, as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 14:59, Alexey Zinoviev < > > > > > > > > > > > > > > > > > > > > zaleslaw@gmail.com>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For Spark and ML components the best dates > should > > > > > > be moved to > > > > > > > > > > > > > > > > > > > > one month > > > > > > > > > > > > > > > later, what's about? > > > > > > > > > > > > > > > There are a lot of features there, but a lot of > > > > > > bugs and minor > > > > > > > > > > > > > > > improvements in JIRA too > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also I support you as a release manager > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scope Freeze: December 4, 2019 > > > > > > > > > > > > > > > Code Freeze: December 18, 2019 > > > > > > > > > > > > > > > Voting Date: January 10, 2019 > > > > > > > > > > > > > > > Release Date: January 17, 2019 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 14:44, Maxim Muzafarov < > > > > > > > > > > > > > > > > > > > > mmu...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's almost a year has passed since the last > > > > > > major Apache > > > > > > > > > > > > > > > > > > > > Ignite 2.7 > > > > > > > > > > > > > > > > has been released. We've accumulated a lot of > > > > > > performance > > > > > > > > > > > > > > > > > > > > > > > > > > improvements > > > > > > > > > > > > > > > > and a lot of new features which are waiting > for > > > > > > their release > > > > > > > > > > > > > > > > > > > > date. > > > > > > > > > > > > > > > > Here is my list of the most interesting > things > > > > > > from my point > > > > > > > > > > > > > > > > > > > > since > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > last major release: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Service Grid, > > > > > > > > > > > > > > > > Monitoring, > > > > > > > > > > > > > > > > Recovery Read > > > > > > > > > > > > > > > > BLT auto-adjust, > > > > > > > > > > > > > > > > PDS compression, > > > > > > > > > > > > > > > > WAL page compression, > > > > > > > > > > > > > > > > Thin client: best effort affinity, > > > > > > > > > > > > > > > > Thin client: transactions support (not yet) > > > > > > > > > > > > > > > > SQL query history > > > > > > > > > > > > > > > > SQL statistics > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think we should no longer wait and freeze > the > > > > > > master branch > > > > > > > > > > > > > > > > > > > > anymore > > > > > > > > > > > > > > > > and prepare the next major release by the > end of > > > > > > the year. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose to discuss Time, Scope of Apache > > > > > > Ignite 2.8 release > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > also > > > > > > > > > > > > > > > > I want to propose myself to be the release > > > > > > manager of the > > > > > > > > > > > > > > > > > > > > planning > > > > > > > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scope Freeze: November 4, 2019 > > > > > > > > > > > > > > > > Code Freeze: November 18, 2019 > > > > > > > > > > > > > > > > Voting Date: December 10, 2019 > > > > > > > > > > > > > > > > Release Date: December 17, 2019 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > > -- BR, Sergey Antonov
Re: [DISCUSSION] Single point in API for changing cluster state.
Also, I would add IGNITE-12225 <https://issues.apache.org/jira/browse/IGNITE-12225> ticket to 2.8 release scope. вт, 24 сент. 2019 г. в 16:18, Sergey Antonov : > Hi, Igniters! > > We have 3 cluster states at the moment: inactive, active, read-only. > > For getting current cluster state and changing them IgniteCluster has > methods: > >- boolean active(), void active(boolean active) - for cluster >activation/deactivation >- boolean readOnly(), void readOnly(boolean readOnly) - for >enabling/disabling read-only mode. > > Also we have control.sh commans for changing cluster state: > >- --activate >- --deactivate >- --read-only-on >- --read-only-off > > For me current API looks unuseful. My proposal: > >1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY. >2. Add methods to IgniteCluster: > - ClusterState state() returns current cluster state > - void state(ClusterState newState) changes cluster state to > newState state >3. Mark as deprecated the following methods in IgniteCluster: boolean >active(), void active(boolean active), >4. Add new command to control.sh: control.sh --set-state >(ACTIVE|INACTIVE|READ-ONLY) >5. Add warn message that command is depricated in control.sh. >Commands: --activate, --deactivate, --read-only-on, --read-only-off > > > I created ticket [1] in Jira for it. > > What do you think about my proposal? > > [1] https://issues.apache.org/jira/browse/IGNITE-12225 > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
[DISCUSSION] Single point in API for changing cluster state.
Hi, Igniters! We have 3 cluster states at the moment: inactive, active, read-only. For getting current cluster state and changing them IgniteCluster has methods: - boolean active(), void active(boolean active) - for cluster activation/deactivation - boolean readOnly(), void readOnly(boolean readOnly) - for enabling/disabling read-only mode. Also we have control.sh commans for changing cluster state: - --activate - --deactivate - --read-only-on - --read-only-off For me current API looks unuseful. My proposal: 1. Create enum ClusterState with values ACTIVE, INACTIVE, READ-ONLY. 2. Add methods to IgniteCluster: - ClusterState state() returns current cluster state - void state(ClusterState newState) changes cluster state to newState state 3. Mark as deprecated the following methods in IgniteCluster: boolean active(), void active(boolean active), 4. Add new command to control.sh: control.sh --set-state (ACTIVE|INACTIVE|READ-ONLY) 5. Add warn message that command is depricated in control.sh. Commands: --activate, --deactivate, --read-only-on, --read-only-off I created ticket [1] in Jira for it. What do you think about my proposal? [1] https://issues.apache.org/jira/browse/IGNITE-12225 -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12225) Add enum for cluster state
Sergey Antonov created IGNITE-12225:
---
Summary: Add enum for cluster state
Key: IGNITE-12225
URL: https://issues.apache.org/jira/browse/IGNITE-12225
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
## Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
## Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
## Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12153) Control.sh add test for checking that help and cache help output are not broken.
Sergey Antonov created IGNITE-12153: --- Summary: Control.sh add test for checking that help and cache help output are not broken. Key: IGNITE-12153 URL: https://issues.apache.org/jira/browse/IGNITE-12153 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.8 We should store "ideal" outputs in resorces and compare with current. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12136) Test ClusterReadOnlyModeTest is flaky.
Sergey Antonov created IGNITE-12136: --- Summary: Test ClusterReadOnlyModeTest is flaky. Key: IGNITE-12136 URL: https://issues.apache.org/jira/browse/IGNITE-12136 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.8 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4535823271211432266=testDetails_IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12125) Concurrency problem in PagesWriteThrottle
Sergey Antonov created IGNITE-12125:
---
Summary: Concurrency problem in PagesWriteThrottle
Key: IGNITE-12125
URL: https://issues.apache.org/jira/browse/IGNITE-12125
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
In IGNITE-12006 and IGNITE-9231 were added code:
{code}
parkThrds.forEach(LockSupport::unpark);
parkThrds.clear();
{code}
This code isn't thread-safe. We should remove from {{parkThrds}} only unparked
threads.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
Re: Control.sh usability & possible bugs
t help usability > >> > >> Example of output: > >> > >> Activate cluster: > >> > >> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] > [--password > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] > >> --activate > >> > >>Deactivate cluster: > >> > >> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] > [--password > >> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT] > >> --deactivate [--yes] > >> > >> ... > >> > >> Why do we repeat tons of parameters each time? Is it better for users to > >> enlist options and commands separately? > >> > >> control.sh [options] command > >> > >> and then enlist options > >> > >> [--host HOST_OR_IP] > >> > >> [--port PORT] > >> > >> [--user USER] > >> > >> [--password PASSWORD] > >> > >> [--ping-interval PING_INTERVAL] > >> > >> [--ping-timeout PING_TIMEOUT] > >> > >> and describe several commands we have? > >> > >> In coding WET is not the best solution. So maybe we could DRY in our > help, > >> should we? > >> > >> Artem Boudnikov, could you evaluate this idea? > >> > >> Sincerely, > >> Dmitriy Pavlov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12052) GridDhtTxPrepareFuture should print transaction in case of assertion error
Sergey Antonov created IGNITE-12052:
---
Summary: GridDhtTxPrepareFuture should print transaction in case
of assertion error
Key: IGNITE-12052
URL: https://issues.apache.org/jira/browse/IGNITE-12052
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
At the moment we getting exception, if assertion error occurs:
{noformat}
2019-07-13
20:23:00.769[ERROR][srvc-deploy-#299%xxx_GRID%xxxGridNodeName%][o.a.i.i.p.s.GridServiceProcessor]
Error when executing service: null
java.lang.AssertionError: Got removed exception on entry with dht local
candidate: IgniteTxEntry []
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.sendPrepareRequests(GridDhtTxPrepareFuture.java:1368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1276)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:704)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:699)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:153)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:69)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:276)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.init(GridDhtForceKeysFuture.java:217)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:523)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:521)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture.onDone(GridAffinityAssignmentCache.java:850)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture.onDone(GridAffinityAssignmentCache.java:834)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451
Re: {DISCUSSION] Cluster read-only mode.
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 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. Please, check my reproducer [1]. CacheException > is not thrown. Am I missing something? > > [1] > https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72 > > On Tue, 4 Jun 2019 at 14:42, Sergey Antonov > wrote: > > > > 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. Cluster exchange guarantees update consistency > > between primary and backups. > > > > >> We should cancel the DataStreamer task or allow it to be finished. > > 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() > > > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov : > > > > > 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 such tests in your PR. > > > > > > I've downloaded your branch and run some tests locally. I've tried > > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent > > > cluster change state request to read-only mode and I've got strange > > > behaviour. My test scenario was: > > > 1) Start DataStremer cache load; > > > 2) change cluster to read-only state; > > > 3) change state back to normal; > > > > > > When the state has been changed to `read-only` I've flooded with a lot > > > of `Failed to perform cache operation (cluster is in read-only mode)` > > > errors, but when I've reverted the state back the DataStreamer > > > continue its load without any error. I think we should not allow such > > > behaviour. We should cancel the DataStreamer task or allow it to be > > > finished. > > > > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov < > antonovserge...@gmail.com> > > > wrote: > > > > > > > > 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-cache updates still be > available ? > > > > ignite-sys-cache is using in the different subcomponents, for > example, > > > > security. > > > > > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky > > > : > > > > > > > > > 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 ClusterReadOnlyModeCheckedException. This feature could be > > > helpfull > > > > > > for maintenance works (control.sh idle_verify/validate_indexes). > > > > > > > > > > > > A few points about cluster read-only mode: > > > > > > 1) Read-only mode could be enabled on active cluster only. > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster > restart > > > > > > enabled > > > > > > read-only mode will be forgotten) > > > > > > 3) Updates to ignite-sys-cache will be available with enabled > > > read-only > > > > > > mode. > > > > > > > > > > > > More informartion about implementation you could find in PR [2]. > > > > > > > > > > > > What do you think about this feature? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > > > [2] https://github.com/apache/ignite/pull/6423 > > > > > > > > > > > > > > > > > -- > > > > BR, Sergey Antonov > > > > > > > > > -- > > BR, Sergey Antonov > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-12006) Threads may be parked for indefinite time during throttling after spurious wakeups
Sergey Antonov created IGNITE-12006:
---
Summary: Threads may be parked for indefinite time during
throttling after spurious wakeups
Key: IGNITE-12006
URL: https://issues.apache.org/jira/browse/IGNITE-12006
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
In the log we see the following behavior:
{noformat}
2019-07-04 06:29:03.649[WARN
][sys-#328%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#328%NODE%xyzGridNodeName% for timeout(ms)=16335
2019-07-04 06:29:03.649[WARN
][sys-#326%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#326%NODE%xyzGridNodeName% for timeout(ms)=13438
2019-07-04 06:29:03.649[WARN
][sys-#277%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#277%NODE%xyzGridNodeName% for timeout(ms)=11609
2019-07-04 06:29:03.649[WARN
][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=18009
2019-07-04 06:29:03.649[WARN
][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=15557
2019-07-04 06:29:03.650[WARN
][sys-#307%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#307%NODE%xyzGridNodeName% for timeout(ms)=27938
2019-07-04 06:29:03.649[WARN
][sys-#316%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#316%NODE%xyzGridNodeName% for timeout(ms)=12189
2019-07-04 06:29:03.649[WARN
][sys-#311%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#311%NODE%xyzGridNodeName% for timeout(ms)=11056
2019-07-04 06:29:03.650[WARN
][sys-#295%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#295%NODE%xyzGridNodeName% for timeout(ms)=20848
2019-07-04 06:29:03.649[WARN
][sys-#290%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#290%NODE%xyzGridNodeName% for timeout(ms)=14816
2019-07-04 06:29:03.649[WARN
][sys-#332%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#332%NODE%xyzGridNodeName% for timeout(ms)=14110
2019-07-04 06:29:03.649[WARN
][sys-#298%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#298%NODE%xyzGridNodeName% for timeout(ms)=10028
2019-07-04 06:29:03.650[WARN
][sys-#304%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#304%NODE%xyzGridNodeName% for timeout(ms)=19855
2019-07-04 06:29:03.650[WARN
][sys-#331%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#331%NODE%xyzGridNodeName% for timeout(ms)=41277
2019-07-04 06:29:03.650[WARN
][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=17151
2019-07-04 06:29:03.650[WARN
][sys-#308%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#308%NODE%xyzGridNodeName% for timeout(ms)=39312
2019-07-04 06:29:03.650[WARN
][sys-#322%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#322%NODE%xyzGridNodeName% for timeout(ms)=43341
2019-07-04 06:29:03.650[WARN
][sys-#306%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#306%NODE%xyzGridNodeName% for timeout(ms)=21890
2019-07-04 06:29:03.650[WARN
][sys-#315%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#315%NODE%xyzGridNodeName% for timeout(ms)=18909
2019-07-04 06:29:03.650[WARN
][sys-#321%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#321%NODE%xyzGridNodeName% for timeout(ms)=74129
2019-07-04 06:29:03.650[WARN
][sys-#305%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#305%NODE%xyzGridNodeName% for timeout(ms)=26608
2019-07-04 06:29:03.650[WARN
][sys-#309%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#309%NODE%xyzGridNodeName% for timeout(ms)=77835
2019-07-04 06:29:03.650[WARN
][sys-#291%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#291%NODE%xyzGridNodeName% for timeout(ms)=90104
2019-07-04 06:29:03.650[WARN
][sys-#325%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#325%NODE%xyzGridNodeName% for timeout(ms)=85813
2019-07-04 06:29:03.650[WARN
][sys-#314%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#314%NODE%xyzGridNodeName% for timeout(ms)=81727
2019-07-04 06:29:03.650[WARN
][sys-#338%NODE%xyzGridNodeName%][o.a.i.i.p.c.p.pagemem.PageMemoryImpl] Parking
thread=sys-#338%NODE%xyzGridNodeName% for timeout(ms)=99340
2019-07-04 06:29:03.650[WARN
][sys-#332%NODE%xyzGridNodeName
Re: {DISCUSSION] Cluster read-only mode.
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#testDataStreamerReadOnly() > > In this test, DataStreamer starts when the cluster already changes its > mode, but not before. Please, check my reproducer [1]. CacheException > is not thrown. Am I missing something? > > [1] > https://github.com/Mmuzaf/ignite/blob/readonly_streamer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/ClusterReadOnlyModeTest.java#L72 > > On Tue, 4 Jun 2019 at 14:42, Sergey Antonov > wrote: > > > > 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. Cluster exchange guarantees update consistency > > between primary and backups. > > > > >> We should cancel the DataStreamer task or allow it to be finished. > > 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() > > > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov : > > > > > 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 such tests in your PR. > > > > > > I've downloaded your branch and run some tests locally. I've tried > > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent > > > cluster change state request to read-only mode and I've got strange > > > behaviour. My test scenario was: > > > 1) Start DataStremer cache load; > > > 2) change cluster to read-only state; > > > 3) change state back to normal; > > > > > > When the state has been changed to `read-only` I've flooded with a lot > > > of `Failed to perform cache operation (cluster is in read-only mode)` > > > errors, but when I've reverted the state back the DataStreamer > > > continue its load without any error. I think we should not allow such > > > behaviour. We should cancel the DataStreamer task or allow it to be > > > finished. > > > > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov < > antonovserge...@gmail.com> > > > wrote: > > > > > > > > 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-cache updates still be > available ? > > > > ignite-sys-cache is using in the different subcomponents, for > example, > > > > security. > > > > > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky > > > : > > > > > > > > > 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 ClusterReadOnlyModeCheckedException. This feature could be > > > helpfull > > > > > > for maintenance works (control.sh idle_verify/validate_indexes). > > > > > > > > > > > > A few points about cluster read-only mode: > > > > > > 1) Read-only mode could be enabled on active cluster only. > > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster > restart > > > > > > enabled > > > > > > read-only mode will be forgotten) > > > > > > 3) Updates to ignite-sys-cache will be available with enabled > > > read-only > > > > > > mode. > > > > > > > > > > > > More informartion about implementation you could find in PR [2]. > > > > > > > > > > > > What do you think about this feature? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > > > [2] https://github.com/apache/ignite/pull/6423 > > > > > > > > > > > > > > > > > -- > > > > BR, Sergey Antonov > > > > > > > > > -- > > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: {DISCUSSION] Cluster read-only mode.
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. Cluster exchange guarantees update consistency between primary and backups. >> We should cancel the DataStreamer task or allow it to be finished. 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() пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov : > 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 such tests in your PR. > > I've downloaded your branch and run some tests locally. I've tried > DataStreamer cache loads (allowOverwrite mode false) with a concurrent > cluster change state request to read-only mode and I've got strange > behaviour. My test scenario was: > 1) Start DataStremer cache load; > 2) change cluster to read-only state; > 3) change state back to normal; > > When the state has been changed to `read-only` I've flooded with a lot > of `Failed to perform cache operation (cluster is in read-only mode)` > errors, but when I've reverted the state back the DataStreamer > continue its load without any error. I think we should not allow such > behaviour. We should cancel the DataStreamer task or allow it to be > finished. > > On Fri, 31 May 2019 at 13:00, Sergey Antonov > wrote: > > > > 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-cache updates still be available ? > > ignite-sys-cache is using in the different subcomponents, for example, > > security. > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky > : > > > > > 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 ClusterReadOnlyModeCheckedException. This feature could be > helpfull > > > > for maintenance works (control.sh idle_verify/validate_indexes). > > > > > > > > A few points about cluster read-only mode: > > > > 1) Read-only mode could be enabled on active cluster only. > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart > > > > enabled > > > > read-only mode will be forgotten) > > > > 3) Updates to ignite-sys-cache will be available with enabled > read-only > > > > mode. > > > > > > > > More informartion about implementation you could find in PR [2]. > > > > > > > > What do you think about this feature? > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > [2] https://github.com/apache/ignite/pull/6423 > > > > > > > > > -- > > BR, Sergey Antonov > -- BR, Sergey Antonov
Re: {DISCUSSION] Cluster read-only mode.
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 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 two modes into one? If not we will need a > clear explanation for a user. > > пн, 3 июн. 2019 г. в 20:15, Maxim Muzafarov : > > > > 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 such tests in your PR. > > > > I've downloaded your branch and run some tests locally. I've tried > > DataStreamer cache loads (allowOverwrite mode false) with a concurrent > > cluster change state request to read-only mode and I've got strange > > behaviour. My test scenario was: > > 1) Start DataStremer cache load; > > 2) change cluster to read-only state; > > 3) change state back to normal; > > > > When the state has been changed to `read-only` I've flooded with a lot > > of `Failed to perform cache operation (cluster is in read-only mode)` > > errors, but when I've reverted the state back the DataStreamer > > continue its load without any error. I think we should not allow such > > behaviour. We should cancel the DataStreamer task or allow it to be > > finished. > > > > On Fri, 31 May 2019 at 13:00, Sergey Antonov > wrote: > > > > > > 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-cache updates still be available ? > > > ignite-sys-cache is using in the different subcomponents, for example, > > > security. > > > > > > чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky > : > > > > > > > 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 ClusterReadOnlyModeCheckedException. This feature could be > helpfull > > > > > for maintenance works (control.sh idle_verify/validate_indexes). > > > > > > > > > > A few points about cluster read-only mode: > > > > > 1) Read-only mode could be enabled on active cluster only. > > > > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart > > > > > enabled > > > > > read-only mode will be forgotten) > > > > > 3) Updates to ignite-sys-cache will be available with enabled > read-only > > > > > mode. > > > > > > > > > > More informartion about implementation you could find in PR [2]. > > > > > > > > > > What do you think about this feature? > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > > > > [2] https://github.com/apache/ignite/pull/6423 > > > > > > > > > > > > > -- > > > BR, Sergey Antonov > > > > -- > Best regards, > Ivan Pavlukhin > -- BR, Sergey Antonov
[jira] [Created] (IGNITE-11889) Add security permissions cluster state change operations
Sergey Antonov created IGNITE-11889: --- Summary: Add security permissions cluster state change operations Key: IGNITE-11889 URL: https://issues.apache.org/jira/browse/IGNITE-11889 Project: Ignite Issue Type: Bug Components: security Reporter: Sergey Antonov We should add security permissions for cluster state change operations: * Cluster activation/deactivation. * Set/change baseline topology. * Enable/disable read-only mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: {DISCUSSION] Cluster read-only mode.
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-cache updates still be available ? ignite-sys-cache is using in the different subcomponents, for example, security. чт, 30 мая 2019 г. в 20:30, Zhenya Stanilovsky : > 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 ClusterReadOnlyModeCheckedException. This feature could be helpfull > > for maintenance works (control.sh idle_verify/validate_indexes). > > > > A few points about cluster read-only mode: > > 1) Read-only mode could be enabled on active cluster only. > > 2) Read-only mode doens't store on PDS (i.e. after cluster restart > > enabled > > read-only mode will be forgotten) > > 3) Updates to ignite-sys-cache will be available with enabled read-only > > mode. > > > > More informartion about implementation you could find in PR [2]. > > > > What do you think about this feature? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11256 > > [2] https://github.com/apache/ignite/pull/6423 > -- BR, Sergey Antonov
{DISCUSSION] Cluster read-only mode.
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 (control.sh idle_verify/validate_indexes). A few points about cluster read-only mode: 1) Read-only mode could be enabled on active cluster only. 2) Read-only mode doens't store on PDS (i.e. after cluster restart enabled read-only mode will be forgotten) 3) Updates to ignite-sys-cache will be available with enabled read-only mode. More informartion about implementation you could find in PR [2]. What do you think about this feature? [1] https://issues.apache.org/jira/browse/IGNITE-11256 [2] https://github.com/apache/ignite/pull/6423 -- BR, Sergey Antonov
[jira] [Created] (IGNITE-11876) control.sh idle verify --cache-filter doesn't work without --dump option
Sergey Antonov created IGNITE-11876:
---
Summary: control.sh idle verify --cache-filter doesn't work
without --dump option
Key: IGNITE-11876
URL: https://issues.apache.org/jira/browse/IGNITE-11876
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
At this moment control.sh {{--cache idle_verify --cache-filter PERSISTENT}}
doesn't work (see {{VerifyBackupPartitionsTaskV2#isCacheMatchFilter()}}). We
should fix it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11866) Add ability to activate cluster in read-only mode
Sergey Antonov created IGNITE-11866: --- Summary: Add ability to activate cluster in read-only mode Key: IGNITE-11866 URL: https://issues.apache.org/jira/browse/IGNITE-11866 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov After IGNITE-11256 we have cluster read-only mode. We should have ability to activate cluster and enable read-only mode like atomic operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11863) .NET: Add clurster read-only mode API (status, run-time change)
Sergey Antonov created IGNITE-11863: --- Summary: .NET: Add clurster read-only mode API (status, run-time change) Key: IGNITE-11863 URL: https://issues.apache.org/jira/browse/IGNITE-11863 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Sergey Antonov We would introduce at IGNITE-11256 new methods in IgniteCluster. We need their support in .Net side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11859) CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
Sergey Antonov created IGNITE-11859:
---
Summary:
CommandHandlerParsingTest#testExperimentalCommandIsDisabled() don't works
Key: IGNITE-11859
URL: https://issues.apache.org/jira/browse/IGNITE-11859
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Fix For: 2.8
{{parseArgs(Arrays.asList(WAL.text(), WAL_PRINT));}} and
{{parseArgs(Arrays.asList(WAL.text(), WAL_DELETE));}} should throw
IllegalArgumentException, but it isn't.
h2. How to reproduce:
Replace test to:
{code:java}
/**
* Test that experimental command (i.e. WAL command) is disabled by default.
*/
@Test
public void testExperimentalCommandIsDisabled() {
System.clearProperty(IGNITE_ENABLE_EXPERIMENTAL_COMMAND);
GridTestUtils.assertThrows(null,
()->parseArgs(Arrays.asList(WAL.text(), WAL_PRINT)),
IllegalArgumentException.class, null);
GridTestUtils.assertThrows(null,
()->parseArgs(Arrays.asList(WAL.text(), WAL_DELETE)),
IllegalArgumentException.class, null);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11814) Log finish rebuilding all indexes
Sergey Antonov created IGNITE-11814:
---
Summary: Log finish rebuilding all indexes
Key: IGNITE-11814
URL: https://issues.apache.org/jira/browse/IGNITE-11814
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
For detecting finish of rebuilding all indexes we should find in logs all
messages:
1) {{Started indexes rebuilding for cache [name=}}
2) {{Finished indexes rebuilding for cache [name=}}
3) {{Failed to rebuild indexes for cache [name=}}
And check, that number of messages (1) equal sum of number of messages (2) and
(3).
We should log message about finish rebuilding indexes for all caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11812) control.sh ignores quotes in passed arguments
Sergey Antonov created IGNITE-11812:
---
Summary: control.sh ignores quotes in passed arguments
Key: IGNITE-11812
URL: https://issues.apache.org/jira/browse/IGNITE-11812
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Fix For: 2.8
Control.sh should consider quotes in incoming arguments. i.e. I expect that
{{control.sh --baseline set "p1,p2,p3","p4,p5,p6" --yes}} set BLT with two
nodes with consistent ids: {{p1,p2,p3}} and {{p4,p5,p6}}, but now it tries to
set BLT with six nodes {{p1}}, {{p2}}, {{p3}}, {{p4}}, {{p5}}, {{p6}}
Reproducer. (Add this test to {{CommandHandlerParsingTest}})
{code:java}
@Test
public void testQuotesWillNotIgnored() throws Exception {
CommandHandler hnd = new CommandHandler();
Arguments args = hnd.parseAndValidate(
Arrays.asList(
BASELINE.text(),
BaselineCommand.SET.text(),
"\"1,2,3\",\"3,2,1\""
)
);
assertEquals(BASELINE, args.command());
assertEquals(BaselineCommand.SET, args.baselineArguments().getCmd());
// FIx me: expected 2, actual 6
assertEquals(2, args.baselineArguments().getConsistentIds().size());
assertEquals("1,2,3",
args.baselineArguments().getConsistentIds().get(0));
assertEquals("3,2,1",
args.baselineArguments().getConsistentIds().get(1));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11809) Missing help for control.sh --baseline collect command.
Sergey Antonov created IGNITE-11809:
---
Summary: Missing help for control.sh --baseline collect command.
Key: IGNITE-11809
URL: https://issues.apache.org/jira/browse/IGNITE-11809
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
I found enum value {{BaselineCommand#COLLECT}}, but I don't see this option in
help output. We should add example with {{BaselineCommand#COLLECT}} to
{{control.sh --help output}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11795) JDBC thin datastreamer don't throws exception is case of problems on closing streamer.
Sergey Antonov created IGNITE-11795: --- Summary: JDBC thin datastreamer don't throws exception is case of problems on closing streamer. Key: IGNITE-11795 URL: https://issues.apache.org/jira/browse/IGNITE-11795 Project: Ignite Issue Type: Bug Components: jdbc, thin client Reporter: Sergey Antonov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11784) Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Sergey Antonov created IGNITE-11784:
---
Summary: Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Key: IGNITE-11784
URL: https://issues.apache.org/jira/browse/IGNITE-11784
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Fix For: 2.8
{{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}} have
TcpDiscoveryNode filed. TcpDiscoveryNode could be huge object due to node
attributes. We could sent only nodeId and get TcpDiscoveryNode from DiscoCache
on target node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11753) control.sh improve error message in case of connection to secured cluster without credentials.
Sergey Antonov created IGNITE-11753:
---
Summary: control.sh improve error message in case of connection to
secured cluster without credentials.
Key: IGNITE-11753
URL: https://issues.apache.org/jira/browse/IGNITE-11753
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
If control.sh tries to connect to secured cluster without login/password now we
got:
{noformat}
./control.sh --state
Failed to get cluster state.
Authentication error, try connection again.
user:
{noformat}
We should print info about attempt to connect to secured cluster and request
login/password if it isn't set. I.e.
{noformat}
./control.sh --state
Failed to get cluster state.
Cluster required authentication.
user:
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11719) Document cluster read-only mode
Sergey Antonov created IGNITE-11719: --- Summary: Document cluster read-only mode Key: IGNITE-11719 URL: https://issues.apache.org/jira/browse/IGNITE-11719 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Assignee: Artem Budnikov Fix For: 2.8 We should document cluster wide read-only mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
