[jira] [Resolved] (IGNITE-8407) Wrong memory size printing in IgniteCacheDatabaseSnaredManager
[
https://issues.apache.org/jira/browse/IGNITE-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kalinin resolved IGNITE-8407.
Resolution: Duplicate
> Wrong memory size printing in IgniteCacheDatabaseSnaredManager
> --
>
> Key: IGNITE-8407
> URL: https://issues.apache.org/jira/browse/IGNITE-8407
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Trivial
>
> In checkDataRegionSize regCfg printing in "si" format (based on 1000, not
> 1024). Need to fix it and any other usages of getInitialSize()/getMaxSize())
> with U.readableSize(*, true)
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), true) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), true) + "]"
> {noformat}
> should be replaced with
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), false) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), false) +
> "]"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8407) Wrong memory size printing in IgniteCacheDatabaseSnaredManager
[
https://issues.apache.org/jira/browse/IGNITE-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kalinin closed IGNITE-8407.
--
> Wrong memory size printing in IgniteCacheDatabaseSnaredManager
> --
>
> Key: IGNITE-8407
> URL: https://issues.apache.org/jira/browse/IGNITE-8407
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Trivial
>
> In checkDataRegionSize regCfg printing in "si" format (based on 1000, not
> 1024). Need to fix it and any other usages of getInitialSize()/getMaxSize())
> with U.readableSize(*, true)
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), true) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), true) + "]"
> {noformat}
> should be replaced with
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), false) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), false) +
> "]"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747703#comment-16747703 ] Pavel Voronkin edited comment on IGNITE-10877 at 1/21/19 6:59 AM: -- I don't think it breaks compatibilty, cause we have ignite property to rollback to original behaviour for mixed envs. Moveover GridAffinityAssignment serialization is broken right now. See IGNITE-10925, we need to fix all issues there. was (Author: voropava): I don't think it breaks compatibilty, cause we have ignite property to rollback to original behaviour for mixed envs. Moveover GridAffinityAssignment serialization is broken right now. See IGNITE-10925, we need to fix issue there. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747703#comment-16747703 ] Pavel Voronkin commented on IGNITE-10877: - I don't think it breaks compatibilty, cause we have ignite property to rollback to original behaviour for mixed envs. Moveover GridAffinityAssignment serialization is broken right now. See IGNITE-10925, we need to fix issue there. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10314) Spark dataframe will get wrong schema if user executes add/drop column DDL
[ https://issues.apache.org/jira/browse/IGNITE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747673#comment-16747673 ] Ray Liu commented on IGNITE-10314: -- [~NIzhikov] Thanks for the review, I've fixed the format issue you mentioned. And run the tests again, it's all green. https://ci.ignite.apache.org/viewLog.html?buildId=2857575 > Spark dataframe will get wrong schema if user executes add/drop column DDL > -- > > Key: IGNITE-10314 > URL: https://issues.apache.org/jira/browse/IGNITE-10314 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7 >Reporter: Ray Liu >Assignee: Ray Liu >Priority: Critical > Fix For: 2.8 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > When user performs add/remove column in DDL, Spark will get the old/wrong > schema. > > Analyse > Currently Spark data frame API relies on QueryEntity to construct schema, but > QueryEntity in QuerySchema is a local copy of the original QueryEntity, so > the original QueryEntity is not updated when modification happens. > > Solution > Use GridQueryTypeDescriptor to replace QueryEntity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10992) update Object type value of entry in EntryProcessor within transaction does not work
cc_2019 created IGNITE-10992:
Summary: update Object type value of entry in EntryProcessor
within transaction does not work
Key: IGNITE-10992
URL: https://issues.apache.org/jira/browse/IGNITE-10992
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: cc_2019
I have a value type as below
{color:#80}public class {color}Entity {
String {color:#660e7a}id{color};
String {color:#660e7a}value{color};
Date {color:#660e7a}date{color};
}
then interact with cache as below
{color:#80}try {color}(Transaction tx =
ignite.transactions().txStart(TransactionConcurrency.{color:#660e7a}PESSIMISTIC{color},
TransactionIsolation.{color:#660e7a}SERIALIZABLE{color})) {
cache1.invoke({color:#008000}"k6"{color}, {color:#80}new
{color}EntryProcessor() {
{color:#808000}@Override
{color} {color:#80}public {color}Object process(MutableEntry mutableEntry, Object... objects) {color:#80}throws
{color}EntryProcessorException {
Entity e = mutableEntry.getValue();
e.setId({color:#008000}"hello3"{color});
e.setValue({color:#008000}"v3"{color});
mutableEntry.setValue(e);
{color:#80}return null{color};
}
});
tx.commit();
}
But entry value does not change after commit.
If i code as below, entry value would change after commit.
{color:#80}try {color}(Transaction tx =
ignite.transactions().txStart(TransactionConcurrency.{color:#660e7a}PESSIMISTIC{color},
TransactionIsolation.{color:#660e7a}SERIALIZABLE{color})) {
cache1.invoke({color:#008000}"k6"{color}, {color:#80}new
{color}EntryProcessor() {
{color:#808000}@Override
{color} {color:#80}public {color}Object process(MutableEntry mutableEntry, Object... objects) {color:#80}throws
{color}EntryProcessorException {
mutableEntry.setValue({color:#808080}new Entity("test2", "a2", new
Date()){color});
{color:#80}return null{color};
}
});
tx.commit();
}
I found that changes to entry would not take effect after commit when
mutableEntry.getValue() called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10654) Report in case of creating index with already existing fields collection.
[
https://issues.apache.org/jira/browse/IGNITE-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747490#comment-16747490
]
Stanilovsky Evgeny commented on IGNITE-10654:
-
may be i miss something, but check already exist for predefined index :
{code:java}
private static class Key {
/** */
@QuerySqlField(index = true)
private String keyStr;
{code}
> Report in case of creating index with already existing fields collection.
> -
>
> Key: IGNITE-10654
> URL: https://issues.apache.org/jira/browse/IGNITE-10654
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
>
> Report in log if new index creating with already existing fields collection.
> for example, need to log warn here:
> {code:java}
> cache.query(new SqlFieldsQuery("create index \"idx1\" on Val(keyStr,
> keyLong)"));
> cache.query(new SqlFieldsQuery("create index \"idx3\" on Val(keyStr,
> keyLong)"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10927:
Fix Version/s: 2.8
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-5463) Weird CPU load reported
[
https://issues.apache.org/jira/browse/IGNITE-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kalinin closed IGNITE-5463.
--
> Weird CPU load reported
> ---
>
> Key: IGNITE-5463
> URL: https://issues.apache.org/jira/browse/IGNITE-5463
> Project: Ignite
> Issue Type: Bug
>Reporter: Yakov Zhdanov
>Priority: Minor
> Labels: newbie
>
> {noformat}
> 2017-06-09 16:27:55,827 INFO [IgniteKernal%187358542614215] -
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=56495ffd, name=187358542614215, uptime=00:46:42:936]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=4]
> ^-- CPU [cur=100%, avg=12.85%, GC=125.47%]
> ^-- PageMemory [pages=314674]
> ^-- Heap [used=4777MB, free=12.52%, comm=5461MB]
> ^-- Non heap [used=71MB, free=-1%, comm=77MB]
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=1, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}
> Need to investigate strange numbers reported and fix. My Ignite process had
> no free heap at the moment I noticed that in the logs but OOME was not thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747468#comment-16747468
]
Ignite TC Bot commented on IGNITE-10927:
{panel:title=--> Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2850559&buildTypeId=IgniteTests24Java8_RunAllNightly]
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-5463) Weird CPU load reported
[
https://issues.apache.org/jira/browse/IGNITE-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kalinin resolved IGNITE-5463.
Resolution: Cannot Reproduce
Closed due to lack of response from the creator of the ticket
> Weird CPU load reported
> ---
>
> Key: IGNITE-5463
> URL: https://issues.apache.org/jira/browse/IGNITE-5463
> Project: Ignite
> Issue Type: Bug
>Reporter: Yakov Zhdanov
>Priority: Minor
> Labels: newbie
>
> {noformat}
> 2017-06-09 16:27:55,827 INFO [IgniteKernal%187358542614215] -
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=56495ffd, name=187358542614215, uptime=00:46:42:936]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=4]
> ^-- CPU [cur=100%, avg=12.85%, GC=125.47%]
> ^-- PageMemory [pages=314674]
> ^-- Heap [used=4777MB, free=12.52%, comm=5461MB]
> ^-- Non heap [used=71MB, free=-1%, comm=77MB]
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=1, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}
> Need to investigate strange numbers reported and fix. My Ignite process had
> no free heap at the moment I noticed that in the logs but OOME was not thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747454#comment-16747454
]
Theodore Han commented on IGNITE-10990:
---
I think to will be work if I using SSL lib version 1.0.0
i try
http://apache-ignite-users.70518.x6.nabble.com/ODBC-Driver-compile-error-td23341.html#a23342
> C++ module doesn't compile on ubuntu 18.04
> --
>
> Key: IGNITE-10990
> URL: https://issues.apache.org/jira/browse/IGNITE-10990
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7
> Environment:
>
> {code:java}
> OS : ubuntu 18.04
> GCC: gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
> Configured with: ../src/configure v --with-pkgversion='Ubuntu
> 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c+,go,brig,d,fortran,objc,obj-c+ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none --without-cuda-driver
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> {code}
>
>Reporter: Theodore Han
>Priority: Minor
> Labels: build, newbie
>
> I followed up installation guide in
> [https://apacheignite-cpp.readme.io/docs/getting-started-1]
>
> occurs this error when execute `make` command
> {code:java}
> /root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp # make
> ...
> Making all in odbc
> make[2]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> Making all in include
> make[3]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
> make[3]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> CXX src/ssl/secure_socket_client.lo
> In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
> from src/ssl/secure_socket_client.cpp:25:
> ./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list
> treated as compound expression in initializer [-fpermissive]
> inline int SSL_library_init()
> ^
> In file included from src/ssl/secure_socket_client.cpp:25:0:
> ./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
> before '{' token
> {
> ^
> In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
> from src/ssl/secure_socket_client.cpp:25:
> ./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
> 'OPENSSL_init_ssl' declared void
> inline void SSL_load_error_strings()
> ^
> src/ssl/secure_socket_client.cpp: In static member function 'static void*
> ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
> string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
> src/ssl/secure_socket_client.cpp:206:31: error:
> 'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
> (void)SSL_library_init();
> ^
> src/ssl/secure_socket_client.cpp:208:25: error:
> 'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
> SSL_load_error_strings();
> ^
> src/ssl/secure_socket_client.cpp:237:40: error: 'SSL_CTRL_OPTIONS' was not
> declared in this scope
> ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
> ^~~~
> src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
> 'SQL_SCROLL_OPTIONS'
> ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
> ^~~~
> SQL_SCROLL_OPTIONS
> Makefile:782: recipe for target 'src/ssl/secure_socket_client.lo' failed
> make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
> make[3]: Leaving directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> Makefile:812: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> Makefile:432: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directo
[jira] [Commented] (IGNITE-10314) Spark dataframe will get wrong schema if user executes add/drop column DDL
[ https://issues.apache.org/jira/browse/IGNITE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747446#comment-16747446 ] Nikolay Izhikov commented on IGNITE-10314: -- Hello, [~ldz] Sorry for the pause in the review. Looks good to me! I think this PR is ready to be merged. I left some very minor comments regarding the code formatting. Please, fix them before the merge. Also, please, make sure you use spaces instead of tabs for indenting. package.scala#sqlCacheName package.scala#isValidSchema. > Spark dataframe will get wrong schema if user executes add/drop column DDL > -- > > Key: IGNITE-10314 > URL: https://issues.apache.org/jira/browse/IGNITE-10314 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7 >Reporter: Ray Liu >Assignee: Ray Liu >Priority: Critical > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > When user performs add/remove column in DDL, Spark will get the old/wrong > schema. > > Analyse > Currently Spark data frame API relies on QueryEntity to construct schema, but > QueryEntity in QuerySchema is a local copy of the original QueryEntity, so > the original QueryEntity is not updated when modification happens. > > Solution > Use GridQueryTypeDescriptor to replace QueryEntity -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10991) SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
[
https://issues.apache.org/jira/browse/IGNITE-10991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-10991:
-
Attachment: CacheSqlStreamingAllowOverwriteTest.java
> SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
> --
>
> Key: IGNITE-10991
> URL: https://issues.apache.org/jira/browse/IGNITE-10991
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Priority: Major
> Attachments: CacheSqlStreamingAllowOverwriteTest.java
>
>
> Please see attached test. Repeatedly overwriting same cache entries over and
> over in streaming mode with ALLOW_OVERWRITE ON will cause either:
> {code}
> java.sql.BatchUpdateException: Failed to INSERT some keys because they are
> already in cache [keys=[2054...]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1052)
> ... 1 more
> {code}
> or
> {code}
> WARNING: Exception during batch send on streamed connection close
> java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: Data streamer has been closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1016)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Expecter behavior - no failures, all records overwritten.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10991) SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
Ilya Kasnacheev created IGNITE-10991:
Summary: SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
Key: IGNITE-10991
URL: https://issues.apache.org/jira/browse/IGNITE-10991
Project: Ignite
Issue Type: Bug
Components: jdbc, sql
Affects Versions: 2.6
Reporter: Ilya Kasnacheev
Please see attached test. Repeatedly overwriting same cache entries over and
over in streaming mode with ALLOW_OVERWRITE ON will cause either:
{code}
java.sql.BatchUpdateException: Failed to INSERT some keys because they are
already in cache [keys=[2054...]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1052)
... 1 more
{code}
or
{code}
WARNING: Exception during batch send on streamed connection close
java.sql.BatchUpdateException: class org.apache.ignite.IgniteCheckedException:
Data streamer has been closed.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)
{code}
Expecter behavior - no failures, all records overwritten.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747443#comment-16747443 ] Alexei Scherbakov commented on IGNITE-10877: [~voropava], 1. Please always use bounded maps and sets if you know a size in advance. On example, in *initPrimaryBackupMaps* you should use U.newHashSet(assignmentSize) or even consider using GridLeanMap for maps from 1-5 keys. This should save more of heap size. 2. The compatibility seems broken because you have changed GridAffinityAssignment and it's transffered between nodes in org.apache.ignite.internal.processors.affinity.GridAffinityUtils.AffinityJob. If old node will receive new object it will fail on deserialization. Please create new ticket and address these issues. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10877: -- Ignite Flags: (was: Docs Required) > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10877: -- Fix Version/s: 2.8 > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Fix For: 2.8 > > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png, image-2019-01-18-11-36-57-451.png, > image-2019-01-18-11-38-39-410.png, image-2019-01-18-11-55-39-496.png, > image-2019-01-18-11-56-10-339.png, image-2019-01-18-11-56-18-040.png, > image-2019-01-18-12-09-04-835.png, image-2019-01-18-12-09-32-876.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10054) sqlline hangs with concurrent operations
[
https://issues.apache.org/jira/browse/IGNITE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-10054.
--
Resolution: Not A Problem
> sqlline hangs with concurrent operations
>
>
> Key: IGNITE-10054
> URL: https://issues.apache.org/jira/browse/IGNITE-10054
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Critical
> Attachments: 15828.txt, 16696.txt, ignite-24507fea.0.log,
> ignite-c9ddebdb.0.log
>
>
> 1. Start 2 nodes cluster with PDS (wal_mode=FSYNC), activate
> 2. Start 1st {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> create table t1 (a int, b int, primary key(a)) with
> "atomicity=TRANSACTIONAL_SNAPSHOT,backups=1";
> insert into t1 values (1,1);
> insert into t1 values (2,1);
> insert into t1 values (3,1);
> insert into t1 values (4,1);
> insert into t1 values (5,1);
> insert into t1 values (6,1);
> insert into t1 values (7,1);
> insert into t1 values (8,1);
> insert into t1 values (9,1);
> insert into t1 values (10,1);
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> ...repeat TX many times...
> {noformat}
> 3. Start 2nd {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> ...repeat TX many times...
> {noformat}
> 4. After some time both {{sqlline}} hang:
> {noformat}
> 611/113163 commit;
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082519, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheV
> ersion [topVer=152310006, order=154082519, nodeOrder=1],
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=M
> ARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11
> , label=null]]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 612/113163 begin;
> No rows affected (0 seconds)
> 613/113163 update t1 set b=b+1;
> {noformat}
> {noformat}
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082505, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[
[jira] [Updated] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Theodore Han updated IGNITE-10990:
--
Environment:
{code:java}
OS : ubuntu 18.04
GCC: gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
Configured with: ../src/configure v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c+,go,brig,d,fortran,objc,obj-c+ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
{code}
was:
OS : ubuntu 18.04
GCC: gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
> C++ module doesn't compile on ubuntu 18.04
> --
>
> Key: IGNITE-10990
> URL: https://issues.apache.org/jira/browse/IGNITE-10990
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7
> Environment:
>
> {code:java}
> OS : ubuntu 18.04
> GCC: gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
> Configured with: ../src/configure v --with-pkgversion='Ubuntu
> 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
> --enable-languages=c,ada,c+,go,brig,d,fortran,objc,obj-c+ --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-7
> --program-prefix=x86_64-linux-gnu --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
> --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none --without-cuda-driver
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu
> Thread model: posix
> {code}
>
>Reporter: Theodore Han
>Priority: Minor
> Labels: build, newbie
>
> I followed up installation guide in
> [https://apacheignite-cpp.readme.io/docs/getting-started-1]
>
> occurs this error when execute `make` command
> {code:java}
> /root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp # make
> ...
> Making all in odbc
> make[2]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> Making all in include
> make[3]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
> make[3]: Nothing to be done for 'all'.
> make[3]: Leaving directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
> make[3]: Entering directory
> '/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
> CXX src/ssl/secure_socket_client.lo
> In file included from .
[jira] [Updated] (IGNITE-10066) Missing key and value constraint validation for MVCC tables
[
https://issues.apache.org/jira/browse/IGNITE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10066:
-
Issue Type: Task (was: Bug)
> Missing key and value constraint validation for MVCC tables
> ---
>
> Key: IGNITE-10066
> URL: https://issues.apache.org/jira/browse/IGNITE-10066
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: PetrovMikhail
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> It seems that key and value constraints for MVCC tables are ignoring now when
> code approach is using to operate with table. The same SQL requests work fine.
> It seems that QueryTypeDescriptorImpl.validateKeyAndValue method call which
> provides corresponding constraints is missed now.
>
> Reproducer for not null constraint:
> {code:java}
> public class IgniteCacheTransactionalSnapshotNullConstraintTest extends
> GridCommonAbstractTest {
> private static final String REPLICATED_CACHE_NAME = "replicatedCacheName";
> private static final String PARTITIONED_CACHE_NAME =
> "partitionedCacheName";
> @Override protected void beforeTestsStarted() throws Exception {
> startGrid(0);
> execSQL("CREATE TABLE table(id INT PRIMARY KEY, str VARCHAR NOT NULL)
> WITH \"atomicity=transactional_snapshot\"");
> jcache(grid(0), cacheConfiguration(REPLICATED,
> TRANSACTIONAL_SNAPSHOT), REPLICATED_CACHE_NAME);
> jcache(grid(0), cacheConfiguration(PARTITIONED,
> TRANSACTIONAL_SNAPSHOT), PARTITIONED_CACHE_NAME);
> }
> protected CacheConfiguration cacheConfiguration(CacheMode cacheMode,
> CacheAtomicityMode atomicityMode) {
> CacheConfiguration cfg = new CacheConfiguration();
> cfg.setCacheMode(cacheMode);
> cfg.setAtomicityMode(atomicityMode);
> cfg.setWriteSynchronizationMode(FULL_SYNC);
> cfg.setQueryEntities(Collections.singletonList(new
> QueryEntity(Integer.class, Person.class)));
> return cfg;
> }
> public void testPutNullValueReplicatedModeFail() throws Exception {
> IgniteCache cache = jcache(0, REPLICATED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(0, new Person(null, 25));
> }, IgniteException.class);
> }
> public void testPutNullValuePartitionedModeFail() throws Exception {
> IgniteCache cache = jcache(0,
> PARTITIONED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(1, new Person(null, 18));
> }, IgniteException.class);
> }
> public void testPutNullValueSQLFail() throws Exception {
> checkSQLThrows("INSERT INTO table VALUES(?, ?)", NULL_VALUE, 0, null);
> }
> public static class Person implements Serializable {
> @QuerySqlField(notNull = true)
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> private void checkSQLThrows(String sql, String sqlStateCode, Object...
> args) {
> IgniteSQLException err =
> (IgniteSQLException)GridTestUtils.assertThrowsWithCause(() -> {
> execSQL(sql, args);
> return 0;
> }, IgniteSQLException.class);
> assertEquals((err).sqlState(), sqlStateCode);
> }
> private List execSQL(String sql, Object... args) {
> SqlFieldsQuery qry = new SqlFieldsQuery(sql)
> .setArgs(args);
> return grid(0).context().query().querySqlFields(qry, true).getAll();
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Theodore Han updated IGNITE-10990:
--
Description:
I followed up installation guide in
[https://apacheignite-cpp.readme.io/docs/getting-started-1]
occurs this error when execute `make` command
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: {color:#ff}error:
expression list treated as compound expression in initializer
[-fpermissive]{color}
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: {color:#ff}error:
expected ',' or ';' before '{' token{color}
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: {color:#ff}error:
variable or field 'OPENSSL_init_ssl' declared void{color}
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: {color:#ff}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function{color}
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: {color:#ff}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function{color}
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: {color:#ff}error:
'SSL_CTRL_OPTIONS' was not declared in this scope{color}
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
'SQL_SCROLL_OPTIONS'
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
SQL_SCROLL_OPTIONS
{color:#ff}Makefile:782: recipe for target
'src/ssl/secure_socket_client.lo' failed{color}
make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:812: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:432: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp'
Makefile:364: recipe for target 'all' failed
make: *** [all] Error 2
was:
I followed up installation guide in
https://apacheignite-cpp.readme.io/docs/getting-started-1
occurs this error when `make`
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: {color:#FF}error:
expression list treated as compound expression in initializer
[-fpermissive]{color}
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: {color:#FF}error: expected
',' or ';' before '{' token{color}
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: {color:#FF}error: variable
or field 'OPENSSL_init_ssl' declared void{color}
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: {color:#FF}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' can
[jira] [Created] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
Theodore Han created IGNITE-10990:
-
Summary: C++ module doesn't compile on ubuntu 18.04
Key: IGNITE-10990
URL: https://issues.apache.org/jira/browse/IGNITE-10990
Project: Ignite
Issue Type: Bug
Components: build
Affects Versions: 2.7
Environment: OS : ubuntu 18.04
GCC: gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Reporter: Theodore Han
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list treated
as compound expression in initializer [-fpermissive]
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
before '{' token
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
'OPENSSL_init_ssl' declared void
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: error: 'SSL_CTRL_OPTIONS' was not
declared in this scope
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
'SQL_SCROLL_OPTIONS'
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
SQL_SCROLL_OPTIONS
Makefile:782: recipe for target 'src/ssl/secure_socket_client.lo' failed
make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:812: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:432: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp'
Makefile:364: recipe for target 'all' failed
make: *** [all] Error 2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10970:
-
Issue Type: Improvement (was: Bug)
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10066) Missing key and value constraint validation for MVCC tables
[
https://issues.apache.org/jira/browse/IGNITE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10066:
-
Labels: (was: mvcc_stabilization_stage_1 transactions)
> Missing key and value constraint validation for MVCC tables
> ---
>
> Key: IGNITE-10066
> URL: https://issues.apache.org/jira/browse/IGNITE-10066
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: PetrovMikhail
>Priority: Major
> Fix For: 2.8
>
>
> It seems that key and value constraints for MVCC tables are ignoring now when
> code approach is using to operate with table. The same SQL requests work fine.
> It seems that QueryTypeDescriptorImpl.validateKeyAndValue method call which
> provides corresponding constraints is missed now.
>
> Reproducer for not null constraint:
> {code:java}
> public class IgniteCacheTransactionalSnapshotNullConstraintTest extends
> GridCommonAbstractTest {
> private static final String REPLICATED_CACHE_NAME = "replicatedCacheName";
> private static final String PARTITIONED_CACHE_NAME =
> "partitionedCacheName";
> @Override protected void beforeTestsStarted() throws Exception {
> startGrid(0);
> execSQL("CREATE TABLE table(id INT PRIMARY KEY, str VARCHAR NOT NULL)
> WITH \"atomicity=transactional_snapshot\"");
> jcache(grid(0), cacheConfiguration(REPLICATED,
> TRANSACTIONAL_SNAPSHOT), REPLICATED_CACHE_NAME);
> jcache(grid(0), cacheConfiguration(PARTITIONED,
> TRANSACTIONAL_SNAPSHOT), PARTITIONED_CACHE_NAME);
> }
> protected CacheConfiguration cacheConfiguration(CacheMode cacheMode,
> CacheAtomicityMode atomicityMode) {
> CacheConfiguration cfg = new CacheConfiguration();
> cfg.setCacheMode(cacheMode);
> cfg.setAtomicityMode(atomicityMode);
> cfg.setWriteSynchronizationMode(FULL_SYNC);
> cfg.setQueryEntities(Collections.singletonList(new
> QueryEntity(Integer.class, Person.class)));
> return cfg;
> }
> public void testPutNullValueReplicatedModeFail() throws Exception {
> IgniteCache cache = jcache(0, REPLICATED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(0, new Person(null, 25));
> }, IgniteException.class);
> }
> public void testPutNullValuePartitionedModeFail() throws Exception {
> IgniteCache cache = jcache(0,
> PARTITIONED_CACHE_NAME);
> assertThrowsWithCause(() -> {
> cache.put(1, new Person(null, 18));
> }, IgniteException.class);
> }
> public void testPutNullValueSQLFail() throws Exception {
> checkSQLThrows("INSERT INTO table VALUES(?, ?)", NULL_VALUE, 0, null);
> }
> public static class Person implements Serializable {
> @QuerySqlField(notNull = true)
> private String name;
> @QuerySqlField
> private int age;
> public Person(String name, int age) {
> this.name = name;
> this.age = age;
> }
> }
> private void checkSQLThrows(String sql, String sqlStateCode, Object...
> args) {
> IgniteSQLException err =
> (IgniteSQLException)GridTestUtils.assertThrowsWithCause(() -> {
> execSQL(sql, args);
> return 0;
> }, IgniteSQLException.class);
> assertEquals((err).sqlState(), sqlStateCode);
> }
> private List execSQL(String sql, Object... args) {
> SqlFieldsQuery qry = new SqlFieldsQuery(sql)
> .setArgs(args);
> return grid(0).context().query().querySqlFields(qry, true).getAll();
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10807) MVCC: Support long-running tx rollback on PME
[
https://issues.apache.org/jira/browse/IGNITE-10807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10807:
-
Issue Type: Task (was: Bug)
> MVCC: Support long-running tx rollback on PME
> -
>
> Key: IGNITE-10807
> URL: https://issues.apache.org/jira/browse/IGNITE-10807
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> Currently long-running tx rollback on PME does not work for MVCC
> transactions.
> {{org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTopologyChangeTest#testRollbackOnTopologyChange}}
> can be used as starting point. Also tx recovery (on node failures) can have
> some issues causing troubles in aforementioned test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Theodore Han updated IGNITE-10990:
--
Description:
I followed up installation guide in
[https://apacheignite-cpp.readme.io/docs/getting-started-1]
occurs this error when execute `make` command
{code:java}
/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp # make
...
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list treated
as compound expression in initializer [-fpermissive]
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
before '{' token
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
'OPENSSL_init_ssl' declared void
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: error: 'SSL_CTRL_OPTIONS' was not
declared in this scope
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
'SQL_SCROLL_OPTIONS'
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
SQL_SCROLL_OPTIONS
Makefile:782: recipe for target 'src/ssl/secure_socket_client.lo' failed
make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:812: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:432: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp'
Makefile:364: recipe for target 'all' failed
make: *** [all] Error 2
{code}
was:
I followed up installation guide in
[https://apacheignite-cpp.readme.io/docs/getting-started-1]
occurs this error when execute `make` command
{code:java}
$ make
...
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list treated
as compound expression in initializer [-fpermissive]
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
before '{' token
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
'OPENSSL_init_ssl' declared void
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used a
[jira] [Updated] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Theodore Han updated IGNITE-10990:
--
Description:
I followed up installation guide in
[https://apacheignite-cpp.readme.io/docs/getting-started-1]
occurs this error when execute `make` command
{code:java}
$ make
...
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list treated
as compound expression in initializer [-fpermissive]
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
before '{' token
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
'OPENSSL_init_ssl' declared void
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: error: 'SSL_CTRL_OPTIONS' was not
declared in this scope
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
'SQL_SCROLL_OPTIONS'
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
SQL_SCROLL_OPTIONS
Makefile:782: recipe for target 'src/ssl/secure_socket_client.lo' failed
make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:812: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:432: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp'
Makefile:364: recipe for target 'all' failed
make: *** [all] Error 2
{code}
was:
I followed up installation guide in
[https://apacheignite-cpp.readme.io/docs/getting-started-1]
occurs this error when execute `make` command
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: {color:#ff}error:
expression list treated as compound expression in initializer
[-fpermissive]{color}
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: {color:#ff}error:
expected ',' or ';' before '{' token{color}
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: {color:#ff}error:
variable or field 'OPENSSL_init_ssl' declared void{color}
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: {color:#ff}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function{color}
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: {color:#ff}error:
'
[jira] [Updated] (IGNITE-10841) Edge-chasing deadlock detection monitoring
[ https://issues.apache.org/jira/browse/IGNITE-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10841: - Issue Type: Task (was: Bug) > Edge-chasing deadlock detection monitoring > -- > > Key: IGNITE-10841 > URL: https://issues.apache.org/jira/browse/IGNITE-10841 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Ivan Pavlukhin >Priority: Major > > A deadlock detection process introduces several effects in the system which > should be visible for an administrator. Here are couple of such effects: > 1. Rolling back deadlocked transactions. > 2. Introducing messaging overhead even in case when there are not deadlocks. > Several metrics can be exposed via JMX and/or SQL view. Here are some > candidates: > 1. Number of detected deadlocks and involved transactions. > 2. Sent/received deadlock detection messages count. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10972) MERGE INTO hangs in MVCC mode with unsorted keys
[ https://issues.apache.org/jira/browse/IGNITE-10972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747416#comment-16747416 ] Vladimir Ozerov commented on IGNITE-10972: -- [~ilyak], this is incorrect assumption - deadlocks are equally possible in MVCC mode. > MERGE INTO hangs in MVCC mode with unsorted keys > > > Key: IGNITE-10972 > URL: https://issues.apache.org/jira/browse/IGNITE-10972 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Attachments: CacheMvccMergeConflictTest.java > > > right now, if you perform repeatedly > MERGE INTO T(K, V) VALUES(k1, v1), (k2, v2), (k3, v3); > and in parallel > MERGE INTO T(K, V) VALUES(k2, v2), (k1, v1); > you will eventually see a deadlock. This is expected behavior as per old > putAll behavior, but the expectation is that you should see "Cannot serialize > transaction" errors instead of deadlock when using MVCC. > When doing MERGE INTO with sorted keys you will not get deadlock but will see > a lot of "Cannot serialize transaction" exception with expectation that such > statements to not conflict instead since they are ordered. > Please see attached test and userlist discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10972) MERGE INTO hangs in MVCC mode with unsorted keys
[ https://issues.apache.org/jira/browse/IGNITE-10972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10972: - Issue Type: Task (was: Bug) > MERGE INTO hangs in MVCC mode with unsorted keys > > > Key: IGNITE-10972 > URL: https://issues.apache.org/jira/browse/IGNITE-10972 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Attachments: CacheMvccMergeConflictTest.java > > > right now, if you perform repeatedly > MERGE INTO T(K, V) VALUES(k1, v1), (k2, v2), (k3, v3); > and in parallel > MERGE INTO T(K, V) VALUES(k2, v2), (k1, v1); > you will eventually see a deadlock. This is expected behavior as per old > putAll behavior, but the expectation is that you should see "Cannot serialize > transaction" errors instead of deadlock when using MVCC. > When doing MERGE INTO with sorted keys you will not get deadlock but will see > a lot of "Cannot serialize transaction" exception with expectation that such > statements to not conflict instead since they are ordered. > Please see attached test and userlist discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10597) MVCC TX: Organize used thread pools
[ https://issues.apache.org/jira/browse/IGNITE-10597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10597: - Issue Type: Task (was: Bug) > MVCC TX: Organize used thread pools > --- > > Key: IGNITE-10597 > URL: https://issues.apache.org/jira/browse/IGNITE-10597 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.8 > > > All mvcc operations use cache pool, this means striped pool is used under > hood that may lead performance issues in case of long operations (like query > update). > we need: > 1) use query pool for query updates > 2) use random stripe for batched updates > 3) use appropriate stripe for single updates. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10990) C++ module doesn't compile on ubuntu 18.04
[
https://issues.apache.org/jira/browse/IGNITE-10990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Theodore Han updated IGNITE-10990:
--
Description:
I followed up installation guide in
https://apacheignite-cpp.readme.io/docs/getting-started-1
occurs this error when `make`
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: {color:#FF}error:
expression list treated as compound expression in initializer
[-fpermissive]{color}
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: {color:#FF}error: expected
',' or ';' before '{' token{color}
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: {color:#FF}error: variable
or field 'OPENSSL_init_ssl' declared void{color}
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: {color:#FF}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function{color}
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: {color:#FF}error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function{color}
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: {color:#FF}error:
'SSL_CTRL_OPTIONS' was not declared in this scope{color}
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
src/ssl/secure_socket_client.cpp:237:40: note: suggested alternative:
'SQL_SCROLL_OPTIONS'
ssl::SSL_CTX_ctrl(ctx, SSL_CTRL_OPTIONS, flags, NULL);
^~~~
SQL_SCROLL_OPTIONS
{color:#FF}Makefile:782: recipe for target
'src/ssl/secure_socket_client.lo' failed{color}
make[3]: *** [src/ssl/secure_socket_client.lo] Error 1
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:812: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Makefile:432: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp'
Makefile:364: recipe for target 'all' failed
make: *** [all] Error 2
was:
Making all in odbc
make[2]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
Making all in include
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc/include'
make[3]: Entering directory
'/root/tmp/apache-ignite-2.7.0-src/modules/platforms/cpp/odbc'
CXX src/ssl/secure_socket_client.lo
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:133:24: error: expression list treated
as compound expression in initializer [-fpermissive]
inline int SSL_library_init()
^
In file included from src/ssl/secure_socket_client.cpp:25:0:
./include/ignite/odbc/ssl/ssl_bindings.h:134:13: error: expected ',' or ';'
before '{' token
{
^
In file included from ./include/ignite/odbc/ssl/ssl_bindings.h:21:0,
from src/ssl/secure_socket_client.cpp:25:
./include/ignite/odbc/ssl/ssl_bindings.h:142:25: error: variable or field
'OPENSSL_init_ssl' declared void
inline void SSL_load_error_strings()
^
src/ssl/secure_socket_client.cpp: In static member function 'static void*
ignite::odbc::ssl::SecureSocketClient::MakeContext(const string&, const
string&, const string&, ignite::odbc::diagnostic::Diagnosable&)':
src/ssl/secure_socket_client.cpp:206:31: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
(void)SSL_library_init();
^
src/ssl/secure_socket_client.cpp:208:25: error:
'ignite::odbc::ssl::OPENSSL_init_ssl' cannot be used as a function
SSL_load_error_strings();
^
src/ssl/secure_socket_client.cpp:237:40: error: 'SSL_CTRL_OPTIONS' was not
decl
[jira] [Commented] (IGNITE-8283) CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747415#comment-16747415
]
prehistoricpenguin commented on IGNITE-8283:
@[~isapego]
Hi Igor, I have all the comments and PRs in the parent task. I am a little
confused, the c++ source code lacks the class _BinaryConfiguration,_ which is
located in the Java and C# source. So I need to create the class myself?
cc [~daradurvs]
> CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
> ---
>
> Key: IGNITE-8283
> URL: https://issues.apache.org/jira/browse/IGNITE-8283
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Daradur
>Assignee: prehistoricpenguin
>Priority: Major
> Fix For: 2.8
>
>
> Need to finish the solution that has been prepared into IGNITE-5153 to be
> configurable via {{BinaryConfiguration}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-10054) sqlline hangs with concurrent operations
[
https://issues.apache.org/jira/browse/IGNITE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-10054.
> sqlline hangs with concurrent operations
>
>
> Key: IGNITE-10054
> URL: https://issues.apache.org/jira/browse/IGNITE-10054
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Critical
> Attachments: 15828.txt, 16696.txt, ignite-24507fea.0.log,
> ignite-c9ddebdb.0.log
>
>
> 1. Start 2 nodes cluster with PDS (wal_mode=FSYNC), activate
> 2. Start 1st {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> create table t1 (a int, b int, primary key(a)) with
> "atomicity=TRANSACTIONAL_SNAPSHOT,backups=1";
> insert into t1 values (1,1);
> insert into t1 values (2,1);
> insert into t1 values (3,1);
> insert into t1 values (4,1);
> insert into t1 values (5,1);
> insert into t1 values (6,1);
> insert into t1 values (7,1);
> insert into t1 values (8,1);
> insert into t1 values (9,1);
> insert into t1 values (10,1);
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> ...repeat TX many times...
> {noformat}
> 3. Start 2nd {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> ...repeat TX many times...
> {noformat}
> 4. After some time both {{sqlline}} hang:
> {noformat}
> 611/113163 commit;
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082519, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheV
> ersion [topVer=152310006, order=154082519, nodeOrder=1],
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=M
> ARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11
> , label=null]]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 612/113163 begin;
> No rows affected (0 seconds)
> 613/113163 update t1 set b=b+1;
> {noformat}
> {noformat}
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082505, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6
[jira] [Updated] (IGNITE-10054) sqlline hangs with concurrent operations
[
https://issues.apache.org/jira/browse/IGNITE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10054:
-
Fix Version/s: (was: 2.8)
> sqlline hangs with concurrent operations
>
>
> Key: IGNITE-10054
> URL: https://issues.apache.org/jira/browse/IGNITE-10054
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Critical
> Attachments: 15828.txt, 16696.txt, ignite-24507fea.0.log,
> ignite-c9ddebdb.0.log
>
>
> 1. Start 2 nodes cluster with PDS (wal_mode=FSYNC), activate
> 2. Start 1st {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> create table t1 (a int, b int, primary key(a)) with
> "atomicity=TRANSACTIONAL_SNAPSHOT,backups=1";
> insert into t1 values (1,1);
> insert into t1 values (2,1);
> insert into t1 values (3,1);
> insert into t1 values (4,1);
> insert into t1 values (5,1);
> insert into t1 values (6,1);
> insert into t1 values (7,1);
> insert into t1 values (8,1);
> insert into t1 values (9,1);
> insert into t1 values (10,1);
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> ...repeat TX many times...
> {noformat}
> 3. Start 2nd {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> ...repeat TX many times...
> {noformat}
> 4. After some time both {{sqlline}} hang:
> {noformat}
> 611/113163 commit;
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082519, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheV
> ersion [topVer=152310006, order=154082519, nodeOrder=1],
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=M
> ARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11
> , label=null]]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 612/113163 begin;
> No rows affected (0 seconds)
> 613/113163 update t1 set b=b+1;
> {noformat}
> {noformat}
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082505, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLoca
[jira] [Commented] (IGNITE-10054) sqlline hangs with concurrent operations
[
https://issues.apache.org/jira/browse/IGNITE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747414#comment-16747414
]
Vladimir Ozerov commented on IGNITE-10054:
--
Expected for now. Deadlock handling will be introduced in IGNITE-9322.
> sqlline hangs with concurrent operations
>
>
> Key: IGNITE-10054
> URL: https://issues.apache.org/jira/browse/IGNITE-10054
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: 15828.txt, 16696.txt, ignite-24507fea.0.log,
> ignite-c9ddebdb.0.log
>
>
> 1. Start 2 nodes cluster with PDS (wal_mode=FSYNC), activate
> 2. Start 1st {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> create table t1 (a int, b int, primary key(a)) with
> "atomicity=TRANSACTIONAL_SNAPSHOT,backups=1";
> insert into t1 values (1,1);
> insert into t1 values (2,1);
> insert into t1 values (3,1);
> insert into t1 values (4,1);
> insert into t1 values (5,1);
> insert into t1 values (6,1);
> insert into t1 values (7,1);
> insert into t1 values (8,1);
> insert into t1 values (9,1);
> insert into t1 values (10,1);
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> ...repeat TX many times...
> {noformat}
> 3. Start 2nd {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> ...repeat TX many times...
> {noformat}
> 4. After some time both {{sqlline}} hang:
> {noformat}
> 611/113163 commit;
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082519, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheV
> ersion [topVer=152310006, order=154082519, nodeOrder=1],
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=M
> ARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11
> , label=null]]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 612/113163 begin;
> No rows affected (0 seconds)
> 613/113163 update t1 set b=b+1;
> {noformat}
> {noformat}
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082505, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL sta
[jira] [Updated] (IGNITE-10054) sqlline hangs with concurrent operations
[
https://issues.apache.org/jira/browse/IGNITE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10054:
-
Labels: (was: mvcc_stabilization_stage_1 transactions)
> sqlline hangs with concurrent operations
>
>
> Key: IGNITE-10054
> URL: https://issues.apache.org/jira/browse/IGNITE-10054
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: 15828.txt, 16696.txt, ignite-24507fea.0.log,
> ignite-c9ddebdb.0.log
>
>
> 1. Start 2 nodes cluster with PDS (wal_mode=FSYNC), activate
> 2. Start 1st {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> create table t1 (a int, b int, primary key(a)) with
> "atomicity=TRANSACTIONAL_SNAPSHOT,backups=1";
> insert into t1 values (1,1);
> insert into t1 values (2,1);
> insert into t1 values (3,1);
> insert into t1 values (4,1);
> insert into t1 values (5,1);
> insert into t1 values (6,1);
> insert into t1 values (7,1);
> insert into t1 values (8,1);
> insert into t1 values (9,1);
> insert into t1 values (10,1);
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> begin;
> update t1 set b=b+1;
> commit;
> ...repeat TX many times...
> {noformat}
> 3. Start 2nd {{bin/sqlline}} with following commands (in batch file):
> {noformat}
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> begin;
> update t1 set b=b-1;
> commit;
> ...repeat TX many times...
> {noformat}
> 4. After some time both {{sqlline}} hang:
> {noformat}
> 611/113163 commit;
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082519, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it has bee
> n rolled back [timeout=0,
> tx=GridNearTxLocal[xid=f91ff90c661--0914-10f6--0001,
> xidVersion=GridCacheV
> ersion [topVer=152310006, order=154082519, nodeOrder=1],
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=M
> ARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11
> , label=null]]]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 612/113163 begin;
> No rows affected (0 seconds)
> 613/113163 update t1 set b=b+1;
> {noformat}
> {noformat}
> Error: Failed to execute DDL statement [stmt=commit, err=Failed to finish
> transaction because it has been rolled back [t
> imeout=0,
> tx=GridNearTxLocal[xid=191ff90c661--0914-10f6--0001,
> xidVersion=GridCacheVersion [topVer=1
> 52310006, order=154082505, nodeOrder=1], concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, state=MARKED_ROLLBACK,
> invalidate=false, rollbackOnly=true,
> nodeId=c9ddebdb-c328-4283-97c5-a663887a, timeout=0, duration=11,
> label=null]]]
> (state=5,code=1)
> java.sql.SQLException: Failed to execute DDL statement [stmt=commit,
> err=Failed to finish transaction because it
[jira] [Updated] (IGNITE-7265) BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
[
https://issues.apache.org/jira/browse/IGNITE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7265:
Labels: pagememory (was: mvcc_stabilization_stage_1 pagememory)
> BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
>
>
> Key: IGNITE-7265
> URL: https://issues.apache.org/jira/browse/IGNITE-7265
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: pagememory
> Fix For: 2.8
>
>
> {code}
> java.lang.AssertionError: Assertion error on row: 26
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2221)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2156)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.iterateConcurrentPutRemove(BPlusTreeSelfTest.java:2202)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.testIterateConcurrentPutRemove_1(BPlusTreeSelfTest.java:2169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2008)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1923)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError: 27
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.setLevelsCount(BPlusMetaIO.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.addRoot(BPlusMetaIO.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:661)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:650)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:241)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$10500(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertWithSplit(BPlusTree.java:3073)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:2949)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:420)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:401)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5153)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5138)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11100(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3143)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2464)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2185)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7265) BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
[
https://issues.apache.org/jira/browse/IGNITE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7265:
Component/s: (was: mvcc)
> BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
>
>
> Key: IGNITE-7265
> URL: https://issues.apache.org/jira/browse/IGNITE-7265
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, pagememory
> Fix For: 2.8
>
>
> {code}
> java.lang.AssertionError: Assertion error on row: 26
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2221)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2156)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.iterateConcurrentPutRemove(BPlusTreeSelfTest.java:2202)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.testIterateConcurrentPutRemove_1(BPlusTreeSelfTest.java:2169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2008)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1923)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError: 27
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.setLevelsCount(BPlusMetaIO.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.addRoot(BPlusMetaIO.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:661)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:650)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:241)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$10500(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertWithSplit(BPlusTree.java:3073)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:2949)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:420)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:401)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5153)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5138)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11100(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3143)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2464)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2185)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747412#comment-16747412
]
Ignite TC Bot commented on IGNITE-10927:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 1{color} [[tests 0 JVM CRASH , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2850548]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2850552&buildTypeId=IgniteTests24Java8_RunAll]
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10347:
Assignee: Vladimir Ozerov (was: Yury Gerzhedovich)
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-29, sql
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747413#comment-16747413
]
Vladimir Ozerov commented on IGNITE-10347:
--
[~jooger], my comments:
# This view expose only local running queries. There will be more such views
with local-only info, along with views, which collect info from the whole
cluster. Hence, we need a prefix to distinguish local from non-local stuff
# From what I understand, this view is concernted only about SQL queries, so
this should be reflected in the name as well. Taking this and previous points
in count, I would name the view {{LOCAL_SQL_RUNNING_QUERIES}} or
{LOCAL_SQL_QUERIES}}
# Do we really need {{NODE_ID}} for local view? IMO it is not necessary
# Query ID should not be manipulated anyhow inside the view. Instead, correct
string representation of query ID should already be prepared inside indexing.
# Not sure if we need any special mechanics for duration ranges. H2 already
will do all necessary stuff for us, so why bother? Note that
{{GridQueryProcessor#runningQueries}} method with {{long}} parameter was
created long ago and for completely different purpose - to report long-running
queries. No need to rely on it, we are free to create our own overload which
will return all running queries
# Why do we need to perform any HEX manipulations on query ID parts? It doesn't
add any clarity to user, neither seem to add any other value.
# Please confirm that non-SQL queries are filtered out in the view. I cannot
find relevant code.
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747411#comment-16747411
]
Ignite TC Bot commented on IGNITE-10758:
{panel:title=--> Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2842753&buildTypeId=IgniteTests24Java8_RunAllNightly]
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10347:
Assignee: Yury Gerzhedovich (was: Vladimir Ozerov)
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747407#comment-16747407
]
Vladimir Ozerov commented on IGNITE-10688:
--
NB: There is no ticket for SQL indexes view. It should be created and completed
after IGNITE-10784 is ready.
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose two system SQL views to be able view statistics for indexes
> and cache group caches.
>
> 1) STATIO_CACHE_GRP
> {quote}cache_grp_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages{quote}
> 2) STATIO_IDX
> {quote}cache_grp_name - Name of cache group{quote}
> {quote}idx_name - Name of index
> physical_read - Common number of physical reads of pages for
> the index
> logical_read - Common number of logical reads of pages for
> the index{quote}
> {quote}leaf_logical_read - Number of logical reads of index leaf
> pages{quote}
> {quote}leaf_physical_read - Number of physical reads of index leaf
> pages{quote}
> {quote}inner_logical_read - Number of logical reads of index inner
> pages{quote}
> {quote}inner_physical_read - Number of physical reads of index leaf
> pages{quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10688) Expose SQL views for IO statistics
[
https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747406#comment-16747406
]
Vladimir Ozerov commented on IGNITE-10688:
--
[~jooger], my comments:
# Why do we use strange {{statio}} prefix? Is it taken from other database? To
me it would be much more clear to have e.g. {{CACHE_GROUP_IO}} next to already
existing {{CACHE_GROUP}} view
# Same question to column names - why {{CACHE_GRP_NAME}}, while base view
{{CACHE_GROUPS}} has {{ID}} and {{GROUP_NAME}} columns? Let's add the same
columns to allow for intuitive joins on either {{ID} or {{GROUP_NAME}} fields.
# Could you please confirm that cache groups without any operations performed
on them will still return a row with zero statistics? This should be the case
because otherwise users will get missing rows when trying to join base
{{CACHE_GROUPS}} view with the new one
# Having SQL index IO stats view before we implemented SQL indexes view looks a
bit prematurely to me. Because we do not know yet how indexes will be exposed,
and how are we going to join groups, caches, tables, indexes and stats.
Note that {{CACHE_GROUP.ID}} is not very good naming actually. Instead, it
would be better to name it {{CACHE_GROUP.GROUP_NAME}}, so may be we'd better to
use {{GROUP_NAME}} in out view.
> Expose SQL views for IO statistics
> --
>
> Key: IGNITE-10688
> URL: https://issues.apache.org/jira/browse/IGNITE-10688
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-27
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As of now no such way to get IO statistics through SQL.
> Need to expose two system SQL views to be able view statistics for indexes
> and cache group caches.
>
> 1) STATIO_CACHE_GRP
> {quote}cache_grp_name - Name of cache group
> physical_read - Number of physical read of pages
> logical_read - Number of logical read of pages{quote}
> 2) STATIO_IDX
> {quote}cache_grp_name - Name of cache group{quote}
> {quote}idx_name - Name of index
> physical_read - Common number of physical reads of pages for
> the index
> logical_read - Common number of logical reads of pages for
> the index{quote}
> {quote}leaf_logical_read - Number of logical reads of index leaf
> pages{quote}
> {quote}leaf_physical_read - Number of physical reads of index leaf
> pages{quote}
> {quote}inner_logical_read - Number of logical reads of index inner
> pages{quote}
> {quote}inner_physical_read - Number of physical reads of index leaf
> pages{quote}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747402#comment-16747402
]
Vladimir Ozerov commented on IGNITE-10754:
--
[~jooger], implementation still doesn't look correct to me.
# First question is why we return {{RunningQueryManager.register}} returns
{{GridRunningQueryInfo}}, while in reality {{Long}} iD is enough, as nothing
else from {{GridRunningQueryInfo}} is used anywhere.
# Why {{RunningQueryManager.unregister}} methods are not void? Their results
are not used anywhere.
# {{RunningQueryManager.unregister}} - when {{run,remove}} is called,
subsequent call to query history tracker do not perform {{null}} check. As a
result, one may get NPE in {{close}} is called several times on some cursor.
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
