[jira] [Updated] (IGNITE-4035) SQL: Avoid excessive calls of deterministic functions on same arguments

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

 [ 
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 (JIRA)]

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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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)
>   

[jira] [Resolved] (IGNITE-4327) Failed to INSERT array of Bytes from SELECT

[Vladimir Ozerov (JIRA)]

 [ 
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 
> 

[jira] [Closed] (IGNITE-4489) Maintain correct MERGE semantic in DML

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Ivan Pavlukhin (JIRA)]

 [ 
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

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Peter Ivanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

 [ 
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

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Vasiliy Sisko (JIRA)]

 [ 
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

[Vasiliy Sisko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

 [ 
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

[Pavel Konstantinov (JIRA)]

 [ 
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

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Pavel Konstantinov (JIRA)]

 [ 
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

[Evgenii Zhuravlev (JIRA)]

 [ 
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

[Evgenii Zhuravlev (JIRA)]

 [ 
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

[Evgenii Zhuravlev (JIRA)]

 [ 
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

[Evgenii Zhuravlev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Dmitriy Pavlov (JIRA)]

 [ 
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

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Denis Magda (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Igor Kamyshnikov (JIRA)]

 [ 
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

[Igor Kamyshnikov (JIRA)]

 [ 
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 

[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

[Igor Kamyshnikov (JIRA)]

 [ 
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

[Igor Kamyshnikov (JIRA)]

 [ 
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

[Igor Kamyshnikov (JIRA)]

 [ 
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

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3077535buildTypeId=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=7945125576049372508=%3Cdefault%3E=testDetails],
>  
> [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8412476034648229784=%3Cdefault%3E=testDetails],
>  
> [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=254244004184327163=%3Cdefault%3E=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

[Ivan Bessonov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3070785buildTypeId=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

[Ilya Suntsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3070399buildTypeId=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 (JIRA)]

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

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Alexander Lapin (JIRA)]

 [ 
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 (JIRA)]

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.

[Alexander Lapin (JIRA)]

 [ 
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.

[Alexander Lapin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.4.jar:2.1.4]
>  

[jira] [Commented] (IGNITE-10644) CorruptedTreeException might occur after force node kill during transaction

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: 4071535538120363041, val: 
> 

[jira] [Commented] (IGNITE-6580) Cluster can fail during concurrent re-balancing and cache destruction

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 

[jira] [Updated] (IGNITE-11299) During SSL Handshake GridNioServer.processWrite is invoked constantly

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=IgniteTests24Java8_SpiWindows
https://ci.ignite.apache.org/viewLog.html?buildId=3077015=queuedBuildOverviewTab
https://ci.ignite.apache.org/viewLog.html?buildId=3076776=IgniteTests24Java8_CacheFailoverSsl=testsInfo
https://ci.ignite.apache.org/viewLog.html?buildId=3076778=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

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3071265buildTypeId=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

[Igor Seliverstov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=7945125576049372508=%3Cdefault%3E=testDetails],
>  
> [two|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8412476034648229784=%3Cdefault%3E=testDetails],
>  
> [three|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=254244004184327163=%3Cdefault%3E=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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Ivan Pavlukhin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[Andrew Mashenkov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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.

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Vladimir Ozerov (JIRA)]

 [ 
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

[Pavel Kuznetsov (JIRA)]

 [ 
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-11265) JVM Crashes on TeamCity

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3070399buildTypeId=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

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-10926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3076357buildTypeId=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.

[Alexander Lapin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Alexander Lapin (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Ilya Kasnacheev (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

 [ 
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

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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)

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3060237buildTypeId=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.

[Andrew Mashenkov (JIRA)]

 [ 
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

[Stanislav Lukyanov (JIRA)]

 [ 
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.

[Andrew Mashenkov (JIRA)]

 [ 
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.

[Ignite TC Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=3037821buildTypeId=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.

[Andrew Mashenkov (JIRA)]

 [ 
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 (JIRA)]

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)

[jira] [Closed] (IGNITE-10759) Disable implicit distributed joins when queryParallelizm>1.

[Vladimir Ozerov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-10759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov closed IGNITE-10759.


> Disable implicit distributed joins when queryParallelizm>1.
> ---
>
> Key: IGNITE-10759
> URL: https://issues.apache.org/jira/browse/IGNITE-10759
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For now, local query with queryParallelizm>1 enables joins between partitions 
> on same even if distributedJoins flag is false.
> This behaviour is unexpected and can't be disabled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)