[MTCGA]: new failures in builds [3160472] 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. *Recently contributed test failed in master internal.GridSpringBeanSerializationSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8768893146029766837=%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 23:10:32 11-03-2019
[jira] [Created] (IGNITE-11523) Can't cast null value from Cassandra table primitive column to primitive value used in domain object model
Xinmin Wang created IGNITE-11523:
Summary: Can't cast null value from Cassandra table primitive
column to primitive value used in domain object model
Key: IGNITE-11523
URL: https://issues.apache.org/jira/browse/IGNITE-11523
Project: Ignite
Issue Type: Bug
Components: cache, cassandra
Affects Versions: 2.7
Reporter: Xinmin Wang
*Issue*
Adding new primitive type columns to the existing tables which have data
existed in
Cassandra causes Ignite to raise an exception (see below) in Ignite 2.7.0 or
2.8.0 nightly build when loading the data from Cassandra into Ignite Cache
store. This works before Ignite 2.6, and even
apache-ignite-fabric-2.7.0.20180918 nightly build.
The assumption seems not correct because both Ignite and Cassandra are (key,
value) store. In fact, SQLLINE tool, we don't need to insert into primitive
value, see the example blow -
CREATE TABLE aa (col1 int PRIMARY KEY, col2 double );
INSERT INTO aa(col1) VALUES (1);
SELECT * FROM aa;
*Root Cause*
This issue is related to the implementation of public static Object
getCassandraColumnValue(Row row, String col, Class clazz, Serializer
serializer) in PropertyMappingHelper.java
([https://github.com/apache/ignite/blob/master/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/common/PropertyMappingHelper.java]).
This class has been changed since 2.7.0. For primitive java type, I don't
think we need to check null value. The assumption is that every row for
primitive types in Cassandra table must have value is not correct.
{panel:title=getCassandraColumnValue(Row row, String col, Class clazz,
Serializer serializer)}
public static Object getCassandraColumnValue(Row row, String col, Class clazz,
Serializer serializer) {
...
if (Long.class.equals(clazz))
return row.isNull(col) ? null : row.getLong(col);
// why needs to check the primitive null. NoSql is a pair of (key, value).
// there is no pair in this case
// all databases (relational databases and NoSql databases support null colum
values)
if (long.class.equals(clazz)) {
if (row.isNull(col)) {
throw new IllegalArgumentException("Can't cast null value from Cassandra table
column '" + col +
"' to " + "long value used in domain object model");
}
return row.getLong(col);
}
}
{panel}
*Detailed Exception*
[2019-03-11
09:44:34,352][ERROR][cassandra-cache-loader-#61%ignite-procurant-purchase-order-cluster%][CassandraCacheStore]
Failed to build Ignite value object from provided Cassandra row
java.lang.IllegalArgumentException: Can't cast null value from Cassandra
table column 'suppliertotamt' to double value used in domain object model
at
org.apache.ignite.cache.store.cassandra.common.PropertyMappingHelper.getCassandraColumnValue(PropertyMappingHelper.java:169)
at
org.apache.ignite.cache.store.cassandra.persistence.PojoField.setValueFromRow(PojoField.java:205)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.buildObject(PersistenceController.java:405)
at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.buildValueObject(PersistenceController.java:227)
at
org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker$1.process(LoadCacheCustomQueryWorker.java:107)
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:402)
at
org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:81)
at
org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:35)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[2019-03-11
09:44:34,360][ERROR][cassandra-cache-loader-#61%ignite-procurant-purchase-order-cluster%][CassandraCacheStore]
Failed to execute Cassandra loadCache operation
class org.apache.ignite.IgniteException: Failed to execute Cassandra
loadCache operation
at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:415)
at
org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:81)
at
org.apache.ignite.cache.store.cassandra.session.LoadCacheCustomQueryWorker.call(LoadCacheCustomQueryWorker.java:35)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
Re: Best Effort Affinity for thin clients
My suggestion is a boolean flag in client configuration: DisableAffinityAwareness And use old random/round-robin behavior with only one active connection. On Mon, Mar 11, 2019 at 1:36 PM Igor Sapego wrote: > Pavel, > > That's right. Do you have other suggestions or objections? > > Best Regards, > Igor > > > On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn > wrote: > > > > maxConnectionNumber parameter > > What's the idea? Follow the Best Effor Affinity logic, but establish up > to > > N connections? > > > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego wrote: > > > > > 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 < > ptupit...@apache.org> > > > > > 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 < > > isap...@apache.org> > > > > > > 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, > > > >
[MTCGA]: new failures in builds [3269313, 3159881, 3157916, 3157778] 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 stable failure of a flaky test in master IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4619901385813836807=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master distributed.IgniteCacheGetRestartTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4856139810793874663=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master http.GridHttpDeploymentSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8313984068492573325=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1829199784039535740=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1736033944635181204=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9168655272383159616=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodeById https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7244515415928378863=%3Cdefault%3E=testDetails Changes may lead to failure were done by - andrey.mashenkov https://ci.ignite.apache.org/viewModification.html?modId=875789 - rodion.vlasov https://ci.ignite.apache.org/viewModification.html?modId=875532 - pvoronkin https://ci.ignite.apache.org/viewModification.html?modId=875525 - mr.weider https://ci.ignite.apache.org/viewModification.html?modId=875782 - ppozerov https://ci.ignite.apache.org/viewModification.html?modId=875014 - alexey.goncharuk https://ci.ignite.apache.org/viewModification.html?modId=875291 - bessonov.ip https://ci.ignite.apache.org/viewModification.html?modId=876310 - ppozerov https://ci.ignite.apache.org/viewModification.html?modId=875821 - ppozerov https://ci.ignite.apache.org/viewModification.html?modId=875308 - vozerov https://ci.ignite.apache.org/viewModification.html?modId=875552 - slava.koptilin https://ci.ignite.apache.org/viewModification.html?modId=875554 - amalykhgh https://ci.ignite.apache.org/viewModification.html?modId=875837 - zaleslaw.sin https://ci.ignite.apache.org/viewModification.html?modId=875839 - ppozerov https://ci.ignite.apache.org/viewModification.html?modId=875326 - vozerov https://ci.ignite.apache.org/viewModification.html?modId=875577 - dmitriy.govorukhin https://ci.ignite.apache.org/viewModification.html?modId=875832 - aplatonovv https://ci.ignite.apache.org/viewModification.html?modId=875835 - verbalab https://ci.ignite.apache.org/viewModification.html?modId=876341 - ivandasch https://ci.ignite.apache.org/viewModification.html?modId=875063 - tledkov https://ci.ignite.apache.org/viewModification.html?modId=875827 - stkuzma https://ci.ignite.apache.org/viewModification.html?modId=875588 - verbalab https://ci.ignite.apache.org/viewModification.html?modId=875590 - irakov https://ci.ignite.apache.org/viewModification.html?modId=876353 - klaster1 https://ci.ignite.apache.org/viewModification.html?modId=875842 - andrey.mashenkov https://ci.ignite.apache.org/viewModification.html?modId=875613 - mr.weider https://ci.ignite.apache.org/viewModification.html?modId=875101 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=875100 - aplatonovv https://ci.ignite.apache.org/viewModification.html?modId=875870 - ppozerov https://ci.ignite.apache.org/viewModification.html?modId=875349 - kaa.dev https://ci.ignite.apache.org/viewModification.html?modId=876116 - antonovsergey93 https://ci.ignite.apache.org/viewModification.html?modId=876375 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=875117 - zaleslaw.sin
[MTCGA]: new failures in builds [3168896, 3167648] 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. *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1736033944635181204=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodeById https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7244515415928378863=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9168655272383159616=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1829199784039535740=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master http.GridHttpDeploymentSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8313984068492573325=%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 19:10:31 11-03-2019
[jira] [Created] (IGNITE-11522) Ignite index in not working in a specific case
Mausam created IGNITE-11522:
---
Summary: Ignite index in not working in a specific case
Key: IGNITE-11522
URL: https://issues.apache.org/jira/browse/IGNITE-11522
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Environment: Red Hat Linux
Reporter: Mausam
Below query is getting frequently fired:
SELECT *
FROM TABLE_A __Z0
WHERE (__Z0.COL_A IN ('DL', 'A'))
AND ((__Z0.COL_B IN('11-W060', '11-W060'))
AND ((__Z0.COL_C IN('HD', 'ED'))
AND ((__Z0.COL_D = '1')
AND ((__Z0.COL_E = '1')
AND (__Z0.COL_F = '1')
Below Index when created on this table is *not working*:
CREATE INDEX CUST_INDEX1
ON TABLE_A
(COL_A ASC, COL_B ASC, COL_C ASC, COL_D ASC, COL_E ASC, COL_F ASC);
Below index is *working perfectly fine:*
CREATE INDEX CUST_INDEX1
ON TABLE_A
(COL_D ASC, COL_A ASC, COL_B ASC, COL_C ASC, COL_E ASC, COL_F ASC);
This is just a change in the ordering. While the first Index is in the same
order as the attributes in the where clause and therefore should have worked,
second one is just in a random order.
On further analysis, it appears that *Index doesn't apply if the first column
of the Index is not an IN clause having multiple values in the Select
statement.*
In the second create index statement, COL_D is the first column which is not an
IN with multiple values in the select clause and hence this is working fine.
It means, if the first column COL_A has only one value 'DL' then it works, but
if it has two values, 'DL' and 'A', the Index doesn't get applied.
This isn't the expected behaviour.
Index should work for both the CREATE INDEX queries, irrespective of number of
values in IN clause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Teamcity Bot DB corrupted (again)
Hi Ignite developers, Unfortunately, AI TC Bot DB is now lost. This means there can be a number of duplicate notifications on issues. I apologize for the inconvenience. I expect after during one day TC Bot DB will be re-loaded from the TC. Sincerely, Dmitriy Pavlov P.S. anticipating questions TC Bot uses 2.7 Bot writes page footer with this info: Apache Ignite TeamCity Bot, V20190307 Powered by Apache Ignite V2.7.0, Java Version: 11.0.1
[MTCGA]: new failures in builds [3222465, 3217217] 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. *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9168655272383159616=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1736033944635181204=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1829199784039535740=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodeById https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7244515415928378863=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master http.GridHttpDeploymentSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8313984068492573325=%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 18:55:31 11-03-2019
[MTCGA]: new failures in builds [3281871, 3281420, 3281282] 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. *Recently contributed test failed in master IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4619901385813836807=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master http.GridHttpDeploymentSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8313984068492573325=%3Cdefault%3E=testDetails No changes in the build *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodeById https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7244515415928378863=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9168655272383159616=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesByIds https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1736033944635181204=%3Cdefault%3E=testDetails *Recently contributed test failed in master IgniteProjectionStartStopRestartSelfTest.testRestartNodesFiltered https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1829199784039535740=%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 18:42:38 11-03-2019
Re: Disk page compression for Ignite persistent store
Hello Igniters! I've implemented compression of WAL page snapshot records. Ticket [1], PR [2]. I've used page compression module implemented by Sergi Vladykin for page store. To configure WAL page records compression there are 2 properties added to DataStorageConfiguration: walPageCompression and walPageCompressionLevel. Unlike page store compression, WAL compression doesn't use sparse files and can be used on any file system (there is also not necessary to enable page store compression to enable WAL page records compression). WAL page snapshot compression is useful and performing best when there are many caches and partitions used by Ignite instance. In this case, page snapshot records take a considerable part of WAL (in my tests it's more than 90% of WAL size). I've done some benchmarks using the yardstick framework and got pretty good results. It's not only WAL size significantly reduced, but there is also an improvement in throughput and latency. I've attached some of the benchmark results to the ticket. Can anyone review the patch? [1]: https://issues.apache.org/jira/browse/IGNITE-11336 [2]: https://github.com/apache/ignite/pull/6116 вт, 20 нояб. 2018 г. в 08:19, Sergi Vladykin : > Denis, > > See inline. > > > пн, 19 нояб. 2018 г. в 20:17, Denis Magda : > > > Hi Sergi, > > > > Didn't know you were cooking this dish in the background ) Excellent. > Just > > to be sure, that's part of this IEP, right? > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-20%3A+Data+Compression+in+Ignite#IEP-20:DataCompressioninIgnite-Withoutin-memorycompression > > > Correct. > > > > > > > > Since we can release only full file system blocks which are typically 4k > > > size, user must configure page size to be at least multiple FS blocks, > > e.g. > > > 8k or 16k. It also means that max compression ratio here is > fsBlockSize / > > > pageSize = 4k / 16k = 0.25 > > > > > > How to we handle the case if the page size is not a multiple of 4K? What > is > > the most optimal page size if the user wants to get the best compression? > > Probably, we can adjust the default page size automatically if it's a > clean > > deployment. > > > > > We already force page size to be between 1k and 16k and to be power of 2. > Thus there are only 2 options greater than 4k: either 8k or 16k. So page > must be just large enough. > > Obviously the greater page size, the better compression you have, but > having very large pages may affect performance badly. Thus 8k with ratio > 0.5 or 16k with ratio 0.25 must be OK for the most of cases. > > > > > There will be 2 new properties on CacheConfiguration > > > (setDiskPageCompression and setDiskPageCompressionLevel) to setup disk > > page > > > compression. > > > > > > How about setting it at DataRegionConfiguration level as well so that > it's > > applied for all the caches/tables from there? > > > > > Does not seem to make much sense until we can tweak page size for different > data regions independently (now we can't). I would start with that one > first. > > Sergi > > > -- > > Denis > > > > On Mon, Nov 19, 2018 at 2:01 AM Sergi Vladykin > > > wrote: > > > > > Folks, > > > > > > I've implemented page compression for persistent store and going to > merge > > > it to master. > > > > > > https://github.com/apache/ignite/pull/5200 > > > > > > Some design notes: > > > > > > It employs "hole punching" approach, it means that the pages are kept > > > uncompressed in memory, > > > but when they get written to disk, they will be compressed and all the > > > extra file system blocks for the page will be released. Thus the > storage > > > files become sparse. > > > > > > Right now we will support 4 compression methods: ZSTD, LZ4, SNAPPY and > > > SKIP_GARBAGE. All of them are self-explaining except SKIP_GARBAGE, > which > > > basically just takes only meaningful data from half-filled pages but > does > > > not apply any compression. It is easy to add more if needed. > > > > > > Since we can release only full file system blocks which are typically > 4k > > > size, user must configure page size to be at least multiple FS blocks, > > e.g. > > > 8k or 16k. It also means that max compression ratio here is > fsBlockSize / > > > pageSize = 4k / 16k = 0.25 > > > > > > It is possible to enable compression for existing databases if they > were > > > configured for large enough page size. In this case pages will be > written > > > to disk in compressed form when updated, and the database will become > > > compressed gradually. > > > > > > There will be 2 new properties on CacheConfiguration > > > (setDiskPageCompression and setDiskPageCompressionLevel) to setup disk > > page > > > compression. > > > > > > Compression dictionaries are not supported at the time, but may in the > > > future. IMO it should be added as a separate feature if needed. > > > > > > The only supported platform for now is Linux. Since all popular file > > > systems support sparse files, it must be relatively easy to support
Re: [MTCGA]: new failures in builds [3250936, 3250899] needs to be handled
It was infra issue, now these and similar tests are passing. чт, 7 мар. 2019 г. в 12:35, : > 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 >
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hi Ignite Developers, I remember I've fixed one case of Corrupted Tree Exception, and this fix still not released. This is DB corruption, and loss of data: if user face with it he/she will probably ban Ignite for him/her preferences forever. If we select 2.7.1 (BTW it is more natural naming of proposed release, here I agree with proposed numbering), we can not ship this and similar fixes made by Igniters. And what is the reason for this? Is it the presence of a number of faulty commits in master? How long does it take us to revert not tested features from ignite-2.8 provided that branch is created from the master? Sincerely, Dmitriy Pavlov пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev : > Hello! > > > - *was hard to start the code samples (same issue as with cmd).* > > - *The step above have to be repeated for every single sample* > > For this issue, do we have any solution at all? I'm afraid you will still > have to add JVM args manually for every main class or test that you run. > > Regards, > -- > Ilya Kasnacheev > > > чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > > Dmitriy, > > > > Please find a copy-paste from the first conversation when impactful > > usability problems were reported more than a month ago: > > > > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > sad:* > > > >- *Starting a node from cmd (ignite.sh) - FAILED* > >- *Opening Ignite examples - BAD EXPERIENCE* > > - *pom.xml wasn't detected automatically, had to select it > manually* > > - *was hard to start the code samples (same issue as with cmd). As > a > > committer, I know how to fix it > > ( > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > < > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >), > > but most of the developers have no glue and will give up* > > - *The step above have to be repeated for every single sample* > > > > Now, imagine that dozens of users new to Ignite go through this. Most of > > them will quit after the failures above and switch to an alternate > solution > > - there are many choices depending on a use case. > > > > Give me a call if it still doesn't sound convincing to you. What I would > > do, considering Vladimirs's feedback, if the master is really in a bad > > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > > released from the master. > > > > - > > Denis > > > > > > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov > wrote: > > > > > 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 < > > > ilya.kasnach...@gmail.com > > > > >: > > > > > > > > > > > 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
[jira] [Created] (IGNITE-11521) Register listeners before joining the cluster
Lukas Polacek created IGNITE-11521: -- Summary: Register listeners before joining the cluster Key: IGNITE-11521 URL: https://issues.apache.org/jira/browse/IGNITE-11521 Project: Ignite Issue Type: New Feature Reporter: Lukas Polacek The documentation says to register local listeners through "ignite.events().localListen(...)", however that can only be done once e.g. "ignite = Ignition.start(cfg)" has been called. At that point, the node has already joined the cluster, so we might have missed events in the meantime. See also the discussion [in apache-ignite-users|http://apache-ignite-users.70518.x6.nabble.com/Register-listeners-before-joining-the-cluster-td25944.html#none]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11520) SQL schema is overwritten by static query entity configuration
Denis Mekhanikov created IGNITE-11520:
-
Summary: SQL schema is overwritten by static query entity
configuration
Key: IGNITE-11520
URL: https://issues.apache.org/jira/browse/IGNITE-11520
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.7, 2.4
Reporter: Denis Mekhanikov
Fix For: 2.8
Steps to reproduce:
1. Start and restart a node with persistence enabled and the following cache
configuration:
{code}
{code}
2. Execute the following DDL statement:
{code}
ALTER TABLE "cache".Person ADD COLUMN lastName varchar;
{code}
3. Restart the node.
After the restart Person table contains only two columns
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Best Effort Affinity for thin clients
Pavel, That's right. Do you have other suggestions or objections? Best Regards, Igor On Fri, Mar 8, 2019 at 11:37 AM Pavel Tupitsyn wrote: > > maxConnectionNumber parameter > What's the idea? Follow the Best Effor Affinity logic, but establish up to > N connections? > > On Thu, Mar 7, 2019 at 1:23 PM Igor Sapego wrote: > > > 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 < > isap...@apache.org> > > > > > 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 г. в
[jira] [Created] (IGNITE-11519) Web Console: Pack configuration tests in test-jar
Andrey Novikov created IGNITE-11519: --- Summary: Web Console: Pack configuration tests in test-jar Key: IGNITE-11519 URL: https://issues.apache.org/jira/browse/IGNITE-11519 Project: Ignite Issue Type: Test Components: wizards Affects Versions: 2.7 Reporter: Andrey Novikov Fix For: 2.8 IGNITE-8145 has introduced tests for covering the configuration. I think it would be better to pack these tests into a test-jar, in order to be able to expand in other modules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11518) SQL: Security checks are skipped on some SELECT paths
Vladimir Ozerov created IGNITE-11518:
Summary: SQL: Security checks are skipped on some SELECT paths
Key: IGNITE-11518
URL: https://issues.apache.org/jira/browse/IGNITE-11518
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Fix For: 2.8
This is regression introduced by IGNITE-11227. Security check should be moved
from {{executeSelectLocal}} to {{executeSelect0}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11517) MVCC: Support one-phase commit
Vladimir Ozerov created IGNITE-11517: Summary: MVCC: Support one-phase commit Key: IGNITE-11517 URL: https://issues.apache.org/jira/browse/IGNITE-11517 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov One-phase commit is critical performance optimization for single-key requests. Our profiling revealed that this is one of the key things why MVCC is much slower than non-MVCC caches. Let's add 1PC support to MVCC. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.8 Release: Time & Scope & Release manager
Hello! > - *was hard to start the code samples (same issue as with cmd).* > - *The step above have to be repeated for every single sample* For this issue, do we have any solution at all? I'm afraid you will still have to add JVM args manually for every main class or test that you run. Regards, -- Ilya Kasnacheev чт, 7 мар. 2019 г. в 21:03, Denis Magda : > Dmitriy, > > Please find a copy-paste from the first conversation when impactful > usability problems were reported more than a month ago: > > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are sad:* > >- *Starting a node from cmd (ignite.sh) - FAILED* >- *Opening Ignite examples - BAD EXPERIENCE* > - *pom.xml wasn't detected automatically, had to select it manually* > - *was hard to start the code samples (same issue as with cmd). As a > committer, I know how to fix it > ( > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > < > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > >), > but most of the developers have no glue and will give up* > - *The step above have to be repeated for every single sample* > > Now, imagine that dozens of users new to Ignite go through this. Most of > them will quit after the failures above and switch to an alternate solution > - there are many choices depending on a use case. > > Give me a call if it still doesn't sound convincing to you. What I would > do, considering Vladimirs's feedback, if the master is really in a bad > shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > released from the master. > > - > Denis > > > On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov wrote: > > > 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 < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > > > 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 < > > dpav...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > > > > > > > In the separate topic, we've touched the question of next > > release > > > > of > > > > > > > Apache > > > > > > > > Ignite. > > > > > > > > > > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 to 2.7.1 release and such releases at future. On Sat, Mar 9, 2019 at 2:14 PM Vyacheslav Daradur wrote: > Denis, > > >> After this release, let's introduce a practice of maintenance > >> releases > > What a reason of waiting for 2.8 to introduce maintenance release? > > Let's prepare 2.7.1 with Java 11 fixes? > Look like this is the safest and fastest way to deliver Java 11 > related improvements to our end-users. > > On Fri, Mar 8, 2019 at 1:35 PM Alexey Zinoviev > wrote: > > > > Dear Denis, I agree, that mentioned fixes should be accessible for > > developers, maybe we could release them as an emergency release 2.7.xxx > or > > another minor version of 2.7, nor 2.8. > > > > And 2.8 could be planned in next 1-2 months with a lot of cool features > > > > > > > > > > > > пт, 8 марта 2019 г., 13:29 Alexey Zinoviev zaleslaw@gmail.com: > > > > > I suggest to make a release from master but at 15 April-1 May to > prepare > > > all release features. It's bad practice to announce release and cut > master > > > in one week. And in future put the approximate date of release for > feature > > > planning. > > > > > > In ML we are in progress of changing API and it takes 1 month to > stabilize > > > that and fix and we hope to deliver that functionality in 2.8. > > > > > > чт, 7 марта 2019 г., 21:03 Denis Magda dma...@apache.org: > > > > > >> Dmitriy, > > >> > > >> Please find a copy-paste from the first conversation when impactful > > >> usability problems were reported more than a month ago: > > >> > > >> *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results are > > >> sad:* > > >> > > >>- *Starting a node from cmd (ignite.sh) - FAILED* > > >>- *Opening Ignite examples - BAD EXPERIENCE* > > >> - *pom.xml wasn't detected automatically, had to select it > manually* > > >> - *was hard to start the code samples (same issue as with cmd). > As a > > >> committer, I know how to fix it > > >> ( > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> < > > >> > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> >), > > >> but most of the developers have no glue and will give up* > > >> - *The step above have to be repeated for every single sample* > > >> > > >> Now, imagine that dozens of users new to Ignite go through this. Most > of > > >> them will quit after the failures above and switch to an alternate > > >> solution > > >> - there are many choices depending on a use case. > > >> > > >> Give me a call if it still doesn't sound convincing to you. What I > would > > >> do, considering Vladimirs's feedback, if the master is really in a bad > > >> shape then I would release 2.8 from 2.7 and 2.8.1, 2.8.2, etc. will be > > >> released from the master. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Thu, Mar 7, 2019 at 9:52 AM Dmitriy Pavlov > wrote: > > >> > > >> > 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 < > voze...@gridgain.com> > > >> > > 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 < > > >> > ilya.kasnach...@gmail.com > > >> > > >: > > >> > > > > > >> > > > > Hello! > > >> > > > > > > >> > > > > Then please fast-forward review and merge > > >> > > > > https://issues.apache.org/jira/browse/IGNITE-11299 because it > > >> breaks > >
[jira] [Created] (IGNITE-11516) MVCC management and monitoring
Vladimir Ozerov created IGNITE-11516: Summary: MVCC management and monitoring Key: IGNITE-11516 URL: https://issues.apache.org/jira/browse/IGNITE-11516 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov This is an umbrella ticket for MVCC management and monitoring capabilities. This should include (but not limited to): # Proper cache metrics (standard cache operations, number of stale versions aka "bloat", etc) # MVCC coordinator metrics (node ID, number of received requests, number of active TXes, current cleanup version, current version, etc) # Cache events (either standard JCache or something else) # Deadlock detector metrics -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11515) MVCC: Make sure that multiple cursors are handled properly for JDBC/ODBC
Vladimir Ozerov created IGNITE-11515: Summary: MVCC: Make sure that multiple cursors are handled properly for JDBC/ODBC Key: IGNITE-11515 URL: https://issues.apache.org/jira/browse/IGNITE-11515 Project: Ignite Issue Type: Bug Components: jdbc, mvcc, odbc Reporter: Vladimir Ozerov Consider the following scenario executed from JDBC/ODBC driver: 1) Open transaction 2) Get a cursor for some large SELECT 3) Close transaction 4) Overwrite some of not-yet-returned values for the cursor 5) Force vacuum 6) Read remaining values from the cursor Will we get correct result? Most probably no, because we close transaction on commit without consulting to any opened cursors. Possible solutions: 1) Extend transaction lifetime until all cursors are closed 2) Or close the cursors forcibly and throw proper error message -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11514) MVCC: Client listener: do not delegate implicit operation execution to separate thread for JDBC/ODBC
Vladimir Ozerov created IGNITE-11514: Summary: MVCC: Client listener: do not delegate implicit operation execution to separate thread for JDBC/ODBC Key: IGNITE-11514 URL: https://issues.apache.org/jira/browse/IGNITE-11514 Project: Ignite Issue Type: Task Components: jdbc, mvcc, odbc Reporter: Vladimir Ozerov If implicit operation over MVCC cache(s) is executed from JDBC/ODBC driver, we always delegate it to a separate thread. But there is no need to do this - once we understand that no active transaction will be left after execution, query could be executed from normal listener thread safely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11513) MVCC: make sure that unsupported features are documented properly
Vladimir Ozerov created IGNITE-11513: Summary: MVCC: make sure that unsupported features are documented properly Key: IGNITE-11513 URL: https://issues.apache.org/jira/browse/IGNITE-11513 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
