Re: [ANNOUNCE] 4 December 2019, the 2.8 RELEASE brach creation
Thank for the leading release, Maxim. Keep going! > 4 дек. 2019 г., в 20:29, Alexey Zinoviev написал(а): > > Great, many thanks to your job > > ср, 4 дек. 2019 г., 19:05 Maxim Muzafarov : > >> Igniters, >> >> >> 1. The release branch created: ignite-2.8 >> 2. The list of unresolved issues [1] related to the 2.8 release has >> been cleaned up (only Blocker and Critical issues left). >> 3. Apache Ignite 2.8 wiki page has been updated [2]. >> 4. The issue [3] with Corrupted B+ tree exception has been reverted >> from the master branch. Discussed [4] [5]. >> >> >> If you are working on issues related to 2.8 release, please, don't forget >> to: >> 1. Discuss them on dev-list (To make the release branch stable we need >> to eliminate risks of any such issues) >> 2. Merge them to both branches master and ignite-2.8. >> >> >> [1] >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) >> [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8 >> [3] https://issues.apache.org/jira/browse/IGNITE-11704 >> [4] >> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44539.html >> [5] >> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44551.html >> >> On Fri, 29 Nov 2019 at 12:52, Alexey Zinoviev >> wrote: >>> >>> Is it ok for me, but please move IGFS dropping ticket to the next >> release, >>> I have no capacity to finish in time the blocker ticket related to >>> Tensorflow-Ignite integration and as a result we shouldn't remove the >> IGFS >>> yet but please mark it as a deprecated and ready for removal in 3.0 >>> >>> чт, 28 нояб. 2019 г. в 16:03, Maxim Muzafarov : >>> Denis, What kind of additional checks do we need? Maybe I'm missing something but all issues currently merged to the master branch will be present in the 2.8 release branch too. I see that this issue has been closed a long time ago, so it definitely comes in. On Thu, 28 Nov 2019 at 01:33, Denis Magda wrote: > > Hi Maxim, > > Sounds good, thanks for branching. Could you double-check that the > following issue was added to the release? > https://issues.apache.org/jira/browse/IGNITE-10577 > > - > Denis > > > On Wed, Nov 27, 2019 at 7:50 AM Maxim Muzafarov wrote: > >> Igniters, >> >> >> I think we are ready to create the 2.8 release branch since >> features >> [1] which we are waiting for are almost completed. >> >> 4 December 2019, the 2.8 release branch will be created. All >> related >> issues with a priority less than `critical` will be excluded from >> the >> 2.8 release (fix version will be changed to 2.9). >> >> >> Any objections? >> >> >> [1] >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Awatingfeaturescompletion >> >>
[jira] [Created] (IGNITE-12418) Add documentation for Sql default query timeout
Saikat Maitra created IGNITE-12418: -- Summary: Add documentation for Sql default query timeout Key: IGNITE-12418 URL: https://issues.apache.org/jira/browse/IGNITE-12418 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Saikat Maitra -- This message was sent by Atlassian Jira (v8.3.4#803005)
Ignite Evolution Direction: short questionary
Folks, There are many ongoing conversations and activities on the list related to Ignite's evolution (modularization, 3.0, full-text search support, etc.). I'm suggesting to ask our broader user community to contribute by sharing short feedback and discuss results in several weeks: https://docs.google.com/forms/d/e/1FAIpQLSdUveEVXer3lpkyiqfFw4175TvZzGHUOS4snPfnkO0NDku0eQ/viewform Ultimately, the project is being developed for the purpose and it will be right to hear back from those who put Ignite in prod. Please check the questionary and suggest any changes. It should be short and compact. We'll send it to the user list and can publish it on the Ignite website. - Denis
[jira] [Created] (IGNITE-12417) .NET: ASP.NET Core Identity Store
Pavel Tupitsyn created IGNITE-12417: --- Summary: .NET: ASP.NET Core Identity Store Key: IGNITE-12417 URL: https://issues.apache.org/jira/browse/IGNITE-12417 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Implement ASP.NET Core identity store based on Apache Ignite (Thin Client or Classic API). * Docs: https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio * RavenDB example: https://www.eximiaco.tech/en/2019/07/27/writing-an-asp-net-core-identity-storage-provider-from-scratch-with-ravendb/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Joining node validation failure event.
Ivan, Andrey, Nikolay, Thanks for your answers! Igniters, if there are no objections, could anyone take a look at implementation [1] of described above event, please? [1] https://github.com/apache/ignite/pull/7057 Regards, Mikhail. On 04.12.2019 21:54, Ivan Pavlukhin wrote: Mikhail, Yes I am fine with the approach. ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov : Ivan, Am I right, that current approach to solving this problem looks good for you? Regards, Mikhail. On 03.12.2019 15:12, Ivan Pavlukhin wrote: Mikhail, Yep, I see IgniteNodeValidationResult in new event in PR [1]. Discovery events such as (join/left/failed) are connected with a topology version change. In my case that not happens and may be misleading. That's why the new event type was chosen. I did not mean that one of those events should be used. I meant that it sounds natural to me to have an additional "unsuccessful node join" event (like is done in PR[1]). https://github.com/apache/ignite/pull/7057/files вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov : Nikolay, Ivan, I understood the possible problem. It seems that it can be solved using EventStorageSpi which starts before DiscoveryManager. As for me, ClusterNode is enough. It contains all info about joining node including its attributes. Discovery events such as (join/left/failed) are connected with a topology version change. In my case that not happens and may be misleading. That's why the new event type was chosen. The cause of the failure is also presented in the event. Regards, Mikhail. On 03.12.2019 13:19, Николай Ижиков wrote: Exception(s) from component(s) that don’t want node joined. 3 дек. 2019 г., в 12:39, Ivan Pavlukhin написал(а): How that reason will look like? Actually, I mostly thinking about general API here. What I would like to avoid is exposing something not general but needed only for a particular extension (plugin). вт, 3 дек. 2019 г. в 12:31, Николай Ижиков : I think we also should provide the reason why join failed. 3 дек. 2019 г., в 12:22, Ivan Pavlukhin написал(а): Mikhail, So, I suppose there should be ordering guarantees that listener is registered before first validation failure can occur. Hope GridComponent#onKernalStart is the right place. Is it enough to pass only problematic node id (or ClusterNode) with an event? Actually such event seems to fit naturally node join/left/failed events. вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov : Hi Ivan. No other lifecycle events are needed in my case. We can register a listener in the security component's GridComponent#onKernalStart method and listen locally to every failed joining attempt. Am I missing something? Regards, Mikhail. On 03.12.2019 8:48, Ivan Pavlukhin wrote: Mikhail, Do you need some ordering guarantees among node lifecycle events and listener notifications. For example, I can imagine that it is good to notify security component about every node failed validation. How can we achieve it with events (I assume dynamic listener registration)? пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov : Hi, Andrey. It doesn't influence on authentication or authorization process. There is a security requirement that demands to notify some outer security subsystems in a specific way when joining node validation failed in any Ignite component (e.g. GridCacheProcessor) not only in IgniteSecurityProcessor. So PluginProvider#validateNewNode is not acceptable for me. Regards, Mikhail. On 02.12.2019 16:35, Andrey Gura wrote: Mikhail, I don't understand how node validation on join affects security. But it seems that you can use PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode, java.io.Serializable) method. Does it fit for your needs? On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov wrote: Hi, Ivan. Unfortunately, we came to no decision yet. As I mentioned above this event is disabled by default and no node will receive this event without an explicit subscription. In my case, that event is assumed to be used on node locally to share joining node info between security and discovery components. I have no idea how to solve this problem without publishing a new event too. But I'm concerned about the acceptance of that solution. Maybe it can be solved some other way? I will appreciate any suggestion or review PR [1] with event implementation. [1] https://github.com/apache/ignite/pull/7057 Regards, Mikhail. On 02.12.2019 10:38, Ivan Pavlukhin wrote: Mikhail, Andrey, Have you come to a common decision here? As for me, it sounds useful to expose node join failure details somehow. The thing to decide on is a mechanism to expose it. Unfortunately, immediately have no idea better than using events. What is purpose of the special cluster wide event? Node is not joined to the topology. Why topology nodes should know something about this node? Was this question answered? I suppose that at least coordinator will receive the event, will not it? чт, 28 нояб. 2019 г. в 10:10
Re: Joining node validation failure event.
Mikhail, Yes I am fine with the approach. ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov : > > Ivan, > > Am I right, that current approach to solving this problem looks good for > you? > > Regards, > Mikhail. > > On 03.12.2019 15:12, Ivan Pavlukhin wrote: > > Mikhail, > > > > Yep, I see IgniteNodeValidationResult in new event in PR [1]. > > > >> Discovery events such as (join/left/failed) are connected with a > >> topology version change. In my case that not happens and may be > >> misleading. That's why the new event type was chosen. > > I did not mean that one of those events should be used. I meant that > > it sounds natural to me to have an additional "unsuccessful node join" > > event (like is done in PR[1]). > > > > https://github.com/apache/ignite/pull/7057/files > > > > вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov : > >> Nikolay, Ivan, > >> > >> I understood the possible problem. It seems that it can be solved using > >> EventStorageSpi which starts before DiscoveryManager. > >> > >> As for me, ClusterNode is enough. It contains all info about joining > >> node including its attributes. > >> > >> Discovery events such as (join/left/failed) are connected with a > >> topology version change. In my case that not happens and may be > >> misleading. That's why the new event type was chosen. > >> > >> The cause of the failure is also presented in the event. > >> > >> Regards, > >> Mikhail. > >> > >> On 03.12.2019 13:19, Николай Ижиков wrote: > >>> Exception(s) from component(s) that don’t want node joined. > >>> > 3 дек. 2019 г., в 12:39, Ivan Pavlukhin написал(а): > > How that reason will look like? Actually, I mostly thinking about > general API here. What I would like to avoid is exposing something not > general but needed only for a particular extension (plugin). > > вт, 3 дек. 2019 г. в 12:31, Николай Ижиков : > > I think we also should provide the reason why join failed. > > > >> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin > >> написал(а): > >> > >> Mikhail, > >> > >> So, I suppose there should be ordering guarantees that listener is > >> registered before first validation failure can occur. Hope > >> GridComponent#onKernalStart is the right place. Is it enough to pass > >> only problematic node id (or ClusterNode) with an event? Actually such > >> event seems to fit naturally node join/left/failed events. > >> > >> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov : > >>> Hi Ivan. > >>> > >>> No other lifecycle events are needed in my case. > >>> > >>> We can register a listener in the security component's > >>> GridComponent#onKernalStart method and listen locally to every failed > >>> joining attempt. Am I missing something? > >>> > >>> Regards, > >>> Mikhail. > >>> > >>> On 03.12.2019 8:48, Ivan Pavlukhin wrote: > Mikhail, > > Do you need some ordering guarantees among node lifecycle events and > listener notifications. For example, I can imagine that it is good to > notify security component about every node failed validation. How can > we achieve it with events (I assume dynamic listener registration)? > > пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov : > > Hi, Andrey. > > > > It doesn't influence on authentication or authorization process. > > There > > is a security requirement that demands to notify some outer security > > subsystems in a specific way when joining node validation failed in > > any > > Ignite component (e.g. GridCacheProcessor) not only in > > IgniteSecurityProcessor. So PluginProvider#validateNewNode is not > > acceptable for me. > > > > Regards, > > Mikhail. > > > > On 02.12.2019 16:35, Andrey Gura wrote: > >> Mikhail, > >> > >> I don't understand how node validation on join affects security. > >> But > >> it seems that you can use > >> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode, > >> java.io.Serializable) method. Does it fit for your needs? > >> > >> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov > >> wrote: > >>> Hi, Ivan. > >>> > >>> > >>> Unfortunately, we came to no decision yet. As I mentioned above > >>> this > >>> event is disabled by default and no node will receive this event > >>> without > >>> an explicit subscription. In my case, that event is assumed to be > >>> used > >>> on node locally to share joining node info between security and > >>> discovery components. I have no idea how to solve this problem > >>> without > >>> publishing a new event too. But I'm concerned about the > >>> acceptance of > >>> that solution
Re: Getting errors while setup new cluster using existing cluster data
Thanks Denis. It's ok to loose delta data(which are writing data to cluster while coping), but want to up the cluster whatever data is valid. Is there any way. I don't have idea about Kafka-like approach, will check. Thanks and Regards, Gangaiah -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Joining node validation failure event.
Ivan, Am I right, that current approach to solving this problem looks good for you? Regards, Mikhail. On 03.12.2019 15:12, Ivan Pavlukhin wrote: Mikhail, Yep, I see IgniteNodeValidationResult in new event in PR [1]. Discovery events such as (join/left/failed) are connected with a topology version change. In my case that not happens and may be misleading. That's why the new event type was chosen. I did not mean that one of those events should be used. I meant that it sounds natural to me to have an additional "unsuccessful node join" event (like is done in PR[1]). https://github.com/apache/ignite/pull/7057/files вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov : Nikolay, Ivan, I understood the possible problem. It seems that it can be solved using EventStorageSpi which starts before DiscoveryManager. As for me, ClusterNode is enough. It contains all info about joining node including its attributes. Discovery events such as (join/left/failed) are connected with a topology version change. In my case that not happens and may be misleading. That's why the new event type was chosen. The cause of the failure is also presented in the event. Regards, Mikhail. On 03.12.2019 13:19, Николай Ижиков wrote: Exception(s) from component(s) that don’t want node joined. 3 дек. 2019 г., в 12:39, Ivan Pavlukhin написал(а): How that reason will look like? Actually, I mostly thinking about general API here. What I would like to avoid is exposing something not general but needed only for a particular extension (plugin). вт, 3 дек. 2019 г. в 12:31, Николай Ижиков : I think we also should provide the reason why join failed. 3 дек. 2019 г., в 12:22, Ivan Pavlukhin написал(а): Mikhail, So, I suppose there should be ordering guarantees that listener is registered before first validation failure can occur. Hope GridComponent#onKernalStart is the right place. Is it enough to pass only problematic node id (or ClusterNode) with an event? Actually such event seems to fit naturally node join/left/failed events. вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov : Hi Ivan. No other lifecycle events are needed in my case. We can register a listener in the security component's GridComponent#onKernalStart method and listen locally to every failed joining attempt. Am I missing something? Regards, Mikhail. On 03.12.2019 8:48, Ivan Pavlukhin wrote: Mikhail, Do you need some ordering guarantees among node lifecycle events and listener notifications. For example, I can imagine that it is good to notify security component about every node failed validation. How can we achieve it with events (I assume dynamic listener registration)? пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov : Hi, Andrey. It doesn't influence on authentication or authorization process. There is a security requirement that demands to notify some outer security subsystems in a specific way when joining node validation failed in any Ignite component (e.g. GridCacheProcessor) not only in IgniteSecurityProcessor. So PluginProvider#validateNewNode is not acceptable for me. Regards, Mikhail. On 02.12.2019 16:35, Andrey Gura wrote: Mikhail, I don't understand how node validation on join affects security. But it seems that you can use PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode, java.io.Serializable) method. Does it fit for your needs? On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov wrote: Hi, Ivan. Unfortunately, we came to no decision yet. As I mentioned above this event is disabled by default and no node will receive this event without an explicit subscription. In my case, that event is assumed to be used on node locally to share joining node info between security and discovery components. I have no idea how to solve this problem without publishing a new event too. But I'm concerned about the acceptance of that solution. Maybe it can be solved some other way? I will appreciate any suggestion or review PR [1] with event implementation. [1] https://github.com/apache/ignite/pull/7057 Regards, Mikhail. On 02.12.2019 10:38, Ivan Pavlukhin wrote: Mikhail, Andrey, Have you come to a common decision here? As for me, it sounds useful to expose node join failure details somehow. The thing to decide on is a mechanism to expose it. Unfortunately, immediately have no idea better than using events. What is purpose of the special cluster wide event? Node is not joined to the topology. Why topology nodes should know something about this node? Was this question answered? I suppose that at least coordinator will receive the event, will not it? чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov : Hi, Ivan. I'm sorry that the discussion was moved in private channel. The problem I'm trying to solve is described below in the thread. The security plugin in my case stores and analyzesinfo about a node that failed to join. Regards, Mikhail. Forwarded Message Subject:Re: Joining node validation failure event. Date:
Re: [ANNOUNCE] 4 December 2019, the 2.8 RELEASE brach creation
Great, many thanks to your job ср, 4 дек. 2019 г., 19:05 Maxim Muzafarov : > Igniters, > > > 1. The release branch created: ignite-2.8 > 2. The list of unresolved issues [1] related to the 2.8 release has > been cleaned up (only Blocker and Critical issues left). > 3. Apache Ignite 2.8 wiki page has been updated [2]. > 4. The issue [3] with Corrupted B+ tree exception has been reverted > from the master branch. Discussed [4] [5]. > > > If you are working on issues related to 2.8 release, please, don't forget > to: > 1. Discuss them on dev-list (To make the release branch stable we need > to eliminate risks of any such issues) > 2. Merge them to both branches master and ignite-2.8. > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) > [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8 > [3] https://issues.apache.org/jira/browse/IGNITE-11704 > [4] > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44539.html > [5] > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44551.html > > On Fri, 29 Nov 2019 at 12:52, Alexey Zinoviev > wrote: > > > > Is it ok for me, but please move IGFS dropping ticket to the next > release, > > I have no capacity to finish in time the blocker ticket related to > > Tensorflow-Ignite integration and as a result we shouldn't remove the > IGFS > > yet but please mark it as a deprecated and ready for removal in 3.0 > > > > чт, 28 нояб. 2019 г. в 16:03, Maxim Muzafarov : > > > > > Denis, > > > > > > What kind of additional checks do we need? Maybe I'm missing something > > > but all issues currently merged to the master branch will be present > > > in the 2.8 release branch too. > > > I see that this issue has been closed a long time ago, so it > > > definitely comes in. > > > > > > On Thu, 28 Nov 2019 at 01:33, Denis Magda wrote: > > > > > > > > Hi Maxim, > > > > > > > > Sounds good, thanks for branching. Could you double-check that the > > > > following issue was added to the release? > > > > https://issues.apache.org/jira/browse/IGNITE-10577 > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Wed, Nov 27, 2019 at 7:50 AM Maxim Muzafarov > > > wrote: > > > > > > > > > Igniters, > > > > > > > > > > > > > > > I think we are ready to create the 2.8 release branch since > features > > > > > [1] which we are waiting for are almost completed. > > > > > > > > > > 4 December 2019, the 2.8 release branch will be created. All > related > > > > > issues with a priority less than `critical` will be excluded from > the > > > > > 2.8 release (fix version will be changed to 2.9). > > > > > > > > > > > > > > > Any objections? > > > > > > > > > > > > > > > [1] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Awatingfeaturescompletion > > > > > > > > >
Re: [ANNOUNCE] 4 December 2019, the 2.8 RELEASE brach creation
Igniters, 1. The release branch created: ignite-2.8 2. The list of unresolved issues [1] related to the 2.8 release has been cleaned up (only Blocker and Critical issues left). 3. Apache Ignite 2.8 wiki page has been updated [2]. 4. The issue [3] with Corrupted B+ tree exception has been reverted from the master branch. Discussed [4] [5]. If you are working on issues related to 2.8 release, please, don't forget to: 1. Discuss them on dev-list (To make the release branch stable we need to eliminate risks of any such issues) 2. Merge them to both branches master and ignite-2.8. [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation) [2] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8 [3] https://issues.apache.org/jira/browse/IGNITE-11704 [4] http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44539.html [5] http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-tp43616p44551.html On Fri, 29 Nov 2019 at 12:52, Alexey Zinoviev wrote: > > Is it ok for me, but please move IGFS dropping ticket to the next release, > I have no capacity to finish in time the blocker ticket related to > Tensorflow-Ignite integration and as a result we shouldn't remove the IGFS > yet but please mark it as a deprecated and ready for removal in 3.0 > > чт, 28 нояб. 2019 г. в 16:03, Maxim Muzafarov : > > > Denis, > > > > What kind of additional checks do we need? Maybe I'm missing something > > but all issues currently merged to the master branch will be present > > in the 2.8 release branch too. > > I see that this issue has been closed a long time ago, so it > > definitely comes in. > > > > On Thu, 28 Nov 2019 at 01:33, Denis Magda wrote: > > > > > > Hi Maxim, > > > > > > Sounds good, thanks for branching. Could you double-check that the > > > following issue was added to the release? > > > https://issues.apache.org/jira/browse/IGNITE-10577 > > > > > > - > > > Denis > > > > > > > > > On Wed, Nov 27, 2019 at 7:50 AM Maxim Muzafarov > > wrote: > > > > > > > Igniters, > > > > > > > > > > > > I think we are ready to create the 2.8 release branch since features > > > > [1] which we are waiting for are almost completed. > > > > > > > > 4 December 2019, the 2.8 release branch will be created. All related > > > > issues with a priority less than `critical` will be excluded from the > > > > 2.8 release (fix version will be changed to 2.9). > > > > > > > > > > > > Any objections? > > > > > > > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Awatingfeaturescompletion > > > > > >
[jira] [Created] (IGNITE-12416) Avoid use deprecated the Ignite.active(boolean) methods in project
Amelchev Nikita created IGNITE-12416: Summary: Avoid use deprecated the Ignite.active(boolean) methods in project Key: IGNITE-12416 URL: https://issues.apache.org/jira/browse/IGNITE-12416 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita IgniteCluster#active(boolean) should be used instead of Ignite#active(boolean) IgniteCluster#active() should be used instead of Ignite#active() Since IEP-4 was merged and deprecates cluster activation methods Deprecated methods usages provide many warnings on the build project stage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Links to commercial version resources in community wiki
I agree that 'TODO: please, fix me GG-X' Should be definitely avoided in the code in all cases. A number of community members don't have access to these tickets. This is the same as linking to GG's private documentation or internal network servers. It doesn't make sense. ср, 4 дек. 2019 г. в 14:53, Ivan Pavlukhin : > Maxim, > > References to GG tickets have definitely no meaning for community. But > references to documentation on the other hand can be very useful, > actually it is very similar to references to Wikipedia or > aforementioned Oracle resources. > > ср, 4 дек. 2019 г. в 14:40, Maxim Muzafarov : > > > > Folks, > > > > In general case, 3rd party resource links look for me absolutely > > normal e.g. we could have some links on Oracle's documentation pages. > > > > But let's add a little accuracy. We are talking about links to > > GridGain documentation pages. For me, it's the same as comments `TODO: > > please, fix me GG-X` in the source code (e.g. like this one [1]). > > Looks a bit strange :-) > > > > > > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/PartitionUpdateCounter.java#L43 > > > > On Tue, 3 Dec 2019 at 20:13, Dmitriy Pavlov wrote: > > > > > > Hi Igniters, > > > > > > It is not good if we'll made a tradition of linking to company websites > > > from the community website / wiki / lists. But if it makes sense to > mention > > > something useful for users, why not. > > > > > > And in this particular case it may be ok, if it is relevant. Just > remember, > > > community resources are not Nascar cars. > > > > > > See also https://www.apache.org/foundation/marks/linking > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > вт, 3 дек. 2019 г. в 19:50, Denis Magda : > > > > > > > Hi Ivan, > > > > > > > > If an author of an article believes that there is a 3rd party > resource that > > > > is handy and helpful for his/her work then there is nothing wrong to > refer > > > > to it. Based on Alexey's response in another thread, that GridGain > page > > > > brings more clarity to the topic, thus, don't see any issue with > that. > > > > > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Tue, Dec 3, 2019 at 6:41 AM Ivan Pavlukhin > wrote: > > > > > > > > > Folks, > > > > > > > > > > In a thread about a document describing data consistency [1] in > Ignite > > > > > it was identified that there is a link to GridGain documentation. > > > > > > > > > > I do not have strong arguments against having such links in > community > > > > > wiki. But it interesting to me to discuss the subject with > community. > > > > > Might be there is some common practice in ASF communities about the > > > > > subject. > > > > > > > > > > Please, share your thoughts. > > > > > > > > > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > -- > Best regards, > Ivan Pavlukhin >
Re: [DISCUSS] Links to commercial version resources in community wiki
Maxim, References to GG tickets have definitely no meaning for community. But references to documentation on the other hand can be very useful, actually it is very similar to references to Wikipedia or aforementioned Oracle resources. ср, 4 дек. 2019 г. в 14:40, Maxim Muzafarov : > > Folks, > > In general case, 3rd party resource links look for me absolutely > normal e.g. we could have some links on Oracle's documentation pages. > > But let's add a little accuracy. We are talking about links to > GridGain documentation pages. For me, it's the same as comments `TODO: > please, fix me GG-X` in the source code (e.g. like this one [1]). > Looks a bit strange :-) > > > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/PartitionUpdateCounter.java#L43 > > On Tue, 3 Dec 2019 at 20:13, Dmitriy Pavlov wrote: > > > > Hi Igniters, > > > > It is not good if we'll made a tradition of linking to company websites > > from the community website / wiki / lists. But if it makes sense to mention > > something useful for users, why not. > > > > And in this particular case it may be ok, if it is relevant. Just remember, > > community resources are not Nascar cars. > > > > See also https://www.apache.org/foundation/marks/linking > > > > Sincerely, > > Dmitriy Pavlov > > > > вт, 3 дек. 2019 г. в 19:50, Denis Magda : > > > > > Hi Ivan, > > > > > > If an author of an article believes that there is a 3rd party resource > > > that > > > is handy and helpful for his/her work then there is nothing wrong to refer > > > to it. Based on Alexey's response in another thread, that GridGain page > > > brings more clarity to the topic, thus, don't see any issue with that. > > > > > > > > > - > > > Denis > > > > > > > > > On Tue, Dec 3, 2019 at 6:41 AM Ivan Pavlukhin wrote: > > > > > > > Folks, > > > > > > > > In a thread about a document describing data consistency [1] in Ignite > > > > it was identified that there is a link to GridGain documentation. > > > > > > > > I do not have strong arguments against having such links in community > > > > wiki. But it interesting to me to discuss the subject with community. > > > > Might be there is some common practice in ASF communities about the > > > > subject. > > > > > > > > Please, share your thoughts. > > > > > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > -- Best regards, Ivan Pavlukhin
Re: [DISCUSS] Links to commercial version resources in community wiki
Folks, In general case, 3rd party resource links look for me absolutely normal e.g. we could have some links on Oracle's documentation pages. But let's add a little accuracy. We are talking about links to GridGain documentation pages. For me, it's the same as comments `TODO: please, fix me GG-X` in the source code (e.g. like this one [1]). Looks a bit strange :-) [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/PartitionUpdateCounter.java#L43 On Tue, 3 Dec 2019 at 20:13, Dmitriy Pavlov wrote: > > Hi Igniters, > > It is not good if we'll made a tradition of linking to company websites > from the community website / wiki / lists. But if it makes sense to mention > something useful for users, why not. > > And in this particular case it may be ok, if it is relevant. Just remember, > community resources are not Nascar cars. > > See also https://www.apache.org/foundation/marks/linking > > Sincerely, > Dmitriy Pavlov > > вт, 3 дек. 2019 г. в 19:50, Denis Magda : > > > Hi Ivan, > > > > If an author of an article believes that there is a 3rd party resource that > > is handy and helpful for his/her work then there is nothing wrong to refer > > to it. Based on Alexey's response in another thread, that GridGain page > > brings more clarity to the topic, thus, don't see any issue with that. > > > > > > - > > Denis > > > > > > On Tue, Dec 3, 2019 at 6:41 AM Ivan Pavlukhin wrote: > > > > > Folks, > > > > > > In a thread about a document describing data consistency [1] in Ignite > > > it was identified that there is a link to GridGain documentation. > > > > > > I do not have strong arguments against having such links in community > > > wiki. But it interesting to me to discuss the subject with community. > > > Might be there is some common practice in ASF communities about the > > > subject. > > > > > > Please, share your thoughts. > > > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > >
[jira] [Created] (IGNITE-12415) .NET: Thin client does not connect to old server nodes
Pavel Tupitsyn created IGNITE-12415:
---
Summary: .NET: Thin client does not connect to old server nodes
Key: IGNITE-12415
URL: https://issues.apache.org/jira/browse/IGNITE-12415
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
Exception when trying to connect .NET Thin Client from current master
(https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20191203) to the 2.7.6
server node:
{code}
Unhandled exception. Apache.Ignite.Core.Client.IgniteClientException: Client
handshake failed: 'Unsupported version.'. Client version: 1.6.0. Server
version: 1.2.0
at
Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(IgniteClientConfiguration
clientConfiguration, ClientProtocolVersion version)
at
Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration
clientConfiguration, EndPoint endPoint, String host, Nullable`1 version,
Action`1 topVerCallback)
at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.Connect()
at
Apache.Ignite.Core.Impl.Client.ClientFailoverSocket..ctor(IgniteClientConfiguration
config, Marshaller marsh)
at
Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration
clientConfiguration)
at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration
clientConfiguration)
at ConsoleApp2.Program.Main(String[] args) in
/home/pavel/RiderProjects/ConsoleApp2/ConsoleApp2/Program.cs:line 14
[StatusCode=Fail]
{code}
This is caused by buggy version handling logic in Handshake method. Otherwise
we support any older protocol version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Full-text queries in Thin Client protocol
Pavel mentioned a thread [1] discussion further development of text queries in Ignite. And currently there is some work in progress. And there is a lot to be improved. As for me, I think that we might think about thin clients support when user demand appear. [1] http://apache-ignite-developers.2346864.n4.nabble.com/Text-queries-indexes-GridLuceneIndex-QueryTextFiled-td43335.html вт, 3 дек. 2019 г. в 18:33, Igor Sapego : > > Pavel, > > I'm against adding this feature, as there were talks recently, that we > should stop supporting TextQuery altogether. No sense in adding > something, that we will need to depreciate and remove soon. > > Best Regards, > Igor > > > On Tue, Dec 3, 2019 at 5:46 PM Pavel Tupitsyn wrote: > > > Oh wow, the next thread actually discusses this very issue about > > discontinuation: > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Text-queries-indexes-GridLuceneIndex-QueryTextFiled-td43335.html > > > > But the question stands - add to Thin Clients or not? > > > > On Tue, Dec 3, 2019 at 5:43 PM Pavel Tupitsyn > > wrote: > > > > > Igniters, > > > > > > I'd like to discuss adding full-text queries (TextQuery, our Lucene-based > > > engine) to the Thin Client protocol. > > > > > > In my opinion, this is a good addition, and rather easy to implement. > > > However, I vaguely remember in-person discussions with some community > > > members along the lines of > > > "Ignite full-text search capabilities may be deprecated or reworked soon, > > > let's not add to thin clients". > > > > > > Any insights on this? Thoughts, objections? > > > > > > Thanks, > > > Pavel > > > > > > > > > > > > > > -- Best regards, Ivan Pavlukhin
