[jira] [Updated] (IGNITE-4035) SQL: Avoid excessive calls of deterministic functions on same arguments
[ https://issues.apache.org/jira/browse/IGNITE-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4035: Labels: performance (was: sql-performance) > SQL: Avoid excessive calls of deterministic functions on same arguments > --- > > Key: IGNITE-4035 > URL: https://issues.apache.org/jira/browse/IGNITE-4035 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.6, 1.7 >Reporter: Andrew Mashenkov >Priority: Major > Labels: performance > > In sql query example below, heavy "datediff" deterministic function will be > called 4 times per row. I'd expected function was called once per row. > Example: > {noformat} > Select > avg(datediff('s',ts1,ts2)) as avg_diff, > min(datediff('s',ts1,ts2)) as min_diff, > max(datediff('s',ts1,ts2)) as max_diff > From table > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4149) Consider adding bitmap index to SQL engine.
[ https://issues.apache.org/jira/browse/IGNITE-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4149. --- > Consider adding bitmap index to SQL engine. > --- > > Key: IGNITE-4149 > URL: https://issues.apache.org/jira/browse/IGNITE-4149 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.7 >Reporter: Vladimir Ozerov >Priority: Major > Labels: sql-engine > > Bitmap index can help us a lot when there are only several distinct values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11317) Document that SQL DML statements (UPDATE/MERGE) cannot update key fields
Vladimir Ozerov created IGNITE-11317: Summary: Document that SQL DML statements (UPDATE/MERGE) cannot update key fields Key: IGNITE-11317 URL: https://issues.apache.org/jira/browse/IGNITE-11317 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Vladimir Ozerov Assignee: Artem Budnikov This is architectural limitation which is unlikely to be resolved in the nearest time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4268) Allow UPDATEs of the key and its fields in DML statements
[ https://issues.apache.org/jira/browse/IGNITE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4268. - Resolution: Won't Fix The ticket appears to be irrelevant (3 years of inactivity). Will be re-opened if needed. > Allow UPDATEs of the key and its fields in DML statements > - > > Key: IGNITE-4268 > URL: https://issues.apache.org/jira/browse/IGNITE-4268 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Initial DML implementation does not allow to UPDATE columns that correspond > to key or its fields - direct modification would probably damage the index as > well as hash map integrity, so UPDATE for such cases would need to do first > {{remove}}, then {{put}}. > In the course of review, it has been agreed that this feature will be > implemented in later releases shortly to deliver initial implementation on > time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4268) Allow UPDATEs of the key and its fields in DML statements
[ https://issues.apache.org/jira/browse/IGNITE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4268. --- > Allow UPDATEs of the key and its fields in DML statements > - > > Key: IGNITE-4268 > URL: https://issues.apache.org/jira/browse/IGNITE-4268 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Initial DML implementation does not allow to UPDATE columns that correspond > to key or its fields - direct modification would probably damage the index as > well as hash map integrity, so UPDATE for such cases would need to do first > {{remove}}, then {{put}}. > In the course of review, it has been agreed that this feature will be > implemented in later releases shortly to deliver initial implementation on > time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-4327) Failed to INSERT array of Bytes from SELECT
[ https://issues.apache.org/jira/browse/IGNITE-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4327. --- > Failed to INSERT array of Bytes from SELECT > --- > > Key: IGNITE-4327 > URL: https://issues.apache.org/jira/browse/IGNITE-4327 > Project: Ignite > Issue Type: Bug > Components: binary, sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > Attachments: IGNITE-4327.zip > > > An attempt to INSERT binary object having a {{Byte[]}} typed field from > {{SELECT *}} yeilds following exception (initially observed in IGNITE-4323): > {code} > Exception in thread "main" javax.cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Can not set [Ljava.lang.Byte; field > org.apache.ignite.testtools.model.AllTypes.bytesCol to [Ljava.lang.Object; > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1440) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2183) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1125) > at > org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:237) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) > Caused by: class org.apache.ignite.IgniteCheckedException: Can not set > [Ljava.lang.Byte; field org.apache.ignite.testtools.model.AllTypes.bytesCol > to [Ljava.lang.Object; > at > org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7185) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:169) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.get(GridDhtAtomicCache.java:482) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4783) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1395) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1118) > ... 6 more > Caused by: java.lang.IllegalArgumentException: Can not set [Ljava.lang.Byte; > field org.apache.ignite.testtools.model.AllTypes.bytesCol to > [Ljava.lang.Object; > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > at > sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81) > at java.lang.reflect.Field.set(Field.java:741) > at > org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643) > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:829) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1498) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:637) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147) > at > org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1760) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:630) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:492) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:155) > at
[jira] [Resolved] (IGNITE-4327) Failed to INSERT array of Bytes from SELECT
[ https://issues.apache.org/jira/browse/IGNITE-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4327. - Resolution: Duplicate https://issues.apache.org/jira/browse/IGNITE-5464 > Failed to INSERT array of Bytes from SELECT > --- > > Key: IGNITE-4327 > URL: https://issues.apache.org/jira/browse/IGNITE-4327 > Project: Ignite > Issue Type: Bug > Components: binary, sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > Attachments: IGNITE-4327.zip > > > An attempt to INSERT binary object having a {{Byte[]}} typed field from > {{SELECT *}} yeilds following exception (initially observed in IGNITE-4323): > {code} > Exception in thread "main" javax.cache.CacheException: class > org.apache.ignite.IgniteCheckedException: Can not set [Ljava.lang.Byte; field > org.apache.ignite.testtools.model.AllTypes.bytesCol to [Ljava.lang.Object; > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1440) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2183) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1125) > at > org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:237) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) > Caused by: class org.apache.ignite.IgniteCheckedException: Can not set > [Ljava.lang.Byte; field org.apache.ignite.testtools.model.AllTypes.bytesCol > to [Ljava.lang.Object; > at > org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7185) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:169) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.get(GridDhtAtomicCache.java:482) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4783) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1395) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1118) > ... 6 more > Caused by: java.lang.IllegalArgumentException: Can not set [Ljava.lang.Byte; > field org.apache.ignite.testtools.model.AllTypes.bytesCol to > [Ljava.lang.Object; > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > at > sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81) > at java.lang.reflect.Field.set(Field.java:741) > at > org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643) > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:829) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1498) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:637) > at > org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:272) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:160) > at > org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:147) > at > org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1760) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:630) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:492) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtC
[jira] [Closed] (IGNITE-4489) Maintain correct MERGE semantic in DML
[ https://issues.apache.org/jira/browse/IGNITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-4489. --- > Maintain correct MERGE semantic in DML > -- > > Key: IGNITE-4489 > URL: https://issues.apache.org/jira/browse/IGNITE-4489 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Currently it's impossible to MERGE object in UPDATE style - i.e. when key is > present in cache, unaffected field values should be retained, and instead of > building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-2602) Queries: offset does not work with negative or MAX_VALUE limit
[ https://issues.apache.org/jira/browse/IGNITE-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2602. --- > Queries: offset does not work with negative or MAX_VALUE limit > -- > > Key: IGNITE-2602 > URL: https://issues.apache.org/jira/browse/IGNITE-2602 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Priority: Major > > H2 allows specifying negative LIMIT with OFFSET: > http://www.h2database.com/html/grammar.html > This does not work with Ignite (query returns empty result set). > To work around this, I tried to specify Integer.MAX_VALUE, but this causes an > exception. > Turns out, offset+limit should be <= Integer.MAX_VALUE, which is quite > inconvenient. > I think we should support negative LIMIT for unlimited offset queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-4489) Maintain correct MERGE semantic in DML
[ https://issues.apache.org/jira/browse/IGNITE-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4489. - Resolution: Fixed The ticket appears to be irrelevant (>2 years of inactivity). Will be re-opened if needed. > Maintain correct MERGE semantic in DML > -- > > Key: IGNITE-4489 > URL: https://issues.apache.org/jira/browse/IGNITE-4489 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.8 >Reporter: Alexander Paschenko >Priority: Major > > Currently it's impossible to MERGE object in UPDATE style - i.e. when key is > present in cache, unaffected field values should be retained, and instead of > building new object we should base it on previous one for given key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-2602) Queries: offset does not work with negative or MAX_VALUE limit
[ https://issues.apache.org/jira/browse/IGNITE-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2602. - Resolution: Won't Fix The ticket appears to be irrelevant (3 years of inactivity). Will be re-opened if needed. > Queries: offset does not work with negative or MAX_VALUE limit > -- > > Key: IGNITE-2602 > URL: https://issues.apache.org/jira/browse/IGNITE-2602 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 1.1.4 >Reporter: Pavel Tupitsyn >Priority: Major > > H2 allows specifying negative LIMIT with OFFSET: > http://www.h2database.com/html/grammar.html > This does not work with Ignite (query returns empty result set). > To work around this, I tried to specify Integer.MAX_VALUE, but this causes an > exception. > Turns out, offset+limit should be <= Integer.MAX_VALUE, which is quite > inconvenient. > I think we should support negative LIMIT for unlimited offset queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9314) MVCC TX: Datastreamer operations
[ https://issues.apache.org/jira/browse/IGNITE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-9314: -- Assignee: Ivan Pavlukhin > MVCC TX: Datastreamer operations > > > Key: IGNITE-9314 > URL: https://issues.apache.org/jira/browse/IGNITE-9314 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > > Need to change DataStreamer semantics (make it transactional) > Currently clients can see DataStreamer partial writes and two subsequent > selects, which are run in scope of one transaction at load time, may return > different results. > Related thread: > > [http://apache-ignite-developers.2346864.n4.nabble.com/MVCC-and-IgniteDataStreamer-td32340.html] > Also there is a problem when {{DataStreamer}} with {{allowOverwrite == > false}} does not insert value when versions for entry exist but they all are > aborted. Proper transactional semantics should developed for such case. After > that attention should be put on Cache.size method behavior. Cache.size > addressed in https://issues.apache.org/jira/browse/IGNITE-8149 could be > decremented improperly in > {{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManager#mvccRemoveAll}} > method (called during streamer processing) when all existing mvcc row > versions are aborted or last committed one is _remove_ version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767940#comment-16767940 ] Peter Ivanov commented on IGNITE-11216: --- Update PR. > Ignite.sh fails on Mac OS and Linux - Java 11 > - > > Key: IGNITE-11216 > URL: https://issues.apache.org/jira/browse/IGNITE-11216 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite.sh fails on Mac OS Mojave with the following JDK version: > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > The same issue is reproduced on Linux and the workaround is discussed here: > https://issues.apache.org/jira/browse/IGNITE-3 > The exception is as follows: > {noformat} > /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh: > line 40: [: -eq: unary operator expected > ./ignite.sh: line 152: [: -eq: unary operator expected > ./ignite.sh: line 157: [: -gt: unary operator expected > ./ignite.sh: line 170: [: -eq: unary operator expected > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) > to field java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @4f83df68 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767940#comment-16767940 ] Peter Ivanov edited comment on IGNITE-11216 at 2/14/19 7:48 AM: Updated PR. was (Author: vveider): Update PR. > Ignite.sh fails on Mac OS and Linux - Java 11 > - > > Key: IGNITE-11216 > URL: https://issues.apache.org/jira/browse/IGNITE-11216 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite.sh fails on Mac OS Mojave with the following JDK version: > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > The same issue is reproduced on Linux and the workaround is discussed here: > https://issues.apache.org/jira/browse/IGNITE-3 > The exception is as follows: > {noformat} > /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh: > line 40: [: -eq: unary operator expected > ./ignite.sh: line 152: [: -eq: unary operator expected > ./ignite.sh: line 157: [: -gt: unary operator expected > ./ignite.sh: line 170: [: -eq: unary operator expected > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) > to field java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @4f83df68 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-10214: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767845#comment-16767845 ] Pavel Konstantinov commented on IGNITE-10214: - Successfully tested using the last version of web agent. > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-10214: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767810#comment-16767810 ] Vasiliy Sisko commented on IGNITE-10214: [~pkonstantinov] Please check you use last version of Web agent. > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-10214: --- Assignee: Vasiliy Sisko (was: Pavel Konstantinov) > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-10214: Attachment: mysql-connector-java-8.0.13.jar > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767794#comment-16767794 ] Pavel Konstantinov edited comment on IGNITE-10214 at 2/14/19 2:02 AM: -- My test failed: * after I imported a whole cluster from the MySQL DB using the mysql-connector-java-8.0.13.jar (attached) I got Generic JDBC dialect in the cache settings !screenshot-1.png! * also the JDBC driver was not automatically detected on the first step of import and I was forced to set it manually was (Author: pkonstantinov): My test failed: after I imported a whole cluster from the MySQL DB using mysql-connector-java-8.0.13.jar (attached) I got Generic JDBC dialect in the cache settings !screenshot-1.png! > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767794#comment-16767794 ] Pavel Konstantinov edited comment on IGNITE-10214 at 2/14/19 1:58 AM: -- My test failed: after I imported a whole cluster from the MySQL DB using mysql-connector-java-8.0.13.jar (attached) I got Generic JDBC dialect in the cache settings !screenshot-1.png! was (Author: pkonstantinov): My test failed: after I imported some cache from the MySQL DB using mysql-connector-java-8.0.13.jar (attached) I got Generic JDBC dialect in the cache settings !screenshot-1.png! > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767794#comment-16767794 ] Pavel Konstantinov edited comment on IGNITE-10214 at 2/14/19 1:57 AM: -- My test failed: after I imported some cache from the MySQL DB using mysql-connector-java-8.0.13.jar (attached) I got Generic JDBC dialect in the cache settings !screenshot-1.png! was (Author: pkonstantinov): My test failed: after I imported some cache from the MySQL DB using mysql-connector-java-8.0.13.jar I got Generic JDBC dialect in the cache settings !screenshot-1.png! > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767794#comment-16767794 ] Pavel Konstantinov commented on IGNITE-10214: - My test failed: after I imported some cache from the MySQL DB using mysql-connector-java-8.0.13.jar I got Generic JDBC dialect in the cache settings !screenshot-1.png! > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10214) Web console: dependency to open source JDBC driver is not generated in the project's pom file
[ https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-10214: Attachment: screenshot-1.png > Web console: dependency to open source JDBC driver is not generated in the > project's pom file > - > > Key: IGNITE-10214 > URL: https://issues.apache.org/jira/browse/IGNITE-10214 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: mysql-connector-java-8.0.13.jar, screenshot-1.png > > > Steps to reproduce: > # import caches from for example MySql DB > # check generated pom file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11165: --- Fix Version/s: 2.7 > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11165: --- Affects Version/s: 2.6 > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6 >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-11165. Resolution: Fixed > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767691#comment-16767691 ] Evgenii Zhuravlev commented on IGNITE-11165: [~Artem Budnikov] Thank you! Then I suppose we can close this issue. > Add note to the documentation that cache name will be used as folder name in > case of using persistence > -- > > Key: IGNITE-11165 > URL: https://issues.apache.org/jira/browse/IGNITE-11165 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > > We should add a note that it's not recommended to use symbols which are not > allowed to use in the file system in case of using persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11265) JVM Crashes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11265: Fix Version/s: 2.8 > JVM Crashes on TeamCity > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Fix For: 2.8 > > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767615#comment-16767615 ] Dmitriy Pavlov commented on IGNITE-11155: - [~dmagda], thanks for the link. I mean easier access than parsing these parameters from strings. Anyway, each call to Ignition start() without parameters under Java 9+ will result in a predictive exception (IllegalReflectiveAccess or its subclass), which is caught and rethrown with our recommendations. So it is more or less same solution as you've suggested. We don't need to throw it, Java does it for us. > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767608#comment-16767608 ] Denis Magda commented on IGNITE-11155: -- How about RuntimeMXBean solution? Check this thread: https://stackoverflow.com/questions/1490869/how-to-get-vm-arguments-from-inside-of-java-application > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767596#comment-16767596 ] Dmitriy Pavlov edited comment on IGNITE-11155 at 2/13/19 9:11 PM: -- [~dmagda], unfortunately, it is not possible to check parameters from Java API. An exception is always thrown after Ignition.start() -> GridUnsafe.init() -> sun.misc.Unsafe. This change catches the exception and adds information about the required parameters. was (Author: dpavlov): [~dmagda], unfortunately, it is not possible to check parameters from Java API. An exception is always thrown after Ignition.start() -> GridUnsafe.init(). This change catches the exception and adds information about the required parameters. > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767596#comment-16767596 ] Dmitriy Pavlov commented on IGNITE-11155: - [~dmagda], unfortunately, it is not possible to check parameters from Java API. An exception is always thrown after Ignition.start() -> GridUnsafe.init(). This change catches the exception and adds information about the required parameters. > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767594#comment-16767594 ] Denis Magda commented on IGNITE-11155: -- [~dpavlov], let's do one step and make an even better improvement. I was asking the following question myself - look, why do we let a node to start and then fail if the parameters are missing? Why don't we check the JDK version and parameters as soon as Ignition.start is called. If the parameters are missed then we will through an exception right away. Could you please do that? It's much more user-friendly. > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[ https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reopened IGNITE-11155: -- > Add JVM options analysis to Ignition.start() or handle and comment exceptions > - > > Key: IGNITE-11155 > URL: https://issues.apache.org/jira/browse/IGNITE-11155 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.8 > > Attachments: start-java11-2.png, start-java11.png > > Time Spent: 20m > Remaining Estimate: 0h > > In Ignite examples or using Ignite Embedded mode (using direct > Ignition.start() call from a user IDE), may fail with exceptions for JDKs > newer than 8. > It may confuse the user. Instead of just logging an exception it is better to > output message with advice on how to fix it. E.g. > {noformat} > Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled. > See > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > for more info > {noformat} > Modern IDEs like IntelliJ will display the link as a clickable hyperlink and > Ignite in embedded mode will show how to set up Application configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11310) SQL: Remove special interaction between query parallelism and distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767552#comment-16767552 ] Vladimir Ozerov commented on IGNITE-11310: -- Implemented. Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=3079523 > SQL: Remove special interaction between query parallelism and distributed > joins > --- > > Key: IGNITE-11310 > URL: https://issues.apache.org/jira/browse/IGNITE-11310 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently we enable so-called "local distributed joins" when query is > executed locally with enabled parallelism. This behavior is not needed and > needs to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11316) SQL: Support partition pruning for local queries
Vladimir Ozerov created IGNITE-11316: Summary: SQL: Support partition pruning for local queries Key: IGNITE-11316 URL: https://issues.apache.org/jira/browse/IGNITE-11316 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Currently it is not supported because extraction happens inside splitter. Local query eithe: # Do not reach splitter at all (no-split case) # Reach splitter, but skip extraction due to missing infrastructure which is to be implemented and tested in the scope of current ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ig
[ https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Kamyshnikov updated IGNITE-11296: -- Attachment: PrimaryBackupTest.java > 3rd-party persistence: Backup and primary partitions data differ after a > single IgniteCache.get that loaded data from the persistent store which > breaks skipStore and Ignite JDBC behavior > -- > > Key: IGNITE-11296 > URL: https://issues.apache.org/jira/browse/IGNITE-11296 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.7 >Reporter: Igor Kamyshnikov >Priority: Major > Attachments: PrimaryBackupTest.java > > > 1) run 2 ignite servers on different machines > (this is important because of > org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced > - it takes into account MACs) > the cache under test should be partitioned with backups = 1. > 2) run cassandra and insert some records into cassandra > 3) connect to the ignite cluster as Ignite client node and invoke > IgniteCache.get(pk); > for the existing pk. This will load data into caches. > 4) execute IgniteCache.withSkipStore().get(pk) several times > The values returned will be randomly NULLs or non-NULLs. > 5) depending on a chance, the data loaded in 3) can appear in primary > partition or backup partition. If they are in backup partition, then they are > not visible to Ignite JDBC. > Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and > {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that > either backup partition or primary partition does not contain data after p. > 3). > However, cache.loadCache(null) loads all the data in both primary and backup > partitions. > Self describing demo code added: [^PrimaryBackupTest.java] : > 1) create nodes with different MACs > 2) create a test cache with a number of backup partitions > 3) implicitely load several keys, making sure we found all the keys that have > at least one empty partition after implicit load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ig
[ https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Kamyshnikov updated IGNITE-11296: -- Description: 1) run 2 ignite servers on different machines (this is important because of org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced - it takes into account MACs) the cache under test should be partitioned with backups = 1. 2) run cassandra and insert some records into cassandra 3) connect to the ignite cluster as Ignite client node and invoke IgniteCache.get(pk); for the existing pk. This will load data into caches. 4) execute IgniteCache.withSkipStore().get(pk) several times The values returned will be randomly NULLs or non-NULLs. 5) depending on a chance, the data loaded in 3) can appear in primary partition or backup partition. If they are in backup partition, then they are not visible to Ignite JDBC. Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that either backup partition or primary partition does not contain data after p. 3). However, cache.loadCache(null) loads all the data in both primary and backup partitions. Self describing demo code added: [^PrimaryBackupTest.java] : 1) create nodes with different MACs 2) create a test cache with a number of backup partitions 3) implicitely load several keys, making sure we found all the keys that have at least one empty partition after implicit load. 4) test other partterns of putting keys 5) test SQL and gets with skip store for implicitely loaded keys, making sure that both nulls and not nulls are returned. was: 1) run 2 ignite servers on different machines (this is important because of org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced - it takes into account MACs) the cache under test should be partitioned with backups = 1. 2) run cassandra and insert some records into cassandra 3) connect to the ignite cluster as Ignite client node and invoke IgniteCache.get(pk); for the existing pk. This will load data into caches. 4) execute IgniteCache.withSkipStore().get(pk) several times The values returned will be randomly NULLs or non-NULLs. 5) depending on a chance, the data loaded in 3) can appear in primary partition or backup partition. If they are in backup partition, then they are not visible to Ignite JDBC. Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that either backup partition or primary partition does not contain data after p. 3). However, cache.loadCache(null) loads all the data in both primary and backup partitions. Self describing demo code added: [^PrimaryBackupTest.java] : 1) create nodes with different MACs 2) create a test cache with a number of backup partitions 3) implicitely load several keys, making sure we found all the keys that have at least one empty partition after implicit load. > 3rd-party persistence: Backup and primary partitions data differ after a > single IgniteCache.get that loaded data from the persistent store which > breaks skipStore and Ignite JDBC behavior > -- > > Key: IGNITE-11296 > URL: https://issues.apache.org/jira/browse/IGNITE-11296 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.7 >Reporter: Igor Kamyshnikov >Priority: Major > Attachments: PrimaryBackupTest.java > > > 1) run 2 ignite servers on different machines > (this is important because of > org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced > - it takes into account MACs) > the cache under test should be partitioned with backups = 1. > 2) run cassandra and insert some records into cassandra > 3) connect to the ignite cluster as Ignite client node and invoke > IgniteCache.get(pk); > for the existing pk. This will load data into caches. > 4) execute IgniteCache.withSkipStore().get(pk) several times > The values returned will be randomly NULLs or non-NULLs. > 5) depending on a chance, the data loaded in 3) can appear in primary > partition or backup partition. If they are in backup partition, then they are > not visible to Ignite JDBC. > Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and > {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that > either backup partition or primary partition does not contain data after p. > 3). > However, cache.loadCache(null) loads all the data in both primary and backup > partitions. > Self des
[jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ig
[ https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Kamyshnikov updated IGNITE-11296: -- Description: 1) run 2 ignite servers on different machines (this is important because of org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced - it takes into account MACs) the cache under test should be partitioned with backups = 1. 2) run cassandra and insert some records into cassandra 3) connect to the ignite cluster as Ignite client node and invoke IgniteCache.get(pk); for the existing pk. This will load data into caches. 4) execute IgniteCache.withSkipStore().get(pk) several times The values returned will be randomly NULLs or non-NULLs. 5) depending on a chance, the data loaded in 3) can appear in primary partition or backup partition. If they are in backup partition, then they are not visible to Ignite JDBC. Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that either backup partition or primary partition does not contain data after p. 3). However, cache.loadCache(null) loads all the data in both primary and backup partitions. Self describing demo code added: [^PrimaryBackupTest.java] : 1) create nodes with different MACs 2) create a test cache with a number of backup partitions 3) implicitely load several keys, making sure we found all the keys that have at least one empty partition after implicit load. was: 1) run 2 ignite servers on different machines (this is important because of org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced - it takes into account MACs) the cache under test should be partitioned with backups = 1. 2) run cassandra and insert some records into cassandra 3) connect to the ignite cluster as Ignite client node and invoke IgniteCache.get(pk); for the existing pk. This will load data into caches. 4) execute IgniteCache.withSkipStore().get(pk) several times The values returned will be randomly NULLs or non-NULLs. 5) depending on a chance, the data loaded in 3) can appear in primary partition or backup partition. If they are in backup partition, then they are not visible to Ignite JDBC. Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that either backup partition or primary partition does not contain data after p. 3). However, cache.loadCache(null) loads all the data in both primary and backup partitions. > 3rd-party persistence: Backup and primary partitions data differ after a > single IgniteCache.get that loaded data from the persistent store which > breaks skipStore and Ignite JDBC behavior > -- > > Key: IGNITE-11296 > URL: https://issues.apache.org/jira/browse/IGNITE-11296 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.7 >Reporter: Igor Kamyshnikov >Priority: Major > Attachments: PrimaryBackupTest.java > > > 1) run 2 ignite servers on different machines > (this is important because of > org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced > - it takes into account MACs) > the cache under test should be partitioned with backups = 1. > 2) run cassandra and insert some records into cassandra > 3) connect to the ignite cluster as Ignite client node and invoke > IgniteCache.get(pk); > for the existing pk. This will load data into caches. > 4) execute IgniteCache.withSkipStore().get(pk) several times > The values returned will be randomly NULLs or non-NULLs. > 5) depending on a chance, the data loaded in 3) can appear in primary > partition or backup partition. If they are in backup partition, then they are > not visible to Ignite JDBC. > Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and > {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that > either backup partition or primary partition does not contain data after p. > 3). > However, cache.loadCache(null) loads all the data in both primary and backup > partitions. > Self describing demo code added: [^PrimaryBackupTest.java] : > 1) create nodes with different MACs > 2) create a test cache with a number of backup partitions > 3) implicitely load several keys, making sure we found all the keys that have > at least one empty partition after implicit load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ig
[ https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Kamyshnikov updated IGNITE-11296: -- Attachment: (was: PrimaryBackupTest.java) > 3rd-party persistence: Backup and primary partitions data differ after a > single IgniteCache.get that loaded data from the persistent store which > breaks skipStore and Ignite JDBC behavior > -- > > Key: IGNITE-11296 > URL: https://issues.apache.org/jira/browse/IGNITE-11296 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.7 >Reporter: Igor Kamyshnikov >Priority: Major > Attachments: PrimaryBackupTest.java > > > 1) run 2 ignite servers on different machines > (this is important because of > org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced > - it takes into account MACs) > the cache under test should be partitioned with backups = 1. > 2) run cassandra and insert some records into cassandra > 3) connect to the ignite cluster as Ignite client node and invoke > IgniteCache.get(pk); > for the existing pk. This will load data into caches. > 4) execute IgniteCache.withSkipStore().get(pk) several times > The values returned will be randomly NULLs or non-NULLs. > 5) depending on a chance, the data loaded in 3) can appear in primary > partition or backup partition. If they are in backup partition, then they are > not visible to Ignite JDBC. > Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and > {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that > either backup partition or primary partition does not contain data after p. > 3). > However, cache.loadCache(null) loads all the data in both primary and backup > partitions. > Self describing demo code added: [^PrimaryBackupTest.java] : > 1) create nodes with different MACs > 2) create a test cache with a number of backup partitions > 3) implicitely load several keys, making sure we found all the keys that have > at least one empty partition after implicit load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11296) 3rd-party persistence: Backup and primary partitions data differ after a single IgniteCache.get that loaded data from the persistent store which breaks skipStore and Ig
[ https://issues.apache.org/jira/browse/IGNITE-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Kamyshnikov updated IGNITE-11296: -- Attachment: PrimaryBackupTest.java > 3rd-party persistence: Backup and primary partitions data differ after a > single IgniteCache.get that loaded data from the persistent store which > breaks skipStore and Ignite JDBC behavior > -- > > Key: IGNITE-11296 > URL: https://issues.apache.org/jira/browse/IGNITE-11296 > Project: Ignite > Issue Type: Bug > Components: cache, cassandra >Affects Versions: 2.5, 2.7 >Reporter: Igor Kamyshnikov >Priority: Major > Attachments: PrimaryBackupTest.java > > > 1) run 2 ignite servers on different machines > (this is important because of > org.apache.ignite.internal.processors.cache.GridCacheContext#selectAffinityNodeBalanced > - it takes into account MACs) > the cache under test should be partitioned with backups = 1. > 2) run cassandra and insert some records into cassandra > 3) connect to the ignite cluster as Ignite client node and invoke > IgniteCache.get(pk); > for the existing pk. This will load data into caches. > 4) execute IgniteCache.withSkipStore().get(pk) several times > The values returned will be randomly NULLs or non-NULLs. > 5) depending on a chance, the data loaded in 3) can appear in primary > partition or backup partition. If they are in backup partition, then they are > not visible to Ignite JDBC. > Various techniques with ignite.affinity.mapKeyToPrimaryAndBackups and > {noformat}ignite.compute.call(() -> { cache.localPeek }){noformat} prove that > either backup partition or primary partition does not contain data after p. > 3). > However, cache.loadCache(null) loads all the data in both primary and backup > partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767356#comment-16767356 ] Ignite TC Bot commented on IGNITE-10693: {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}PDS 2{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=3077502]] * IgnitePdsTestSuite2: IgniteWalHistoryReservationsTest.testNodeLeftDuringExchange - 0,0% fails in last 415 master runs. {color:#d04437}Queries 2{color} [[tests 5|https://ci.ignite.apache.org/viewLog.html?buildId=3077445]] * IgniteBinaryCacheQueryTestSuite2: IgniteCacheQueryNodeRestartSelfTest.testRestarts - 0,0% fails in last 416 master runs. * IgniteBinaryCacheQueryTestSuite2: IgniteChangingBaselineCacheQueryNodeRestartSelfTest.testRestarts - 0,0% fails in last 416 master runs. * IgniteBinaryCacheQueryTestSuite2: DynamicIndexPartitionedTransactionalConcurrentSelfTest.testCoordinatorChange - 0,0% fails in last 416 master runs. * IgniteBinaryCacheQueryTestSuite2: DynamicIndexPartitionedAtomicConcurrentSelfTest.testCoordinatorChange - 0,0% fails in last 416 master runs. {color:#d04437}Cache 5{color} [[tests 4|https://ci.ignite.apache.org/viewLog.html?buildId=3077487]] * IgniteCacheWithIndexingTestSuite: CacheTtlAtomicPartitionedSelfTest.testDefaultTimeToLivePreload - 0,0% fails in last 417 master runs. * IgniteCacheWithIndexingTestSuite: IgniteClientReconnectQueriesTest.testReconnectQueryInProgress - 0,0% fails in last 417 master runs. * IgniteCacheWithIndexingTestSuite: IgniteClientReconnectQueriesTest.testQueryReconnect - 0,0% fails in last 417 master runs. {color:#d04437}JDBC Driver{color} [[tests 6|https://ci.ignite.apache.org/viewLog.html?buildId=3077442]] * IgniteJdbcDriverTestSuite: JdbcComplexQuerySelfTest.testBetween - 0,0% fails in last 418 master runs. * IgniteJdbcDriverTestSuite: JdbcComplexQuerySelfTest.testJoinWithoutAlias - 0,0% fails in last 418 master runs. * IgniteJdbcDriverTestSuite: JdbcComplexQuerySelfTest.testJoin - 0,0% fails in last 418 master runs. * IgniteJdbcDriverTestSuite: JdbcComplexQuerySelfTest.testIn - 0,0% fails in last 418 master runs. * IgniteJdbcDriverTestSuite: JdbcDistributedJoinsQueryTest.testJoin - 0,0% fails in last 418 master runs. * IgniteJdbcDriverTestSuite: JdbcComplexQuerySelfTest.testCalculatedValue - 0,0% fails in last 418 master runs. {color:#d04437}Spring{color} [[tests 0 Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3077446]] {color:#d04437}MVCC PDS 4{color} [[tests 0 TIMEOUT , Exit Code , BUILD_RUNNER_ERROR |https://ci.ignite.apache.org/viewLog.html?buildId=3077533]] {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3077535&buildTypeId=IgniteTests24Java8_RunAll] > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11265) JVM Crashes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767345#comment-16767345 ] Ivan Bessonov commented on IGNITE-11265: [~EdShangGG] code looks good, thank you! > JVM Crashes on TeamCity > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767337#comment-16767337 ] Ignite TC Bot commented on IGNITE-8571: --- {panel:title=--> Run :: All: No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3070785&buildTypeId=IgniteTests24Java8_RunAll] > Baseline auto-adjust feature > > > Key: IGNITE-8571 > URL: https://issues.apache.org/jira/browse/IGNITE-8571 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Now we have only one way to change BLAT - manually update it via console.sh > or API. > We need to add the possibility to change it automatically. Adjust to current > topology. > So, I propose 2 new distributed parameters which would be responsible to tune > this feature. > 1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto > adjusting baseline. > 2. autoAdjustTimeout - time which we would wait after the actual topology > change. But it would be reset if new discovery event happened. (node > join/exit). > We need to change API next way: > org.apache.ignite.IgniteCluster: > * isBaselineAutoAdjustEnabled() > * setBaselineAutoAdjustEnabled(boolean enabled); > * setBaselineAutoAdjustTimeout(long timeoutInMs); > Also, we need to ensure that all nodes would have the same > parameters(distributed parameters). > And we should be able to survive coordinator left during parameters changes. > When autoAdjustEnabled is true we should be block ability to manual baseline > change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767328#comment-16767328 ] Ilya Suntsov commented on IGNITE-11216: --- [~vveider] I see the problem with ignitevisorcmd.sh {noformat} bin/ignitevisorcmd.sh: line 69: DOCK_OPTS: unbound variable {noformat} > Ignite.sh fails on Mac OS and Linux - Java 11 > - > > Key: IGNITE-11216 > URL: https://issues.apache.org/jira/browse/IGNITE-11216 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite.sh fails on Mac OS Mojave with the following JDK version: > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > The same issue is reproduced on Linux and the workaround is discussed here: > https://issues.apache.org/jira/browse/IGNITE-3 > The exception is as follows: > {noformat} > /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh: > line 40: [: -eq: unary operator expected > ./ignite.sh: line 152: [: -eq: unary operator expected > ./ignite.sh: line 157: [: -gt: unary operator expected > ./ignite.sh: line 170: [: -eq: unary operator expected > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) > to field java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @4f83df68 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11265) JVM Crashes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767322#comment-16767322 ] Ignite TC Bot commented on IGNITE-11265: {panel:title=--> Run :: All: No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3070399&buildTypeId=IgniteTests24Java8_RunAll] > JVM Crashes on TeamCity > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11315) [ML] Nonlinear SVM
Artem Malykh created IGNITE-11315: - Summary: [ML] Nonlinear SVM Key: IGNITE-11315 URL: https://issues.apache.org/jira/browse/IGNITE-11315 Project: Ignite Issue Type: Improvement Components: ml Reporter: Artem Malykh Assignee: Artem Malykh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6135) java.sql.Date is serialized using OptimizedMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6135: Priority: Blocker (was: Major) > java.sql.Date is serialized using OptimizedMarshaller > - > > Key: IGNITE-6135 > URL: https://issues.apache.org/jira/browse/IGNITE-6135 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.1 >Reporter: Valentin Kulichenko >Assignee: Amelchev Nikita >Priority: Blocker > > For some reason, if an object has a field of {{java.sql.Date}}, it's > serialized with {{OptimizedMarshaller}}. It should be a first class citizen, > similar to {{java.util.Date}}. > In addition, it's possible to write a field using builder like this: > {code} > builder.setField(name, val, java.util.Date.class) > {code} > where {{val}} is instance of {{java.sql.Date}}. This leads to an exception > during deserialization, because {{java.util.Date}} would be expected. > More context and code reproducing the issue can be found here: > http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-td16276.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-11257. -- > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11314) JDBC Thin: add transaction-scoped flag to JdbcHandler's responses.
Alexander Lapin created IGNITE-11314: Summary: JDBC Thin: add transaction-scoped flag to JdbcHandler's responses. Key: IGNITE-11314 URL: https://issues.apache.org/jira/browse/IGNITE-11314 Project: Ignite Issue Type: Task Components: jdbc Reporter: Alexander Lapin Within the context of best effort affinity, and particular, multi-connections, it's necessary to use "sticky" connections in case of "next page" requests, transactions, streaming and copy. In order to implement transaction-based-sticky use case we need to know whether we are in transnational scope or not. So JdbcRequestHandler ought to retrieve query execution plan, analyse whether transaction exists and propagate corresponding flag to the client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin closed IGNITE-11257. > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767253#comment-16767253 ] Alexander Lapin commented on IGNITE-11257: -- Merged to IGNITE-11287. > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6580) Cluster can fail during concurrent re-balancing and cache destruction
[ https://issues.apache.org/jira/browse/IGNITE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767244#comment-16767244 ] Ilya Kasnacheev commented on IGNITE-6580: - [~mcherkasov] please check if it can still be reproduced on master. > Cluster can fail during concurrent re-balancing and cache destruction > - > > Key: IGNITE-6580 > URL: https://issues.apache.org/jira/browse/IGNITE-6580 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.2 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > The following exceptions can be abserved during concurrent re-balancing and > cache destruction: > 1. > {noformat} > [00:01:27,135][ERROR][sys-#4375%null%][GridDhtPreloader] Partition eviction > failed, this can cause grid hang. > org.apache.ignite.IgniteException: Runtime failure on search row: > Row@6be51c3d[ **REMOVED SENSITIVE INFORMATION** ] > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1787) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.remove(BPlusTree.java:1578) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.remove(H2TreeIndex.java:226) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:523) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:416) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:574) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2172) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1462) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1425) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:951) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:809) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6629) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > [ignite-core-2.1.4.jar:2.1.4] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [?:1.8.0_131] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [?:1.8.0_131] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131] > Caused by: java.lang.IllegalStateException: Item not found: 1 > at > org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.findIndirectItemIndex(DataPageIO.java:346) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:446) > ~[ignite-core-2.1
[jira] [Commented] (IGNITE-10644) CorruptedTreeException might occur after force node kill during transaction
[ https://issues.apache.org/jira/browse/IGNITE-10644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767242#comment-16767242 ] Ilya Kasnacheev commented on IGNITE-10644: -- I cannot reproduce it after IGNITE-9303 any more! [~pvinokurov] please check if you can still observe it. > CorruptedTreeException might occur after force node kill during transaction > --- > > Key: IGNITE-10644 > URL: https://issues.apache.org/jira/browse/IGNITE-10644 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Priority: Major > > Partition eviction process on the other hand: > > 2018-12-10 20:59:24.426 > [ERROR]sys-#204%_GRID%GridNodeName%[o.a.i.i.p.c.d.d.t.PartitionsEvictManager] > Partition eviction failed, this can cause grid hang. > org.h2.message.DbException: General error: "class > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > Runtime failure on search row: Row@3580787f[ key: 4071535538120363041, val: > X.common.dpl.model.backstream.DBackStreamMessage_DPL_PROXY > [idHash=1961442513, hash=529139710, colocationKey=14465, entityType=I, > lastChangeDate=1544464745135, errorMessage=No api > [X.scripts.ucp.retail.propagate.publicapi.ClientPropagateService] services > available for route: [*][*][kbt] (zone-node-module).IP: [*]. > List of services violations: > NODE MODULE FILTER VIOLATIONS > No services or violations were found for routing, partition_X_id=5, > messageId=1211871172446406939, entityId=1211871174131851324, ownerId=ucp, > responseDate=null, entityVersion=1, isDeleted=false, requestDate=Mon Dec 10 > 20:59:05 MSK 2018, id=4071535538120363041], ver: GridCacheVersion > [topVer=155940834, order=1544596983071, nodeOrder=114] ][ I, null, > 1211871172446406939, 1211871174131851324, null, 1, 2018-12-10 20:59:05.115, > No api [X.scripts.ucp.retail.propagate.publicapi.ClientPropagateService] > services available for route: [*][*][kbt] (zone-node-module).IP: [*]. > List of services violations: > NODE MODULE FILTER VIOLATIONS > No services or violations were found for routing, 4071535538120363041, FALSE, > 5 ]" [5-195] > at org.h2.message.DbException.get(DbException.java:168) > at org.h2.message.DbException.convert(DbException.java:295) > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.removex(H2TreeIndex.java:293) > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:515) > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:738) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2487) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:433) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1465) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1435) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:1633) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3706) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:652) > at > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:1079) > at > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.tryClear(GridDhtLocalPartition.java:915) > at > org.apache.ignite.internal.processors.cache.distributed.dht.topology.PartitionsEvictManager$PartitionEvictionTask.run(PartitionsEvictManager.java:423) > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6782) > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.h2.jdbc.JdbcSQLException: General error: "class > org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException: > Runtime failure on search row: Row@3580787f[ key: 40715355381203
[jira] [Commented] (IGNITE-6580) Cluster can fail during concurrent re-balancing and cache destruction
[ https://issues.apache.org/jira/browse/IGNITE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767237#comment-16767237 ] Ilya Kasnacheev commented on IGNITE-6580: - Possibly fixed by IGNITE-9303 > Cluster can fail during concurrent re-balancing and cache destruction > - > > Key: IGNITE-6580 > URL: https://issues.apache.org/jira/browse/IGNITE-6580 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.2 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > The following exceptions can be abserved during concurrent re-balancing and > cache destruction: > 1. > {noformat} > [00:01:27,135][ERROR][sys-#4375%null%][GridDhtPreloader] Partition eviction > failed, this can cause grid hang. > org.apache.ignite.IgniteException: Runtime failure on search row: > Row@6be51c3d[ **REMOVED SENSITIVE INFORMATION** ] > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:1787) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.remove(BPlusTree.java:1578) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.remove(H2TreeIndex.java:226) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:523) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:416) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:574) > ~[ignite-indexing-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2172) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:451) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:1462) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:1425) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:383) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:3224) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.clearInternal(GridDhtCacheEntry.java:588) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:951) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:809) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6629) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967) > [ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > [ignite-core-2.1.4.jar:2.1.4] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [?:1.8.0_131] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [?:1.8.0_131] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131] > Caused by: java.lang.IllegalStateException: Item not found: 1 > at > org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.findIndirectItemIndex(DataPageIO.java:346) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:446) > ~[ignite-core-2.1.4.jar:2.1.4] > at > org.apache
[jira] [Updated] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11299: - Labels: ssl (was: ) > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: ssl > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11299: - Description: Causes busy looping in processSelectionKeyOptimized() This also causes problems on Windows/Java 11 since if key is always ready for writing it will never be shown as ready for reading. The reason for this behavior that during handshake we never un-listen OP_WRITE was: Causes busy looping in processSelectionKeyOptimized() This also causes problems on Windows/Java 11 since if key is always ready for writing it will never be shown as ready for reading. > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: ssl > Time Spent: 10m > Remaining Estimate: 0h > > Causes busy looping in processSelectionKeyOptimized() > This also causes problems on Windows/Java 11 since if key is always ready for > writing it will never be shown as ready for reading. > The reason for this behavior that during handshake we never un-listen OP_WRITE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11299: - Description: Causes busy looping in processSelectionKeyOptimized() This also causes problems on Windows/Java 11 since if key is always ready for writing it will never be shown as ready for reading. > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: ssl > Time Spent: 10m > Remaining Estimate: 0h > > Causes busy looping in processSelectionKeyOptimized() > This also causes problems on Windows/Java 11 since if key is always ready for > writing it will never be shown as ready for reading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767225#comment-16767225 ] Ilya Kasnacheev commented on IGNITE-11299: -- [~yzhdanov] [~sboikov] [~dpavlov] please review NIO SSL patch. I have ran some suites on Java 11 - SSL works, ditto SPI on Windows: https://ci.ignite.apache.org/viewLog.html?buildId=3077134&buildTypeId=IgniteTests24Java8_SpiWindows https://ci.ignite.apache.org/viewLog.html?buildId=3077015&tab=queuedBuildOverviewTab https://ci.ignite.apache.org/viewLog.html?buildId=3076776&buildTypeId=IgniteTests24Java8_CacheFailoverSsl&tab=testsInfo https://ci.ignite.apache.org/viewLog.html?buildId=3076778&tab=queuedBuildOverviewTab https://ci.ignite.apache.org/viewLog.html?buildId=3076518&; This is in addition to regular Visa shown above. > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-11299: Assignee: Ilya Kasnacheev > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11299: - Ignite Flags: (was: Docs Required) > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: ssl > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly
[ https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767220#comment-16767220 ] Ignite TC Bot commented on IGNITE-11299: {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}SPI{color} [[tests 4|https://ci.ignite.apache.org/viewLog.html?buildId=3077015]] * IgniteSpiTestSuite: TcpDiscoverySslParametersTest.testNonExistentCipherSuite - 0,0% fails in last 418 master runs. {color:#d04437}Basic 1{color} [[tests 0 TIMEOUT , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3071192]] * SetTxTimeoutOnPartitionMapExchangeTest.testSetTxTimeoutOnClientDuringPartitionMapExchange (last started) {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3071265&buildTypeId=IgniteTests24Java8_RunAll] > During SSL Handshake GridNioServer.processWrite is invoked constantly > - > > Key: IGNITE-11299 > URL: https://issues.apache.org/jira/browse/IGNITE-11299 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767218#comment-16767218 ] Igor Seliverstov edited comment on IGNITE-10693 at 2/13/19 2:07 PM: Seems we have wrong mapping logic in case of unstable topology. In the patch reworked mapping is implemented. the main flow looks so: 1) find all nodes that have all partitions for involved replicated caches (optional step) 2) find nodes that have each partition of each involved partitioned cache. Filter these nodes using previously collected nodes for replicated caches if needed 3) reduce the nodes count for execution - use as little as possible nodes having all needed partitions but not intersecting partitions between nodes. was (Author: gvvinblade): Seems we have wrong mapping logic in case of unstable topology. In the patch reworked mapping implemented. the main flow looks so: 1) find all nodes that have all partitions for involved replicated caches (optional step) 2) find nodes that have each partition of each involved partitioned cache. Filter these nodes using previously collected nodes for replicated caches if needed 3) reduce the nodes count for execution - use as little as possible nodes having all needed partitions but not intersecting partitions between nodes. > MVCC TX: Random server restart tests became failed > -- > > Key: IGNITE-10693 > URL: https://issues.apache.org/jira/browse/IGNITE-10693 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [one|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7945125576049372508&branch=%3Cdefault%3E&tab=testDetails], > > [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8412476034648229784&branch=%3Cdefault%3E&tab=testDetails], > > [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=254244004184327163&branch=%3Cdefault%3E&tab=testDetails], > all these tests became failed after IGNITE-9630 has been merged to master. > Seems there is an issue in partition calculating mechanism on unstable > topology. I suppose the algorithm uses partitions on nodes just become > primary while the partitions are in moving state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[ https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-11226: Assignee: Pavel Kuznetsov > SQL: Remove GridQueryIndexing.prepareNativeStatement > > > Key: IGNITE-11226 > URL: https://issues.apache.org/jira/browse/IGNITE-11226 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Pavel Kuznetsov >Priority: Major > > This method is the only leak of H2 internals to the outer code. Close > analysis of code reveals that the only reason we have it is *JDBC metadata*. > Need to create a method which will prepare metadata for a statement and > return it as a detached object. Most probably we already have all necessary > mechanics. This is more about refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11300) MVCC: forbid using DataStreamer with allowOverwrite=true
[ https://issues.apache.org/jira/browse/IGNITE-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767211#comment-16767211 ] Ivan Pavlukhin commented on IGNITE-11300: - [~amashenkov], {{allowOverwrite=true}} have not been explicitly tested. Moreover, streamer implementation using single {{cache.put}} operations will most likely have very poor performance. {{allowOverwrite=false}} should be addressed in scope of IGNITE-9314. Currently, streamer in such mode will not insert a tuple if there is anything (e.g. aborted versions) for a give key in BPlusTree. > MVCC: forbid using DataStreamer with allowOverwrite=true > > > Key: IGNITE-11300 > URL: https://issues.apache.org/jira/browse/IGNITE-11300 > Project: Ignite > Issue Type: Task > Components: mvcc >Affects Versions: 2.7 >Reporter: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > > Calling {{IgniteDataStreamer.allowOverwrite(true)}} configures a streamer to > use single-key cache put/remove operations for data modification. But > put/remove operations on MVCC caches can be aborted due to write conflicts. > So, some development effort is needed to support that mode properly. Let's > throw exception in such case for MVCC caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11258: - Fix Version/s: 2.8 > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11258: - Ignite Flags: (was: Docs Required) > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11258: - Component/s: (was: sql) jdbc > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767209#comment-16767209 ] Vladimir Ozerov commented on IGNITE-11258: -- [~alapin], my recommendations: # Make {{JdbcThinTcpIo}} - once initialized it never changes (no reconnect). Once disconnected it is disconnected forever. This way we will avoid a lot of bugs # Need to properly handle "sticky" case, when a group of requests must be routed through the same IO. Examples: "next page" requests, transactions, streaming, copy. One way to achieve this is to pass desired IO to "send" method, and return IO on which the request was executed back together with {{JdbcResult}}. # I would suggest to keep {{connected}} logic as simple as possible for now - {{true}} if and only if we successfully established connections to all nodes # Old logic should work fine with multiple established connections including proper "stickiness" > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation
Ivan Bessonov created IGNITE-11313: -- Summary: Cluster hangs on cache invoke with binary objects creation Key: IGNITE-11313 URL: https://issues.apache.org/jira/browse/IGNITE-11313 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Creating of binary objects in entry processors in parallel with continuous queries may lead to deadlock: {code:java} [2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible starvation in striped pool. Thread name: sys-stripe-13-#14 Queue: [] Deadlock: false Completed: 1 Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304) at o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178) at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141) at o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284) at o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202) at o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366) at o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189) at o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106) at o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68) at o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446) at o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302) at o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713) at o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103) at o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405) at o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569) at o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367) at o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171) at o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156) at o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118) at o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198) at o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196) at o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129) at o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594) at o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393) at o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319) at o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) at o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) at o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569) at o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197) at o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127) at o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093) at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505) at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120) at java.lang.Thread.run(Thread.java:748) {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11300) MVCC: forbid using DataStreamer with allowOverwrite=true
[ https://issues.apache.org/jira/browse/IGNITE-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767187#comment-16767187 ] Andrew Mashenkov commented on IGNITE-11300: --- [~Pavlukhin], With allowOverwrite=true each entry will be updated within separate implicit transaction and data streamer provides snapshot isolation guaranties only on per-entry basis. So, both policies looks safe as just skip operation on conflict as retry operation. The first policy looks simpliest and performant and second one may requires to resolve issues on unstable topologies (such as retry on recently updated top ver) to prevent deadlocks. With allowOverwrite=false we just put INITIAL entry version to the entry versions list and it may be impossible to overwrite already invisible entry. Assume, you have put entry into cache, then removed it and it wasn't cleaned with Vacuum due to some reason (some active Tx is on fly), and now you start DataStreamer with allowOverwrite=false that will try to insert INITIAL version. Will this change visible? Do we support this case correctly? > MVCC: forbid using DataStreamer with allowOverwrite=true > > > Key: IGNITE-11300 > URL: https://issues.apache.org/jira/browse/IGNITE-11300 > Project: Ignite > Issue Type: Task > Components: mvcc >Affects Versions: 2.7 >Reporter: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > > Calling {{IgniteDataStreamer.allowOverwrite(true)}} configures a streamer to > use single-key cache put/remove operations for data modification. But > put/remove operations on MVCC caches can be aborted due to write conflicts. > So, some development effort is needed to support that mode properly. Let's > throw exception in such case for MVCC caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11257: - Ignite Flags: (was: Docs Required) > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11287) JDBC Thin: best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11287: - Labels: iep-23 (was: iep-23 sql) > JDBC Thin: best effort affinity > --- > > Key: IGNITE-11287 > URL: https://issues.apache.org/jira/browse/IGNITE-11287 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > > It's an umbrella ticket for implementing > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11257: - Component/s: (was: sql) jdbc > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11287) JDBC Thin: best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11287: - Component/s: jdbc > JDBC Thin: best effort affinity > --- > > Key: IGNITE-11287 > URL: https://issues.apache.org/jira/browse/IGNITE-11287 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23, sql > Fix For: 2.8 > > > It's an umbrella ticket for implementing > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11287) JDBC Thin: best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11287: - Fix Version/s: 2.8 > JDBC Thin: best effort affinity > --- > > Key: IGNITE-11287 > URL: https://issues.apache.org/jira/browse/IGNITE-11287 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23, sql > Fix For: 2.8 > > > It's an umbrella ticket for implementing > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11287) JDBC Thin: best effort affinity
[ https://issues.apache.org/jira/browse/IGNITE-11287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11287: - Issue Type: New Feature (was: Task) > JDBC Thin: best effort affinity > --- > > Key: IGNITE-11287 > URL: https://issues.apache.org/jira/browse/IGNITE-11287 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > > It's an umbrella ticket for implementing > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > within the scope of JDBC Thin driver. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767185#comment-16767185 ] Vladimir Ozerov commented on IGNITE-11257: -- [~alapin], looks good, but please note that we can re-use 2_8_0 protocol version as it is not released yet. > JDBC Thin: update handshake protocol so that the node returns its UUID. > --- > > Key: IGNITE-11257 > URL: https://issues.apache.org/jira/browse/IGNITE-11257 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Add node UUID to successful handshake response. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-11258: Assignee: Alexander Lapin > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10937) Support data page scan for JDBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-10937: - Description: In scope jdbc v2 and thin drivers We need to add connection property that reflects states of data page scan feature: enabled/disabled/not defined. > Support data page scan for JDBC > --- > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergi Vladykin >Assignee: Pavel Kuznetsov >Priority: Major > Labels: performance > > In scope jdbc v2 and thin drivers > We need to add connection property that reflects states of data page scan > feature: enabled/disabled/not defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767165#comment-16767165 ] Ilya Suntsov commented on IGNITE-11216: --- [~dpavlov] in progress > Ignite.sh fails on Mac OS and Linux - Java 11 > - > > Key: IGNITE-11216 > URL: https://issues.apache.org/jira/browse/IGNITE-11216 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite.sh fails on Mac OS Mojave with the following JDK version: > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > The same issue is reproduced on Linux and the workaround is discussed here: > https://issues.apache.org/jira/browse/IGNITE-3 > The exception is as follows: > {noformat} > /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh: > line 40: [: -eq: unary operator expected > ./ignite.sh: line 152: [: -eq: unary operator expected > ./ignite.sh: line 157: [: -gt: unary operator expected > ./ignite.sh: line 170: [: -eq: unary operator expected > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) > to field java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @4f83df68 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11265) JVM Crashes on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767148#comment-16767148 ] Ignite TC Bot commented on IGNITE-11265: {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}Queries 1{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=3070375]] * IgniteBinaryCacheQueryTestSuite: IndexingCachePartitionLossPolicySelfTest.testReadWriteSafe - 0,0% fails in last 413 master runs. {color:#d04437}Cache (Failover) 1{color} [[tests 6|https://ci.ignite.apache.org/viewLog.html?buildId=3070339]] * IgniteCacheFailoverTestSuite: IgniteChangingBaselineUpCacheRemoveFailoverTest.testPutAndRemoveOptimisticSerializableTx - 0,0% fails in last 406 master runs. * IgniteCacheFailoverTestSuite: IgniteChangingBaselineDownCacheRemoveFailoverTest.testPutAndRemovePessimisticTx - 0,0% fails in last 406 master runs. * IgniteCacheFailoverTestSuite: IgniteChangingBaselineUpCacheRemoveFailoverTest.testPutAndRemove - 0,0% fails in last 406 master runs. * IgniteCacheFailoverTestSuite: IgniteChangingBaselineUpCacheRemoveFailoverTest.testPutAndRemovePessimisticTx - 0,0% fails in last 406 master runs. * IgniteCacheFailoverTestSuite: IgniteChangingBaselineDownCacheRemoveFailoverTest.testPutAndRemoveOptimisticSerializableTx - 0,0% fails in last 406 master runs. * IgniteCacheFailoverTestSuite: IgniteChangingBaselineDownCacheRemoveFailoverTest.testPutAndRemove - 0,0% fails in last 406 master runs. {color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0 TIMEOUT , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3070322]] * GridCachePartitionedNodeRestartTest.testRestartWithTxTenNodesTwoBackups (last started) {color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3070348]] * GridCacheDhtPreloadMultiThreadedSelfTest.testConcurrentNodesStartStop (last started) {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3070399&buildTypeId=IgniteTests24Java8_RunAll] > JVM Crashes on TeamCity > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Eduard Shangareev >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > Time Spent: 10m > Remaining Estimate: 0h > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767145#comment-16767145 ] Dmitriy Pavlov commented on IGNITE-11216: - [~ustas], could you please review this fix https://github.com/apache/ignite/pull/6095 ? IMO, LGTM, but it would be better if you can take a look, as well. > Ignite.sh fails on Mac OS and Linux - Java 11 > - > > Key: IGNITE-11216 > URL: https://issues.apache.org/jira/browse/IGNITE-11216 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Denis Magda >Assignee: Peter Ivanov >Priority: Blocker > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite.sh fails on Mac OS Mojave with the following JDK version: > java version "11.0.2" 2019-01-15 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode) > The same issue is reproduced on Linux and the workaround is discussed here: > https://issues.apache.org/jira/browse/IGNITE-3 > The exception is as follows: > {noformat} > /Users/dmagda/Downloads/apache-ignite-2.7.0-bin/bin/include/functions.sh: > line 40: [: -eq: unary operator expected > ./ignite.sh: line 152: [: -eq: unary operator expected > ./ignite.sh: line 157: [: -gt: unary operator expected > ./ignite.sh: line 170: [: -eq: unary operator expected > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.apache.ignite.internal.util.GridUnsafe$2 > (file:/Users/dmagda/Downloads/apache-ignite-2.7.0-bin/libs/ignite-core-2.7.0.jar) > to field java.nio.Buffer.address > WARNING: Please consider reporting this to the maintainers of > org.apache.ignite.internal.util.GridUnsafe$2 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > Exception in thread "main" java.lang.ExceptionInInitializerError > at > org.apache.ignite.internal.util.IgniteUtils.(IgniteUtils.java:795) > at > org.apache.ignite.lang.IgniteProductVersion.fromString(IgniteProductVersion.java:305) > at > org.apache.ignite.internal.IgniteVersionUtils.(IgniteVersionUtils.java:71) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.(CommandLineStartup.java:99) > Caused by: java.lang.RuntimeException: jdk.internal.misc.JavaNioAccess class > is unavailable. > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1453) > at > org.apache.ignite.internal.util.GridUnsafe.(GridUnsafe.java:112) > ... 4 more > Caused by: java.lang.IllegalAccessException: class > org.apache.ignite.internal.util.GridUnsafe cannot access class > jdk.internal.misc.SharedSecrets (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @4f83df68 > at > java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at > java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at > org.apache.ignite.internal.util.GridUnsafe.javaNioAccessObject(GridUnsafe.java:1450) > ... 5 more > {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10926) ZookeeperDiscoverySpi: client does not survive after several cluster restarts
[ https://issues.apache.org/jira/browse/IGNITE-10926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767129#comment-16767129 ] Dmitriy Pavlov commented on IGNITE-10926: - [~ivan.glukos] thank you for picking up this merge. > ZookeeperDiscoverySpi: client does not survive after several cluster restarts > - > > Key: IGNITE-10926 > URL: https://issues.apache.org/jira/browse/IGNITE-10926 > Project: Ignite > Issue Type: Bug > Components: zookeeper >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > {{ZookeeperDiscoveryImpl#cleanupPreviousClusterData}} can delete alive node > of a client in case of low internal order. > Steps to reproduce: > 1. Start server and client. > 2. Stop the server and wait for the client disconnected. > 3. Start and stop the server. The server hasn't time to process client join > request. > 4. Start server. It will delete alive client node because the client has low > internal order. The client will never connect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11304) SQL: Common caching of both local and distributed query metadata
[ https://issues.apache.org/jira/browse/IGNITE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767127#comment-16767127 ] Ignite TC Bot commented on IGNITE-11304: {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}Cache 7{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=3076311]] * IgniteCacheTestSuite7: TxRollbackAsyncWithPersistenceTest.testSynchronousRollback - 0,0% fails in last 416 master runs. {color:#d04437}MVCC Cache{color} [[tests 1|https://ci.ignite.apache.org/viewLog.html?buildId=3076288]] * IgniteCacheMvccTestSuite: CacheMvccVacuumTest.testVacuumNotStartedOnNonAffinityNode - 0,0% fails in last 182 master runs. {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3076357&buildTypeId=IgniteTests24Java8_RunAll] > SQL: Common caching of both local and distributed query metadata > > > Key: IGNITE-11304 > URL: https://issues.apache.org/jira/browse/IGNITE-11304 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently query metadata is only cached for distributed queries. For local > queries it is calculated on every request over and over again. Need to cache > it always in {{QueryParserResultSelect}}. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767124#comment-16767124 ] Alexander Lapin edited comment on IGNITE-11258 at 2/13/19 12:35 PM: [~vozerov] Ready for preliminary review. Please, pay attention, that given ticket also contains changes from IGNITE-11257. was (Author: alapin): [~vozerov] Ready for preliminary review. > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767124#comment-16767124 ] Alexander Lapin commented on IGNITE-11258: -- [~vozerov] Ready for preliminary review. > JDBC Thin: update connection setup logic. > - > > Key: IGNITE-11258 > URL: https://issues.apache.org/jira/browse/IGNITE-11258 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Lapin >Priority: Major > Labels: iep-23 > Time Spent: 10m > Remaining Estimate: 0h > > # On thin client startup it connects to *all* *nodes* provided by user by > client configuration. > # Upon handshake server returns its UUID to client. > # By the end of the startup procedure, client have open connections to all > available server nodes and the following mapping (*nodeMap*): [UUID => > Connection]. > Connection to all nodes helps to identify available nodes, but can lead to > significant delay, when thin client is used on a large cluster with a long IP > list provided by user. To lower this delay, asynchronous establishment of > connections can be used. > For more information see [IEP-23: Best Effort > Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11298) TcpCommunicationSpi does not support TLSv1.3
[ https://issues.apache.org/jira/browse/IGNITE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11298: - Description: When started on Java 11 we cannot form a secure cluster - Discovery will happily use the default TLSv1.3 but Communication will fail with its custom SSLEngine-using code. Need to fix that. Until that, nodes may be salvaged by setProtocol("TLSv1.2") on SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2" was: When started on Java 11 we cannot form a secure cluster - Discovery will happily use the default TLSv1.2 but Communication will fail with its custom SSLEngine-using code. Need to fix that. Until that, nodes may be salvaged by setProtocol("TLSv1.2") on SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2" > TcpCommunicationSpi does not support TLSv1.3 > > > Key: IGNITE-11298 > URL: https://issues.apache.org/jira/browse/IGNITE-11298 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Labels: Java11 > > When started on Java 11 we cannot form a secure cluster - Discovery will > happily use the default TLSv1.3 but Communication will fail with its custom > SSLEngine-using code. > Need to fix that. > Until that, nodes may be salvaged by setProtocol("TLSv1.2") on > SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11310) SQL: Remove special interaction between query parallelism and distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-11310: - Summary: SQL: Remove special interaction between query parallelism and distributed joins (was: SQL: remove special interaction between query parallelism and distributed joins) > SQL: Remove special interaction between query parallelism and distributed > joins > --- > > Key: IGNITE-11310 > URL: https://issues.apache.org/jira/browse/IGNITE-11310 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we enable so-called "local distributed joins" when query is > executed locally with enabled parallelism. This behavior is not needed and > needs to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11310) SQL: remove special interaction between query parallelism and distributed joins
[ https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767099#comment-16767099 ] Vladimir Ozerov commented on IGNITE-11310: -- A number of new failures appeared. Some of them are due to incorrect tests (e.g. missing collocation). But some of them show actual cause of "distributedJoins" flag magic. When "local" flag is set we need to query local partitions. If parallelism is enabled, then we have to query each stripe separately, and then merge the result using standard two-phase flow. For some reason "distributedJoins" flag was used to force query split and execution in two-step mode. This is wrong. What we need to do instead, is to add special flag "split needed" to parsing result. Then this flag should be used to decide how query is executed - with or without split. Previous PRs are removed since their implementation was incorrect. > SQL: remove special interaction between query parallelism and distributed > joins > --- > > Key: IGNITE-11310 > URL: https://issues.apache.org/jira/browse/IGNITE-11310 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we enable so-called "local distributed joins" when query is > executed locally with enabled parallelism. This behavior is not needed and > needs to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
Stanislav Lukyanov created IGNITE-11312: --- Summary: JDBC: Thin driver doesn't reports incorrect property names Key: IGNITE-11312 URL: https://issues.apache.org/jira/browse/IGNITE-11312 Project: Ignite Issue Type: Improvement Components: jdbc Reporter: Stanislav Lukyanov JDBC driver reports the properties it supports via getPropertyInfo method. It currently reports the property names as simple strings, like "enforceJoinOrder". However, when the properties are processed on connect they are looked up with prefix "ignite.jdbc", e.g. "ignite.jdbc.enforceJoinOrder". Because of this UI tools like DBeaver can't properly pass the properties to Ignite. For example, when "enforceJoinOrder" is set to true in "Connection settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11267) Print warning when keystore password arguments are used in control.sh (bat)
[ https://issues.apache.org/jira/browse/IGNITE-11267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767044#comment-16767044 ] Ignite TC Bot commented on IGNITE-11267: {panel:title=--> Run :: All: No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3060237&buildTypeId=IgniteTests24Java8_RunAll] > Print warning when keystore password arguments are used in control.sh (bat) > --- > > Key: IGNITE-11267 > URL: https://issues.apache.org/jira/browse/IGNITE-11267 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Control utility gets keystore/truststore password either as command line > argument or as console input. Former way is insecure, and user should be > warned. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-11247) MVCC: Tests has been forgotten to unmute.
[ https://issues.apache.org/jira/browse/IGNITE-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reopened IGNITE-11247: --- > MVCC: Tests has been forgotten to unmute. > - > > Key: IGNITE-11247 > URL: https://issues.apache.org/jira/browse/IGNITE-11247 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1 > Time Spent: 10m > Remaining Estimate: 0h > > There are muted\ignored tests that are not being run on TC, but tickets for > fixing them looks already resolved. > Let's recheck those tests and either unmute them or create a new tickets to > fix lately if needed. > IgniteBasicWithPersistenceTestSuite > * testIoomErrorMvccPdsHandling - IGNITE-10185 > IgniteCacheMvccSqlTestSuite > * testSqlReadInsideTxInProgressCoordinatorFails - IGNITE-8841 > * testSqlReadInsideTxInProgressCoordinatorFails_ReadDelay - IGNITE-8841 > * > testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml > - IGNITE-10752 > * testAccountsTxSql_SingleNode_CoordinatorFails_Persistence - IGNITE-10753 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-11312: Labels: newbie (was: ) > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Priority: Major > Labels: newbie > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11247) MVCC: Tests has been forgotten to unmute.
[ https://issues.apache.org/jira/browse/IGNITE-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov resolved IGNITE-11247. --- Resolution: Fixed Muted failed tests with IGNITE-11311 > MVCC: Tests has been forgotten to unmute. > - > > Key: IGNITE-11247 > URL: https://issues.apache.org/jira/browse/IGNITE-11247 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1 > Time Spent: 10m > Remaining Estimate: 0h > > There are muted\ignored tests that are not being run on TC, but tickets for > fixing them looks already resolved. > Let's recheck those tests and either unmute them or create a new tickets to > fix lately if needed. > IgniteBasicWithPersistenceTestSuite > * testIoomErrorMvccPdsHandling - IGNITE-10185 > IgniteCacheMvccSqlTestSuite > * testSqlReadInsideTxInProgressCoordinatorFails - IGNITE-8841 > * testSqlReadInsideTxInProgressCoordinatorFails_ReadDelay - IGNITE-8841 > * > testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml > - IGNITE-10752 > * testAccountsTxSql_SingleNode_CoordinatorFails_Persistence - IGNITE-10753 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11247) MVCC: Tests has been forgotten to unmute.
[ https://issues.apache.org/jira/browse/IGNITE-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767058#comment-16767058 ] Ignite TC Bot commented on IGNITE-11247: {panel:title=--> Run :: All: Possible Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}MVCC Queries{color} [[tests 5|https://ci.ignite.apache.org/viewLog.html?buildId=3039187]] * IgniteCacheMvccSqlTestSuite: CacheMvccPartitionedSqlCoordinatorFailoverTest.testAccountsTxSql_SingleNode_CoordinatorFails_Persistence - 0,0% fails in last 0 master runs. * IgniteCacheMvccSqlTestSuite: CacheMvccReplicatedSqlCoordinatorFailoverTest.testAccountsTxSql_SingleNode_CoordinatorFails_Persistence - 0,0% fails in last 0 master runs. {color:#d04437}PDS (Indexing){color} [[tests 2|https://ci.ignite.apache.org/viewLog.html?buildId=3060610]] * IgnitePdsWithIndexingTestSuite: IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes - 3,1% fails in last 417 master runs. {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3037821&buildTypeId=IgniteTests24Java8_RunAll] > MVCC: Tests has been forgotten to unmute. > - > > Key: IGNITE-11247 > URL: https://issues.apache.org/jira/browse/IGNITE-11247 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1 > Time Spent: 10m > Remaining Estimate: 0h > > There are muted\ignored tests that are not being run on TC, but tickets for > fixing them looks already resolved. > Let's recheck those tests and either unmute them or create a new tickets to > fix lately if needed. > IgniteBasicWithPersistenceTestSuite > * testIoomErrorMvccPdsHandling - IGNITE-10185 > IgniteCacheMvccSqlTestSuite > * testSqlReadInsideTxInProgressCoordinatorFails - IGNITE-8841 > * testSqlReadInsideTxInProgressCoordinatorFails_ReadDelay - IGNITE-8841 > * > testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml > - IGNITE-10752 > * testAccountsTxSql_SingleNode_CoordinatorFails_Persistence - IGNITE-10753 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11311) MVCC: SQL full table scan query can return duplicates.
[ https://issues.apache.org/jira/browse/IGNITE-11311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11311: -- Ignite Flags: (was: Docs Required) > MVCC: SQL full table scan query can return duplicates. > -- > > Key: IGNITE-11311 > URL: https://issues.apache.org/jira/browse/IGNITE-11311 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Andrew Mashenkov >Priority: Major > > SQL query like "select * from table" can return duplicate rows. > Possible reasons can be > * due to SQL query iterates over data pages directly and can see > inconsistent state (IGNITE-10561) > * Same as IGNITE-10767, query see stale pages. > * Smth is wrong with mvcc versions visibility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11311) MVCC: SQL full table scan query can return duplicates.
Andrew Mashenkov created IGNITE-11311: - Summary: MVCC: SQL full table scan query can return duplicates. Key: IGNITE-11311 URL: https://issues.apache.org/jira/browse/IGNITE-11311 Project: Ignite Issue Type: Bug Components: mvcc, sql Reporter: Andrew Mashenkov SQL query like "select * from table" can return duplicate rows. Possible reasons can be * due to SQL query iterates over data pages directly and can see inconsistent state (IGNITE-10561) * Same as IGNITE-10767, query see stale pages. * Smth is wrong with mvcc versions visibility. -- This message was sent by Atlassian JIRA (v7.6.3#76005)