[jira] [Created] (IGNITE-11508) Yarn Ignite deployment: Add support to over ride queue name through cluster properties
ARAVINDA REDDY N created IGNITE-11508:
-
Summary: Yarn Ignite deployment: Add support to over ride queue
name through cluster properties
Key: IGNITE-11508
URL: https://issues.apache.org/jira/browse/IGNITE-11508
Project: Ignite
Issue Type: Improvement
Components: yarn
Affects Versions: 2.7
Reporter: ARAVINDA REDDY N
Yarn ignite 2.7.0 doesn't have the facility to provide queue name through the
cluster.properties. When i checked the IgniteYarnClient source code by default
it is set to "default".
// Finally, set-up ApplicationSubmissionContext for the application
ApplicationSubmissionContext appContext =
app.getApplicationSubmissionContext();
appContext.setApplicationName("ignition"); // application name
appContext.setAMContainerSpec(amContainer);
appContext.setResource(capability);
appContext.setQueue("default"); // queue
It would be a great support if we can allow overriding it through cluster
properties.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Ignite 2.8 Release: Time & Scope & Release manager
Dmitry, “Master is always releasable” is a myth, let’s do not be naive. We develop complex product. Many features are being developed in iterations. Many features are developed by different contributors and have to be aligned with each other after merge. And in the end all this should be tested and benchmarked before becoming a product. None serious products are “releasable” from master in a classical “release” sense. Nightly builds are not releases. чт, 7 марта 2019 г. в 20:31, Dmitriy Pavlov : > Vova it is not cool I have to remind Ignite veterans about How to > contribute page, it says the master is release ready branch. > > Otherwise feature is developed in its own branch. > > So my vote goes for master-based release. > > чт, 7 мар. 2019 г. в 20:28, Vladimir Ozerov : > > > Igniters, > > > > Making release from master is not an option. We have a lot of > not-yet-ready > > and not-yet-tested features. From SQL side this is partition pruning and > > SQL views with KILL command. > > > > So if we do not want to release a mess, then there are only two options: > > release Java 11 fixes on top of 2.7, or make normal release in about > 1.5-2 > > month with proper feature freeze process and testing. > > > > Vladimir. > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev >: > > > > > Hello! > > > > > > Then please fast-forward review and merge > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks > SSL > > > on > > > Windows under Java 11. > > > > > > Anything else that needs to be merged before release is branched? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > +1 > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > Igniters, > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > release > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > > with > > > > > Java 11 improvements, they are really helpful from the usability > > > > > standpoint. > > > > > > > > > > After this release, let's introduce a practice of maintenance > > releases > > > > > 2.8.x. Those who are working on any improvements and won't merge > them > > > to > > > > > the release branch on Monday-Tuesday will be able to roll out in a > > > point > > > > > release like 2.8.1 slightly later. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > In the separate topic, we've touched the question of next release > > of > > > > > Apache > > > > > > Ignite. > > > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > > changes > > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > > full > > > > > > modularity support is impossible without 3.0 because package > > > > refactoring > > > > > is > > > > > > breaking change in some cases. > > > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed > that > > > the > > > > > > next release will contain step 1 of services redesign, - > discovery > > > > > protocol > > > > > > usage for services redeploy. > > > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > > cherry-picked > > > > > > into it. It is analog of emergency release but without really > > > > emergency. > > > > > > Since we don't release our new modules we have more time to make > it > > > > > modular > > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > > include > > > > > > new hibernate version, ignite-compress, ignite-services, and all > > > other > > > > > > changes we have. Once it is published we will not be able to > change > > > > > > something. > > > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > > this > > > > > > release (as release manager). > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Denis, there is not so much difference in Java 9 vs Java 11, so previous Java 9-efforts done by Igniters should be applicable for 11. So I don't understand why we can go through the normal release process and pilot minor releases afterward. Please share a particular case when the absence of `emergency 2.8` is a problem for the user. Is it still our rush and 'highway or no way'? I was in the hope it is gone. чт, 7 мар. 2019 г. в 20:43, Denis Magda : > Vova, > > Thanks for the inputs. If it takes weeks to stabilize the master then let's > release from 2.7 cherry-picking Java 11 improvements. We can't wait for > months holding these improvements - the world is switching to Java 11 and > Ignite fails during the first runs presently. > > - > Denis > > > On Thu, Mar 7, 2019 at 9:28 AM Vladimir Ozerov > wrote: > > > Igniters, > > > > Making release from master is not an option. We have a lot of > not-yet-ready > > and not-yet-tested features. From SQL side this is partition pruning and > > SQL views with KILL command. > > > > So if we do not want to release a mess, then there are only two options: > > release Java 11 fixes on top of 2.7, or make normal release in about > 1.5-2 > > month with proper feature freeze process and testing. > > > > Vladimir. > > > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev >: > > > > > Hello! > > > > > > Then please fast-forward review and merge > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks > SSL > > > on > > > Windows under Java 11. > > > > > > Anything else that needs to be merged before release is branched? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > > > +1 > > > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > > > Igniters, > > > > > > > > > > How about releasing Ignite 2.8 from the master - creating the > release > > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > > with > > > > > Java 11 improvements, they are really helpful from the usability > > > > > standpoint. > > > > > > > > > > After this release, let's introduce a practice of maintenance > > releases > > > > > 2.8.x. Those who are working on any improvements and won't merge > them > > > to > > > > > the release branch on Monday-Tuesday will be able to roll out in a > > > point > > > > > release like 2.8.1 slightly later. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > In the separate topic, we've touched the question of next release > > of > > > > > Apache > > > > > > Ignite. > > > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > > changes > > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > > full > > > > > > modularity support is impossible without 3.0 because package > > > > refactoring > > > > > is > > > > > > breaking change in some cases. > > > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed > that > > > the > > > > > > next release will contain step 1 of services redesign, - > discovery > > > > > protocol > > > > > > usage for services redeploy. > > > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > > cherry-picked > > > > > > into it. It is analog of emergency release but without really > > > > emergency. > > > > > > Since we don't release our new modules we have more time to make > it > > > > > modular > > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > > include > > > > > > new hibernate version, ignite-compress, ignite-services, and all > > > other > > > > > > changes we have. Once it is published we will not be able to > change > > > > > > something. > > > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > > this > > > > > > release (as release manager). > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Vova it is not cool I have to remind Ignite veterans about How to contribute page, it says the master is release ready branch. Otherwise feature is developed in its own branch. So my vote goes for master-based release. чт, 7 мар. 2019 г. в 20:28, Vladimir Ozerov : > Igniters, > > Making release from master is not an option. We have a lot of not-yet-ready > and not-yet-tested features. From SQL side this is partition pruning and > SQL views with KILL command. > > So if we do not want to release a mess, then there are only two options: > release Java 11 fixes on top of 2.7, or make normal release in about 1.5-2 > month with proper feature freeze process and testing. > > Vladimir. > > чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev : > > > Hello! > > > > Then please fast-forward review and merge > > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks SSL > > on > > Windows under Java 11. > > > > Anything else that needs to be merged before release is branched? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > > > +1 > > > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > > > Igniters, > > > > > > > > How about releasing Ignite 2.8 from the master - creating the release > > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > > with > > > > Java 11 improvements, they are really helpful from the usability > > > > standpoint. > > > > > > > > After this release, let's introduce a practice of maintenance > releases > > > > 2.8.x. Those who are working on any improvements and won't merge them > > to > > > > the release branch on Monday-Tuesday will be able to roll out in a > > point > > > > release like 2.8.1 slightly later. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > > wrote: > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > In the separate topic, we've touched the question of next release > of > > > > Apache > > > > > Ignite. > > > > > > > > > > The main reason for the release is Java 11 support, modularity > > changes > > > > > (actually we have a couple of this kind of fixes). Unfortunately, > > full > > > > > modularity support is impossible without 3.0 because package > > > refactoring > > > > is > > > > > breaking change in some cases. > > > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed that > > the > > > > > next release will contain step 1 of services redesign, - discovery > > > > protocol > > > > > usage for services redeploy. > > > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > > cherry-picked > > > > > into it. It is analog of emergency release but without really > > > emergency. > > > > > Since we don't release our new modules we have more time to make it > > > > modular > > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > > > B. (in large) And, it is a full release based on master, it will > > > include > > > > > new hibernate version, ignite-compress, ignite-services, and all > > other > > > > > changes we have. Once it is published we will not be able to change > > > > > something. > > > > > > > > > > Please share your vision, and please stand up if you want to lead > > this > > > > > release (as release manager). > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Igniters, Making release from master is not an option. We have a lot of not-yet-ready and not-yet-tested features. From SQL side this is partition pruning and SQL views with KILL command. So if we do not want to release a mess, then there are only two options: release Java 11 fixes on top of 2.7, or make normal release in about 1.5-2 month with proper feature freeze process and testing. Vladimir. чт, 7 марта 2019 г. в 20:10, Ilya Kasnacheev : > Hello! > > Then please fast-forward review and merge > https://issues.apache.org/jira/browse/IGNITE-11299 because it breaks SSL > on > Windows under Java 11. > > Anything else that needs to be merged before release is branched? > > Regards, > -- > Ilya Kasnacheev > > > чт, 7 мар. 2019 г. в 20:07, Nikolay Izhikov : > > > +1 > > > > чт, 7 марта 2019 г., 20:00 Denis Magda : > > > > > Igniters, > > > > > > How about releasing Ignite 2.8 from the master - creating the release > > > branch on Monday-Tuesday, as fast as we can? Don't want us to delay > with > > > Java 11 improvements, they are really helpful from the usability > > > standpoint. > > > > > > After this release, let's introduce a practice of maintenance releases > > > 2.8.x. Those who are working on any improvements and won't merge them > to > > > the release branch on Monday-Tuesday will be able to roll out in a > point > > > release like 2.8.1 slightly later. > > > > > > - > > > Denis > > > > > > > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov > > wrote: > > > > > > > Hi Ignite Developers, > > > > > > > > In the separate topic, we've touched the question of next release of > > > Apache > > > > Ignite. > > > > > > > > The main reason for the release is Java 11 support, modularity > changes > > > > (actually we have a couple of this kind of fixes). Unfortunately, > full > > > > modularity support is impossible without 3.0 because package > > refactoring > > > is > > > > breaking change in some cases. > > > > > > > > But I clearly remember that in 2.7 thread we've also discussed that > the > > > > next release will contain step 1 of services redesign, - discovery > > > protocol > > > > usage for services redeploy. > > > > > > > > We have 2 alternative options for releasing 2.8; > > > > > > > > A. (in a small way): 2.7-based branch with particular commits > > > cherry-picked > > > > into it. It is analog of emergency release but without really > > emergency. > > > > Since we don't release our new modules we have more time to make it > > > modular > > > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > > > > > B. (in large) And, it is a full release based on master, it will > > include > > > > new hibernate version, ignite-compress, ignite-services, and all > other > > > > changes we have. Once it is published we will not be able to change > > > > something. > > > > > > > > Please share your vision, and please stand up if you want to lead > this > > > > release (as release manager). > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 чт, 7 марта 2019 г., 20:00 Denis Magda : > Igniters, > > How about releasing Ignite 2.8 from the master - creating the release > branch on Monday-Tuesday, as fast as we can? Don't want us to delay with > Java 11 improvements, they are really helpful from the usability > standpoint. > > After this release, let's introduce a practice of maintenance releases > 2.8.x. Those who are working on any improvements and won't merge them to > the release branch on Monday-Tuesday will be able to roll out in a point > release like 2.8.1 slightly later. > > - > Denis > > > On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov wrote: > > > Hi Ignite Developers, > > > > In the separate topic, we've touched the question of next release of > Apache > > Ignite. > > > > The main reason for the release is Java 11 support, modularity changes > > (actually we have a couple of this kind of fixes). Unfortunately, full > > modularity support is impossible without 3.0 because package refactoring > is > > breaking change in some cases. > > > > But I clearly remember that in 2.7 thread we've also discussed that the > > next release will contain step 1 of services redesign, - discovery > protocol > > usage for services redeploy. > > > > We have 2 alternative options for releasing 2.8; > > > > A. (in a small way): 2.7-based branch with particular commits > cherry-picked > > into it. It is analog of emergency release but without really emergency. > > Since we don't release our new modules we have more time to make it > modular > > for 2.9 and make Ignite fully modules compliant in 3.0 > > > > B. (in large) And, it is a full release based on master, it will include > > new hibernate version, ignite-compress, ignite-services, and all other > > changes we have. Once it is published we will not be able to change > > something. > > > > Please share your vision, and please stand up if you want to lead this > > release (as release manager). > > > > Sincerely, > > Dmitriy Pavlov > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Igniters, How about releasing Ignite 2.8 from the master - creating the release branch on Monday-Tuesday, as fast as we can? Don't want us to delay with Java 11 improvements, they are really helpful from the usability standpoint. After this release, let's introduce a practice of maintenance releases 2.8.x. Those who are working on any improvements and won't merge them to the release branch on Monday-Tuesday will be able to roll out in a point release like 2.8.1 slightly later. - Denis On Thu, Mar 7, 2019 at 6:22 AM Dmitriy Pavlov wrote: > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov >
[jira] [Created] (IGNITE-11507) SQL: Ensure that affinity topology version doesn't change during PartitionResult construction/application.
Alexander Lapin created IGNITE-11507: Summary: SQL: Ensure that affinity topology version doesn't change during PartitionResult construction/application. Key: IGNITE-11507 URL: https://issues.apache.org/jira/browse/IGNITE-11507 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Lapin Fix For: 2.8 Currently some actions might be performed (for example cache removal) during PartitionResult construction, so it might become invalid. Besides that it's not possible to associate PartitionResult with affinity topology version, so it is impossible to guarantee that the partition result is used on the same version on which it was built. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11506) Web Console: Adjust CSS styles to correctly show "User name" in top menu.
Alexey Kuznetsov created IGNITE-11506: - Summary: Web Console: Adjust CSS styles to correctly show "User name" in top menu. Key: IGNITE-11506 URL: https://issues.apache.org/jira/browse/IGNITE-11506 Project: Ignite Issue Type: Bug Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov If user will input large names UI will be broken. We need to tweak CSS overflow properties -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello! I think we can surely go with B. It contains fresh Hibernate and Spring Data support with fixed bugs, which is good while it lasts. Also there are a lot of Java 11 fixes and cherry-picking them all probably not much easier than just stabilizing master. We have fixes for other regressions too. Regards, -- Ilya Kasnacheev чт, 7 мар. 2019 г. в 17:22, Dmitriy Pavlov : > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Can we freeze scope effective immediately, make branch and stabilise whatever should be finished, producing not emergency but not full regular release? > On 7 Mar 2019, at 17:21, Dmitriy Pavlov wrote: > > Hi Ignite Developers, > > In the separate topic, we've touched the question of next release of Apache > Ignite. > > The main reason for the release is Java 11 support, modularity changes > (actually we have a couple of this kind of fixes). Unfortunately, full > modularity support is impossible without 3.0 because package refactoring is > breaking change in some cases. > > But I clearly remember that in 2.7 thread we've also discussed that the > next release will contain step 1 of services redesign, - discovery protocol > usage for services redeploy. > > We have 2 alternative options for releasing 2.8; > > A. (in a small way): 2.7-based branch with particular commits cherry-picked > into it. It is analog of emergency release but without really emergency. > Since we don't release our new modules we have more time to make it modular > for 2.9 and make Ignite fully modules compliant in 3.0 > > B. (in large) And, it is a full release based on master, it will include > new hibernate version, ignite-compress, ignite-services, and all other > changes we have. Once it is published we will not be able to change > something. > > Please share your vision, and please stand up if you want to lead this > release (as release manager). > > Sincerely, > Dmitriy Pavlov
Ignite 2.8 Release: Time & Scope & Release manager
Hi Ignite Developers, In the separate topic, we've touched the question of next release of Apache Ignite. The main reason for the release is Java 11 support, modularity changes (actually we have a couple of this kind of fixes). Unfortunately, full modularity support is impossible without 3.0 because package refactoring is breaking change in some cases. But I clearly remember that in 2.7 thread we've also discussed that the next release will contain step 1 of services redesign, - discovery protocol usage for services redeploy. We have 2 alternative options for releasing 2.8; A. (in a small way): 2.7-based branch with particular commits cherry-picked into it. It is analog of emergency release but without really emergency. Since we don't release our new modules we have more time to make it modular for 2.9 and make Ignite fully modules compliant in 3.0 B. (in large) And, it is a full release based on master, it will include new hibernate version, ignite-compress, ignite-services, and all other changes we have. Once it is published we will not be able to change something. Please share your vision, and please stand up if you want to lead this release (as release manager). Sincerely, Dmitriy Pavlov
[jira] [Created] (IGNITE-11505) Validation of starting cache configuration wraps original exception into Suppressed section
Pavel Kuznetsov created IGNITE-11505:
Summary: Validation of starting cache configuration wraps original
exception into Suppressed section
Key: IGNITE-11505
URL: https://issues.apache.org/jira/browse/IGNITE-11505
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Kuznetsov
{{org.apache.ignite.internal.processors.cache.GridCacheProcessor#validate}} :
If user starts cache dynamically via {{getOrCreateCache}} on *server node* and
{{validate}} method throws an
exception, this exception will be shown to user in the as Suppressed. So user
need to get the cause as {{ String origMessage =
catchedUserExc.getSuppressed()[0].getCause().getMessage();}}.
To reproduce, it is important, that validation should be performed on the
server node.
take a look at stacktraces.
cache started from server node:
{noformat}
class org.apache.ignite.IgniteCheckedException: Failed to complete exchange
process.
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3209)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3237)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3323)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3304)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2906)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:145)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2713)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2701)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2701)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1812)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:148)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:385)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:343)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3368)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3347)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1126)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[jira] [Created] (IGNITE-11504) [ML] Preprocessor trainers should support new feature-label extraction API
Alexey Platonov created IGNITE-11504: Summary: [ML] Preprocessor trainers should support new feature-label extraction API Key: IGNITE-11504 URL: https://issues.apache.org/jira/browse/IGNITE-11504 Project: Ignite Issue Type: Improvement Components: ml Reporter: Alexey Platonov Problem is same as feature extractors serialization bug. We should narrow our API. (see parent task) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Best Effort Affinity for thin clients
I can propose two improvements here: 1. A simple one. Lets introduce maxConnectionNumber parameter in ClientConfiguration. As it is easy to implement it may be introduced together with the new feature to give user an additional control. 2. Asynchronous connection establishment. In this case startup method of a client returns control to user once it have established at least one connection. Other connections established in background by a separate thread. This one is harder to implement and maybe it makes sense to add it as a separate feature. Best Regards, Igor On Wed, Mar 6, 2019 at 9:43 PM Pavel Tupitsyn wrote: > Hi, > > I'm in progress of implementing this IEP for Ignite.NET, and I have > concerns about the following: > > > On thin client startup it connects to all nodes provided by client > configuration > > Should we, at least, make this behavior optional? > > One of the benefits of thin client is quick startup/connect time and low > resource usage. > Adding "connect all" behavior can negate those benefits, especially on > large clusters. > > Thoughts? > > On Thu, Feb 14, 2019 at 5:39 PM Igor Sapego wrote: > > > Guys, I've updated the IEP page [1] once again. > > > > Please, pay attention to sections Cache affinity mapping acquiring > > (4.a, format of Cache Partitions Request) and Changes to cache > > operations with single key (3 and 4, algorithm). > > > > Long story short, I've decided to add some additional data to Cache > > Partitions Response, so that client can determine how to calculate > > partition for a given key properly. > > > > [1] - > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > > > Best Regards, > > Igor > > > > > > On Mon, Feb 4, 2019 at 8:24 PM Pavel Tupitsyn > > wrote: > > > > > Looks good to me. > > > > > > On Mon, Feb 4, 2019 at 6:30 PM Igor Sapego wrote: > > > > > > > I've updated IEP page: [1] > > > > > > > > What do you think now? To me it looks cleaner. > > > > > > > > [1] - > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > > > > > > > Best Regards, > > > > Igor > > > > > > > > > > > > On Mon, Feb 4, 2019 at 4:44 PM Igor Sapego > wrote: > > > > > > > > > Ok, I understand now. I'll try updating IEP according to this > > proposal > > > > and > > > > > notify you guys. > > > > > > > > > > Best Regards, > > > > > Igor > > > > > > > > > > > > > > > On Mon, Feb 4, 2019 at 4:27 PM Vladimir Ozerov < > voze...@gridgain.com > > > > > > > > wrote: > > > > > > > > > >> Igor, > > > > >> > > > > >> My idea is simply to add the list of caches with the same > > distribution > > > > to > > > > >> the end of partition response. Client can use this information to > > > > populate > > > > >> partition info for more caches in a single request. > > > > >> > > > > >> On Mon, Feb 4, 2019 at 3:06 PM Igor Sapego > > > wrote: > > > > >> > > > > >> > Vladimir, > > > > >> > > > > > >> > So correct me if I'm wrong, what you propose is to avoid > > mentioning > > > > >> > of cache groups, and use instead of "cache group" term something > > > like > > > > >> > "distribution"? Or do you propose some changes in protocol? If > so, > > > can > > > > >> > you briefly explain, what kind of changes they are? > > > > >> > > > > > >> > Best Regards, > > > > >> > Igor > > > > >> > > > > > >> > > > > > >> > On Mon, Feb 4, 2019 at 1:13 PM Vladimir Ozerov < > > > voze...@gridgain.com> > > > > >> > wrote: > > > > >> > > > > > >> > > Igor, > > > > >> > > > > > > >> > > Yes, cache groups are public API. However, we try to avoid new > > > APIs > > > > >> > > depending on them. > > > > >> > > The main point from my side is that “similar cache group” can > be > > > > >> easily > > > > >> > > generalized to “similar distribution”. This way we avoid cache > > > > groups > > > > >> on > > > > >> > > protocol level at virtually no cost. > > > > >> > > > > > > >> > > Vladimir. > > > > >> > > > > > > >> > > пн, 4 февр. 2019 г. в 12:48, Igor Sapego >: > > > > >> > > > > > > >> > > > Guys, > > > > >> > > > > > > > >> > > > Can you explain why do we want to avoid Cache groups in > > > protocol? > > > > >> > > > > > > > >> > > > If it's about simplicity of the protocol, then removing > cache > > > > groups > > > > >> > will > > > > >> > > > not help much with it - we will still need to include > > > > >> "knownCacheIds" > > > > >> > > > field in request and "cachesWithTheSamePartitioning" field > in > > > > >> response. > > > > >> > > > And also, since when do Ignite prefers simplicity over > > > > performance? > > > > >> > > > > > > > >> > > > If it's about not wanting to show internals of Ignite then > it > > > > sounds > > > > >> > like > > > > >> > > > a very weak argument to me, since Cache Groups is a public > > thing > > > > >> [1]. > > > > >> > > > > > > > >> > > > [1] - https://apacheignite.readme.io/docs/cache-groups > > > > >> > > > > > > > >> > > > Best Regards, > >
[jira] [Created] (IGNITE-11503) MVCC: Handle partition loss policies
Ivan Pavlukhin created IGNITE-11503: --- Summary: MVCC: Handle partition loss policies Key: IGNITE-11503 URL: https://issues.apache.org/jira/browse/IGNITE-11503 Project: Ignite Issue Type: Task Components: mvcc Reporter: Ivan Pavlukhin We need to be sure that partition loss policy is properly handled during interaction with MVCC caches. It should be covered by tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [3250903] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New test failure in master DataStreamProcessorMvccPersistenceSelfTest.testCustomUserUpdater https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6637048842291767623=%3Cdefault%3E=testDetails *New test failure in master DataStreamProcessorMvccPersistenceSelfTest.testLocalDataStreamerDedicatedThreadPool https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=759944735770848920=%3Cdefault%3E=testDetails *New test failure in master DataStreamProcessorMvccPersistenceSelfTest.testReplicatedIsolated https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3106704882057752298=%3Cdefault%3E=testDetails *New test failure in master DataStreamProcessorMvccSelfTest.testReplicatedIsolated https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7610274339067283285=%3Cdefault%3E=testDetails *New test failure in master DataStreamProcessorMvccPersistenceSelfTest.testPartitionedMultiThreaded https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7712479474670171747=%3Cdefault%3E=testDetails *New test failure in master DataStreamProcessorMvccPersistenceSelfTest.testLoaderApi https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7960532704015080859=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ilya.kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=877382 - 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 12:50:17 07-03-2019
[MTCGA]: new failures in builds [3250936, 3250899] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testRandomPutGetRemove https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5851024270797597225=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRandomUniqueMultipleObjects https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2669811093134192917=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGroupIndexes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3449538838366747292=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGroupIndexes2 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2955416849020277650=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRandomNonUniqueMultipleObjects https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4723824971707226617=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRemoveMultipleForward https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-396838873773736=%3Cdefault%3E=testDetails *New test failure in master IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGradualRandomPutAllRemoveAll https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2358563154632800532=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ilya.kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=877382 *New stable failure of a flaky test in master CacheFreeListImplSelfTest.testInsertDeleteSingleThreaded_16384 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8113496860340008440=%3Cdefault%3E=testDetails *New stable failure of a flaky test in master CacheFreeListImplSelfTest.testInsertDeleteSingleThreaded_8192 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3061751661531366946=%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 12:35:18 07-03-2019
[MTCGA]: new failures in builds [3250928] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New test failure in master IgniteTxCachePrimarySyncTest.testSingleKeyCommitFromPrimary https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8188960320563412129=%3Cdefault%3E=testDetails *New test failure in master IgniteTxCachePrimarySyncTest.testTxSyncMode https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5425953491606214861=%3Cdefault%3E=testDetails *New test failure in master IgniteTxCachePrimarySyncTest.testSingleKeyPrimaryNodeFail2 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-226594202544241=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ilya.kasnacheev https://ci.ignite.apache.org/viewModification.html?modId=877382 - 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 12:20:16 07-03-2019
[jira] [Created] (IGNITE-11502) Django engine
Nikolai Svistov created IGNITE-11502: Summary: Django engine Key: IGNITE-11502 URL: https://issues.apache.org/jira/browse/IGNITE-11502 Project: Ignite Issue Type: New Feature Reporter: Nikolai Svistov Django supports a standard driver for working with DB. To work with cassandra, there is a driver - [Django Cassandra Engine|https://github.com/r4fek/django-cassandra-engine], but Apache Ignite doesn’t have a driver that allows users to work with Ignite from Django. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11501) Build examples failed with Scala profile and Java11
Sergey Kozlov created IGNITE-11501:
--
Summary: Build examples failed with Scala profile and Java11
Key: IGNITE-11501
URL: https://issues.apache.org/jira/browse/IGNITE-11501
Project: Ignite
Issue Type: Bug
Components: examples
Affects Versions: 2.7
Environment: Open JDK 11.0.1, Windows 10 64bit
Reporter: Sergey Kozlov
Import in IDEA {{examples}/pom.xml} with {{scala}} profile.
The compilation failed:
{noformat}
C:\Java\open-jdk-11.0.1\bin\java.exe
-Dmaven.multiModuleProjectDirectory=C:\Work\apache-ignite-2.7.0-bin\examples
"-Dmaven.home=C:\Program Files\JetBrains\IntelliJ IDEA Community Edition
2018.3.5\plugins\maven\lib\maven3" "-Dclassworlds.conf=C:\Program
Files\JetBrains\IntelliJ IDEA Community Edition
2018.3.5\plugins\maven\lib\maven3\bin\m2.conf" "-javaagent:C:\Program
Files\JetBrains\IntelliJ IDEA Community Edition
2018.3.5\lib\idea_rt.jar=52182:C:\Program Files\JetBrains\IntelliJ IDEA
Community Edition 2018.3.5\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program
Files\JetBrains\IntelliJ IDEA Community Edition
2018.3.5\plugins\maven\lib\maven3\boot\plexus-classworlds-2.5.2.jar"
org.codehaus.classworlds.Launcher -Didea.version=2018.3.5 compile -P scala
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.ignite:ignite-examples:jar:2.7.0
[WARNING] 'build.plugins.plugin.version' for
org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 204, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO]
[INFO] Building ignite-examples 2.7.0
[INFO]
Downloading:
http://h2database.com/m2-repo/commons-codec/commons-codec/maven-metadata.xml
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.199 s
[INFO] Finished at: 2019-03-07T11:17:10+03:00
[INFO] Final Memory: 18M/67M
[INFO]
[ERROR] Failed to execute goal on project ignite-examples: Could not resolve
dependencies for project org.apache.ignite:ignite-examples:jar:2.7.0: Could not
find artifact jdk.tools:jdk.tools:jar:1.6 at specified path
C:\Java\open-jdk-11.0.1/../lib/tools.jar -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
