[jira] [Commented] (IGNITE-11247) MVCC: Tests has been forgotten to unmute.
[ https://issues.apache.org/jira/browse/IGNITE-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765762#comment-16765762 ] Andrew Mashenkov commented on IGNITE-11247: --- All test look ok, excepts testAccountsTxSql_SingleNode_CoordinatorFails_Persistence one. Looks like SQL can see stale data on unstable topology. > 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-8368) Reimplement queries notebooks list table wth pc-items-table'
[ https://issues.apache.org/jira/browse/IGNITE-8368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765761#comment-16765761 ] Alexander Kalinin commented on IGNITE-8368: --- Let\s do it not with pc-items-table, but with ignite-grid-table instead. > Reimplement queries notebooks list table wth pc-items-table' > > > Key: IGNITE-8368 > URL: https://issues.apache.org/jira/browse/IGNITE-8368 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Minor > > Currently notebooks list table is implemented with pure ui-grid directive. > But now we have a component 'pc-items-table', which enfolds higher > abstractions. For better managability we should reimplement this table with > pc-items-table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11165) Add note to the documentation that cache name will be used as folder name in case of using persistence
[ https://issues.apache.org/jira/browse/IGNITE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765753#comment-16765753 ] Artem Budnikov commented on IGNITE-11165: - Added a callout on page [https://apacheignite.readme.io/v2.7/docs/jcache] > 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-11253) When a node that is not part of the baseline topology joins the cluster, it may lead to a node failure.
[
https://issues.apache.org/jira/browse/IGNITE-11253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765746#comment-16765746
]
Ignite TC Bot commented on IGNITE-11253:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=3066504]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3064210buildTypeId=IgniteTests24Java8_RunAll]
> When a node that is not part of the baseline topology joins the cluster, it
> may lead to a node failure.
> ---
>
> Key: IGNITE-11253
> URL: https://issues.apache.org/jira/browse/IGNITE-11253
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * In case of eager TTL is configured, a starting node creates and starts
> {{cleanupWorker}} (see {{GridCacheTtlManager.start0()}})
> * {{GridCacheSharedTtlCleanupManager.CleanupWorker}}, in its turn, has to
> wait for {{discovery().localJoin()}} future that is completed by discovery
> thread.
> * On the other hand, the exchange thread stops cache contexts and,
> therefore, it stops the {{cleanupWorker}} as well.
>
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager.stopCleanupWorker(GridCacheSharedTtlCleanupManager.java:109)
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager.unregister(GridCacheSharedTtlCleanupManager.java:82)
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.onKernalStop0(GridCacheTtlManager.java:110)
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStop(GridCacheManagerAdapter.java:111)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1495)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStopCaches(GridCacheProcessor.java:1182)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onBaselineChange(GridCacheProcessor.java:5637)
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:910)
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:792)
> {code}
> So, exchange thread may try to stop the {{cleanupWorker}} before the
> {{localJoin}} future is completed by discovery thread. Unfortunately,
> `cleanupWorker` incorrectly handles this situation, and this fact can lead to
> a node failure:
> {code:java}
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: Got
> interrupted while waiting for future to complete.]]
> class org.apache.ignite.IgniteException: Got interrupted while waiting for
> future to complete.
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2217)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:136)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.IgniteInterruptedCheckedException: Got interrupted
> while waiting for future to complete.
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:186)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2214)
> ... 3 more
> {code}
> The obvious fix is changing the catch block
> {code:java}
> catch (Throwable t) {
> if (!(t instanceof IgniteInterruptedCheckedException))
> err = t;
> throw t;
> }
> {code}
> to the following:
> {code:java}
> catch (Throwable t) {
> if (!(X.hasCause(t, IgniteInterruptedCheckedException.class)))
> err = t;
> throw t;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11282) NullPointerException if transaction enabled and using byte[] for key/value
[
https://issues.apache.org/jira/browse/IGNITE-11282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Akkuratov reassigned IGNITE-11282:
---
Assignee: Igor Akkuratov
> NullPointerException if transaction enabled and using byte[] for key/value
> --
>
> Key: IGNITE-11282
> URL: https://issues.apache.org/jira/browse/IGNITE-11282
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Courtney
>Assignee: Igor Akkuratov
>Priority: Blocker
> Attachments: Screen Shot 2019-02-10 at 15.02.19.png
>
>
> I have debugged this and found the problem is because of hashCode comparison
> failure. You can see in the screenshot below.
> {code:java}
> txMap == null ? null : txMap.get(key)
> {code}
> this will fail to get the entry but they the key is in fact in the map, it's
> the only entry and if a proper array comparison is done e.g. using
> `Arrays.equals` as shown in the eval window then the key would match. !Screen
> Shot 2019-02-10 at 15.02.19.png!
> If running without `-ea` then the exception is
> {code:java}
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> io.hypi.arc.ignite.ArcIgniteUtils.lambda$asFuture$f0cf812f$1(ArcIgniteUtils.java:21)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:215)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl$InternalFutureListener.apply(IgniteFutureImpl.java:179)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:81)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:300)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:287)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:349)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:337)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:497)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:476)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:81)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
>
[jira] [Commented] (IGNITE-11091) Visor shows all indexes in upper case
[
https://issues.apache.org/jira/browse/IGNITE-11091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765425#comment-16765425
]
Ignite TC Bot commented on IGNITE-11091:
{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=3015773buildTypeId=IgniteTests24Java8_RunAll]
> Visor shows all indexes in upper case
> -
>
> Key: IGNITE-11091
> URL: https://issues.apache.org/jira/browse/IGNITE-11091
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.5, 2.6, 2.7
>Reporter: Igor Akkuratov
>Assignee: Igor Akkuratov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765303#comment-16765303
]
Peter Ivanov commented on IGNITE-11216:
---
[~dpavlov] — fix is valid.
Unfortunately, no {{JAVA_HOME}} at all was not in consideration.
> 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: 20m
> 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-10206) Allow specifying query parallelism in CREATE TABLE's WITH "" clause
[
https://issues.apache.org/jira/browse/IGNITE-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765274#comment-16765274
]
Ignite TC Bot commented on IGNITE-10206:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=3061557]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3061582buildTypeId=IgniteTests24Java8_RunAll]
> Allow specifying query parallelism in CREATE TABLE's WITH "" clause
> ---
>
> Key: IGNITE-10206
> URL: https://issues.apache.org/jira/browse/IGNITE-10206
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As in
> {code}
> CREATE TABLE foo (id long primary key, val varchar) WITH "backups=1,
> query_parallelism=4";
> {code}
> Currently it is possible to specify e.g. backups but not query_parallelism.
> This leads to necessity to specify cache template for such tables, which is
> cumbersome.
> Moreover, people may ignore this option outright and get worse performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765262#comment-16765262
]
Dmitriy Govorukhin commented on IGNITE-10908:
-
[~slava.koptilin] Looks good to me, merged.
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765264#comment-16765264
]
Ignite TC Bot commented on IGNITE-11177:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3061627]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=3061680]]
{color:#d04437}SPI{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3061620]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiSelfTest.testDisconnectAfterNetworkTimeout - 0,0% fails in
last 425 master runs.
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3038319]]
* IgniteBinaryCacheQueryTestSuite:
IgniteDynamicSqlRestoreTest.testIndexCreationWhenNodeStopped - 0,0% fails in
last 420 master runs.
{color:#d04437}Thin Client: Java{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=3061611]]
* ClientTestSuite:
FunctionalQueryTest.testGettingEmptyResultWhenQueryingEmptyTable - 0,0% fails
in last 413 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3061705buildTypeId=IgniteTests24Java8_RunAll]
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin resolved IGNITE-10908.
-
Resolution: Fixed
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov resolved IGNITE-10118.
--
Resolution: Duplicate
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10118) JDBC v2: metadata.getSchemas returns cache names instead of schema names
[
https://issues.apache.org/jira/browse/IGNITE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765153#comment-16765153
]
Pavel Kuznetsov commented on IGNITE-10118:
--
[~vozerov] looked at the this issue patch. Due to IGNITE-9989 introduced big
change into jdbc v2 metadata, it fixed this issue as well; Also it introduced
the same test.
Closing as duplicate of 9989
> JDBC v2: metadata.getSchemas returns cache names instead of schema names
>
>
> Key: IGNITE-10118
> URL: https://issues.apache.org/jira/browse/IGNITE-10118
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> jdbc v2 returns list of cache names instead of list of schemas.
> It is correct only if we have a cache and table created in it using cache API.
> If we create tables using ddl we expect to see "PUBLIC" schema name in
> results of {{connection.getMetadata().getSchemas()}} not
> "SQL_PUBLIC_TABLENAME"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10644) CorruptedTreeException might occur after force node kill during transaction
[
https://issues.apache.org/jira/browse/IGNITE-10644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765123#comment-16765123
]
Ilya Kasnacheev commented on IGNITE-10644:
--
I can also get JVM crash:
{code}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7f0d91a9748f, pid=22056, tid=0x7f0d64eda700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build
1.8.0_144-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# J 3661 C2
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(J)Lorg/apache/ignite/internal/processors/cache/persistence/tree/io/PageIO;
(76 bytes) @ 0x7f0d91a9748f [0x7f0d91a97460+0x2f]
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/gridgain/w/index-reproducer/hs_err_pid22056.log
Compiled method (c2) 10820 3661 4
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions::forPage
(76 bytes)
total in heap [0x7f0d91a97310,0x7f0d91a97620] = 784
relocation [0x7f0d91a97438,0x7f0d91a97450] = 24
main code [0x7f0d91a97460,0x7f0d91a97520] = 192
stub code [0x7f0d91a97520,0x7f0d91a97538] = 24
oops [0x7f0d91a97538,0x7f0d91a97540] = 8
metadata [0x7f0d91a97540,0x7f0d91a97550] = 16
scopes data[0x7f0d91a97550,0x7f0d91a975b8] = 104
scopes pcs [0x7f0d91a975b8,0x7f0d91a97608] = 80
dependencies [0x7f0d91a97608,0x7f0d91a97610] = 8
nul chk table [0x7f0d91a97610,0x7f0d91a97620] = 16
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
{code}
> 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
>
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765131#comment-16765131
]
Dmitriy Pavlov commented on IGNITE-11216:
-
[~Artukhov] please align the solution with [~vveider]. I can merge second
commit once it is clear how to handle
> 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: 20m
> 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-11291) Assertion error in time of rebalance completion lead to to critical failure node
[
https://issues.apache.org/jira/browse/IGNITE-11291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-11291:
--
Assignee: Alexei Scherbakov
> Assertion error in time of rebalance completion lead to to critical failure
> node
>
>
> Key: IGNITE-11291
> URL: https://issues.apache.org/jira/browse/IGNITE-11291
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Alexei Scherbakov
>Priority: Major
>
> {noformat}
> java.lang.AssertionError: Got removed exception on entry with dht local
> candidate: [IgniteTxEntry [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], cacheId=-313938805,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], cacheId=-313938805],
> val=[op=UPDATE,
> val=com.sbt.bm.ucp.common.dpl.model.party.hashcodes.DPartyHashCode_DPL_PROXY
> [idHash=1985166276, hash=1530579783, colocationKey=11859, sync Flag=null,
> hashUpdateTime=Sat Feb 09 20:16:55 MSK 2019, lastChangeDate=1549732615042,
> partition_DPL_id=4, ownerId=ucp, externalSystem=21,
> serializedHashCodesMap={"Address":["581a1367d4f50172c41168747c99105df1d3a4c6","24d3413bc5d3151dd784e088eaf4603e8e86c40b","fd7ce1449cd539a5976d358fb15060820c630f36"],"BirthDate":["a5cc7c1ac9821a6b19a455ae7eac55f4a4475bd7","415fe3810f8c4555a7188fe62275b34cdd1384cd","1311875998ef2aaccc5860ac6f991107ad4fa558"],"BirthPlace":["2fb5ea4cf7e9cfbdf77baae18f26804a10f51d57","76ddc5f2d959d27044c180957d9d0aed7369c0a2"],"Gender":["ad99678bb0e6de91d6a2ce620ba4fa98206aa9b9"],"IndividualIdentification":["c5b73f0087461fa4b980362344d38afddd1677b6","157952428fbe8c5b80da4db12c945cb4ad1f33f8","4d2257f62b1aa9cf290728d147776dd569b226a7"],"IndividualName":["256dba12a3b9d95dc1ada524d1a67cb590eb3ec2","2302eda39fb8f3751f3646542ad54ae717f5bc2c","9b8084de661530d5dc6ea140df793f4aa417a114"],"PartyToPartyGroup":["8d41984edf2e9ff916da0a74b884554cc2fceca9"],"PhoneNumber":["c89cbfb741ba5ea0fa13091a1cc7591c69374c0c","149081529b36fe29bc72bf88c66e51bdab3ae2d7","3c6bc9cc9e47ecd2f79b1506a22799ba69b95227","389830cd794fd6748f46ab7d8d878a2fec75cf63","9d5c3ecd5c951a16745cefd771b79c17bbc8c665","dfd8959391fd18e89505bfde31e0aa9a80513fec"],"Individual":["82dc325513d53990709bafbf1a334b602025ba17","544aab947d3a33787c7feffc93c4a4572e957dca","2728a40ce9759fa7110bc5d0d3c8b5c193210a2d"]},
> uid=null, isDeleted=false, isImmutable=false, checksum=null,
> id=3338011748811769508, externalClientId=75662144,
> colocationId=1216693183554769678]], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=false,
> entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], val=null, startVer=1551196730698,
> ver=GridCacheVersion [topVer=156972865, order=1546089814280, nodeOrder=65],
> hash=777160356, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=2147483647, order=0, nodeOrder=0]],
> flags=2]GridDistributedCacheEntry [super=]GridDhtCacheEntry [rdrs=ReaderId[]
> [], part=11859, super=], prepared=1, locked=false, nodeId=null,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=2,
> partUpdateCntr=0, serReadVer=GridCacheVersion[topVer=156972865,
> order=1546089814280, nodeOrder=65], xidVer=null]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.checkReadConflict(GridDhtTxPrepareFuture.java:1164)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:701)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:696)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
>
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765112#comment-16765112
]
Ivan Artukhov commented on IGNITE-11216:
Checked on Ubuntu 18.04.1 and OracleJDK 11.0.2. I get the following error if
*JAVA_HOME* variable is *unset*:
{code}
bin/include/functions.sh: line 64: JAVA_HOME: unbound variable
{code}
Proposed fix:
{code}
if [ "${JAVA_HOME:-}" = "" ]; then
{code}
> 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: 20m
> 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] [Updated] (IGNITE-11293) NPE in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11293:
---
Fix Version/s: 2.8
> NPE in TcpCommunicationSpi
> --
>
> Key: IGNITE-11293
> URL: https://issues.apache.org/jira/browse/IGNITE-11293
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes this exception is happening during "stopAllGrids" method execution
> in tests:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
> is already in invalid state at this point so "log" and some other fields are
> nulls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765106#comment-16765106
]
Aleksey Plekhanov commented on IGNITE-11177:
[~pkouznet] you can also simplify test and remove reflection, by using
something like this:
{code:java}
public void testDurationMetricsCanBeLonger24Hours() throws Exception {
long LONG_DURATION_MS = TimeUnit.DAYS.toMillis(365);
IgniteEx ignite =
startGrid(getConfiguration().setMetricsUpdateFrequency(500L));
GridJobMetricsProcessor jobMetricsProc = new
GridJobMetricsProcessor(ignite.context()) {
@Override public GridJobMetrics getJobMetrics() {
return new GridJobMetrics() {
@Override public long getTotalJobsExecutionTime() {
return LONG_DURATION_MS;
}
};
}
};
((GridKernalContextImpl)ignite.context()).add(jobMetricsProc);
List durationMetrics = execSql(ignite, "SELECT TOTAL_JOBS_EXECUTE_TIME
FROM IGNITE.NODE_METRICS").get(0);
assertEquals(LONG_DURATION_MS, durationMetrics.get(0));
}
{code}
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11293) NPE in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11293:
---
Labels: MakeTeamcityGreenAgain (was: )
> NPE in TcpCommunicationSpi
> --
>
> Key: IGNITE-11293
> URL: https://issues.apache.org/jira/browse/IGNITE-11293
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes this exception is happening during "stopAllGrids" method execution
> in tests:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
> is already in invalid state at this point so "log" and some other fields are
> nulls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10069) SQL implicit schema is incorrectly resolved in native api.
[
https://issues.apache.org/jira/browse/IGNITE-10069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10069:
Assignee: Pavel Kuznetsov
> SQL implicit schema is incorrectly resolved in native api.
> --
>
> Key: IGNITE-10069
> URL: https://issues.apache.org/jira/browse/IGNITE-10069
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> Without explicit schema declaration (either sql syntax SCHEMA.TABLE or
> SqlFieldsQuery#setSchema), do:
> 1) Create table using cache.query()
> 2) Perform select to this table
> reproducer:
> {noformat}
> public void testSchema(){
> IgniteCache c = ignite.getOrCreateCache("testCache");
> c.query(new SqlFieldsQuery("CREATE TABLE TEST1 (ID LONG PRIMARY KEY,
> VAL LONG) WITH \"template=replicated\";")).getAll();
> c.query(new SqlFieldsQuery("SELECT * FROM TEST1")).getAll();
> }
> {noformat}
> Got exception:
> {noformat}
> javax.cache.CacheException: Failed to parse query. Таблица "TEST1" не найдена
> Table "TEST1" not found; SQL statement:
> SELECT * FROM TEST1 [42102-197]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.internal.processors.query.h2.sql.ExplainSelfTest.testSchema(ExplainSelfTest.java:119)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2209)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query. Таблица "TEST1" не найдена
> Table "TEST1" not found; SQL statement:
> SELECT * FROM TEST1 [42102-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2628)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2327)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2171)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2141)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2136)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2713)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2150)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
> ... 12 more
> Caused by: org.h2.jdbc.JdbcSQLException: Таблица "TEST1" не найдена
> Table "TEST1" not found; SQL statement:
> SELECT * FROM TEST1 [42102-197]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5920)
> at org.h2.command.Parser.readTableFilter(Parser.java:1430)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:2138)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2287)
> at org.h2.command.Parser.parseSelectSub(Parser.java:2133)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1946)
> at org.h2.command.Parser.parseSelect(Parser.java:1919)
> at org.h2.command.Parser.parsePrepared(Parser.java:463)
> at org.h2.command.Parser.parse(Parser.java:335)
> at org.h2.command.Parser.parse(Parser.java:307)
> at org.h2.command.Parser.prepareCommand(Parser.java:278)
>
[jira] [Assigned] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10414:
Assignee: Pavel Kuznetsov
> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Kuznetsov
>Priority: Major
>
> Reproducer:
>
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
> Error:
> {code:java}
> (err) DDL operation failureSchemaOperationException [code=3, msg=Table
> already exists: CITY]
> at
> org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Exception in thread "main" javax.cache.CacheException: Table already exists:
> CITY
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Table already
> exists: CITY
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
> at
>
[jira] [Assigned] (IGNITE-10937) Support data page scan for JDBC/ODBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-10937: Assignee: Pavel Kuznetsov > Support data page scan for JDBC/ODBC > > > 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 > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765076#comment-16765076
]
Pavel Kuznetsov commented on IGNITE-11177:
--
[~vozerov] ready for review.
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11293) NPE in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11293:
---
Description:
Sometimes this exception is happening during "stopAllGrids" method execution in
tests:
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
is already in invalid state at this point so "log" and some other fields are
nulls.
was:
Sometimes this exception is happening in "stopAllGrids" method in tests:
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
is already in invalid state at this point so "log" and some other fields are
nulls.
> NPE in TcpCommunicationSpi
> --
>
> Key: IGNITE-11293
> URL: https://issues.apache.org/jira/browse/IGNITE-11293
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes this exception is happening during "stopAllGrids" method execution
> in tests:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
>
[jira] [Updated] (IGNITE-11293) NPE in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-11293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11293:
---
Description:
Sometimes this exception is happening in "stopAllGrids" method in tests:
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
is already in invalid state at this point so "log" and some other fields are
nulls.
was:
Sometimes this exception is happening in "stopAllGrids" method in tests:
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Reason is interruption thrown from TcpCommunicationSpi#reserveClient, SPI is
already in invalid state at this point so "log" and some other fields are nulls.
> NPE in TcpCommunicationSpi
> --
>
> Key: IGNITE-11293
> URL: https://issues.apache.org/jira/browse/IGNITE-11293
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>
> Sometimes this exception is happening in "stopAllGrids" method in tests:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reason is the interruption thrown from TcpCommunicationSpi#reserveClient, SPI
> is already in invalid state at this point so "log" and some other fields are
> nulls.
[jira] [Created] (IGNITE-11293) NPE in TcpCommunicationSpi
Ivan Bessonov created IGNITE-11293:
--
Summary: NPE in TcpCommunicationSpi
Key: IGNITE-11293
URL: https://issues.apache.org/jira/browse/IGNITE-11293
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Sometimes this exception is happening in "stopAllGrids" method in tests:
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2787)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2717)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1648)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1757)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1303)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.lambda$null$1(GridDhtPartitionDemander.java:505)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6892)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
Reason is interruption thrown from TcpCommunicationSpi#reserveClient, SPI is
already in invalid state at this point so "log" and some other fields are nulls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765024#comment-16765024
]
Yakov Zhdanov commented on IGNITE-10935:
[~agoncharuk] good to merge
> "Invalid node order" error occurs while cycle cluster nodes restart
> ---
>
> Key: IGNITE-10935
> URL: https://issues.apache.org/jira/browse/IGNITE-10935
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> {code:java}
> Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError:
> Invalid node order: TcpDiscoveryNode
> [id=9a332aa3-3d60-469a-9ff5-3deee8918451, addrs=[0:0:0:0:0:0:0:1%lo,
> 127.0.0.1, 172.17.0.1, 172.25.1.40], sockAddrs=[/172.25.1.40:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /172.17.0.1:47501],
> discPort=47501, order=0, intOrder=16, lastExchangeTime=1547486771047,
> loc=false, ver=2.4.13#20190114-sha1:a7667ae6, isClient=false]
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
> at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
> at
> org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
> at
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Collaps{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11292) There is no way to disable WAL for cache in group
[
https://issues.apache.org/jira/browse/IGNITE-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sherstobitov updated IGNITE-11292:
-
Description:
Following code doesn't work if cache is in a cacheGroup:
{code:java}
ignite.cluster().disableWal(cacheName){code}
cacheName == cacheName:
{code:java}
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot change WAL
mode because not all cache names belonging to the group are provided
[group=cache_group_1, missingCaches=[cache_group_1_005, cache_group_3_063,
cache_group_1_003, cache_group_3_064, cache_group_1_004, cache_group_3_061,
cache_group_3_062, cache_group_1_001, cache_group_1_002]]
{code}
cacheName == groupName:
{code:java}
Caused by: class org.apache.ignite.IgniteCheckedException: Cache doesn't exist:
cache_group_1
{code}
was:
Following code doesn't work if cache is in cacheGroup:
{code}ignite.cluster().disableWal(cacheName){code}
cacheName == cacheName:
{code}
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot change WAL
mode because not all cache names belonging to the group are provided
[group=cache_group_1, missingCaches=[cache_group_1_005, cache_group_3_063,
cache_group_1_003, cache_group_3_064, cache_group_1_004, cache_group_3_061,
cache_group_3_062, cache_group_1_001, cache_group_1_002]]
{code}
cacheName == groupName:
{code}
Caused by: class org.apache.ignite.IgniteCheckedException: Cache doesn't exist:
cache_group_1
{code}
> There is no way to disable WAL for cache in group
> -
>
> Key: IGNITE-11292
> URL: https://issues.apache.org/jira/browse/IGNITE-11292
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Priority: Critical
>
> Following code doesn't work if cache is in a cacheGroup:
> {code:java}
> ignite.cluster().disableWal(cacheName){code}
> cacheName == cacheName:
> {code:java}
> Caused by: class org.apache.ignite.IgniteCheckedException: Cannot change WAL
> mode because not all cache names belonging to the group are provided
> [group=cache_group_1, missingCaches=[cache_group_1_005, cache_group_3_063,
> cache_group_1_003, cache_group_3_064, cache_group_1_004, cache_group_3_061,
> cache_group_3_062, cache_group_1_001, cache_group_1_002]]
> {code}
> cacheName == groupName:
> {code:java}
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache doesn't
> exist: cache_group_1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11292) There is no way to disable WAL for cache in group
[
https://issues.apache.org/jira/browse/IGNITE-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765037#comment-16765037
]
Dmitry Sherstobitov commented on IGNITE-11292:
--
[~avinogradov] Could you please look at this issue?
> There is no way to disable WAL for cache in group
> -
>
> Key: IGNITE-11292
> URL: https://issues.apache.org/jira/browse/IGNITE-11292
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Priority: Critical
>
> Following code doesn't work if cache is in cacheGroup:
> {code}ignite.cluster().disableWal(cacheName){code}
> cacheName == cacheName:
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Cannot change WAL
> mode because not all cache names belonging to the group are provided
> [group=cache_group_1, missingCaches=[cache_group_1_005, cache_group_3_063,
> cache_group_1_003, cache_group_3_064, cache_group_1_004, cache_group_3_061,
> cache_group_3_062, cache_group_1_001, cache_group_1_002]]
> {code}
> cacheName == groupName:
> {code}
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache doesn't
> exist: cache_group_1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765023#comment-16765023
]
Dmitriy Pavlov commented on IGNITE-11216:
-
[~ustas], yes, warning about reflective access in unavoidable.
See also https://docs.oracle.com/en/java/javase/11/tools/java.html
--illegal-access and it's value 'permit'
{quote}
This mode opens each package in each module in the run-time image to code in
all unnamed modules (such as code on the class path), if that package existed
in JDK 8. This enables both static access (for example, by compiled bytecode),
and deep reflective access through the platform's various reflection APIs. The
first reflective-access operation to any such package causes a warning to be
issued. However, no warnings are issued after the first occurrence. This single
warning describes how to enable further warnings. This mode is the default for
the current JDK but will change in a future release.
{quote}
> 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: 10m
> 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] [Updated] (IGNITE-11265) JVM Crash is often on TeamCity for Java 11 runs
[ https://issues.apache.org/jira/browse/IGNITE-11265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11265: Priority: Critical (was: Major) > JVM Crash is often on TeamCity for Java 11 runs > --- > > Key: IGNITE-11265 > URL: https://issues.apache.org/jira/browse/IGNITE-11265 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Priority: Critical > Attachments: hs_err_pid2431080.log.txt, hs_err_pid2458635.log.txt, > hs_err_pid2674225.log.txt, hs_err_pid3473289.log.txt > > > All crash dumps complain about the same method > org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock > Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log > Other recent examples > Queries 1 > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log > Client Nodes > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log > Zookeeper Discovery > https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765033#comment-16765033
]
Dmitriy Pavlov commented on IGNITE-11155:
-
New comment for failure looks like the following exception
!start-java11-2.png!
> 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: 10m
> 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] [Updated] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11155:
Attachment: start-java11-2.png
> 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: 10m
> 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] [Created] (IGNITE-11292) There is no way to disable WAL for cache in group
Dmitry Sherstobitov created IGNITE-11292:
Summary: There is no way to disable WAL for cache in group
Key: IGNITE-11292
URL: https://issues.apache.org/jira/browse/IGNITE-11292
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
Following code doesn't work if cache is in cacheGroup:
{code}ignite.cluster().disableWal(cacheName){code}
cacheName == cacheName:
{code}
Caused by: class org.apache.ignite.IgniteCheckedException: Cannot change WAL
mode because not all cache names belonging to the group are provided
[group=cache_group_1, missingCaches=[cache_group_1_005, cache_group_3_063,
cache_group_1_003, cache_group_3_064, cache_group_1_004, cache_group_3_061,
cache_group_3_062, cache_group_1_001, cache_group_1_002]]
{code}
cacheName == groupName:
{code}
Caused by: class org.apache.ignite.IgniteCheckedException: Cache doesn't exist:
cache_group_1
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11291) Assertion error in time of rebalance completion lead to to critical failure node
[
https://issues.apache.org/jira/browse/IGNITE-11291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-11291:
---
Issue Type: Bug (was: Improvement)
> Assertion error in time of rebalance completion lead to to critical failure
> node
>
>
> Key: IGNITE-11291
> URL: https://issues.apache.org/jira/browse/IGNITE-11291
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> {noformat}
> java.lang.AssertionError: Got removed exception on entry with dht local
> candidate: [IgniteTxEntry [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], cacheId=-313938805,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], cacheId=-313938805],
> val=[op=UPDATE,
> val=com.sbt.bm.ucp.common.dpl.model.party.hashcodes.DPartyHashCode_DPL_PROXY
> [idHash=1985166276, hash=1530579783, colocationKey=11859, sync Flag=null,
> hashUpdateTime=Sat Feb 09 20:16:55 MSK 2019, lastChangeDate=1549732615042,
> partition_DPL_id=4, ownerId=ucp, externalSystem=21,
> serializedHashCodesMap={"Address":["581a1367d4f50172c41168747c99105df1d3a4c6","24d3413bc5d3151dd784e088eaf4603e8e86c40b","fd7ce1449cd539a5976d358fb15060820c630f36"],"BirthDate":["a5cc7c1ac9821a6b19a455ae7eac55f4a4475bd7","415fe3810f8c4555a7188fe62275b34cdd1384cd","1311875998ef2aaccc5860ac6f991107ad4fa558"],"BirthPlace":["2fb5ea4cf7e9cfbdf77baae18f26804a10f51d57","76ddc5f2d959d27044c180957d9d0aed7369c0a2"],"Gender":["ad99678bb0e6de91d6a2ce620ba4fa98206aa9b9"],"IndividualIdentification":["c5b73f0087461fa4b980362344d38afddd1677b6","157952428fbe8c5b80da4db12c945cb4ad1f33f8","4d2257f62b1aa9cf290728d147776dd569b226a7"],"IndividualName":["256dba12a3b9d95dc1ada524d1a67cb590eb3ec2","2302eda39fb8f3751f3646542ad54ae717f5bc2c","9b8084de661530d5dc6ea140df793f4aa417a114"],"PartyToPartyGroup":["8d41984edf2e9ff916da0a74b884554cc2fceca9"],"PhoneNumber":["c89cbfb741ba5ea0fa13091a1cc7591c69374c0c","149081529b36fe29bc72bf88c66e51bdab3ae2d7","3c6bc9cc9e47ecd2f79b1506a22799ba69b95227","389830cd794fd6748f46ab7d8d878a2fec75cf63","9d5c3ecd5c951a16745cefd771b79c17bbc8c665","dfd8959391fd18e89505bfde31e0aa9a80513fec"],"Individual":["82dc325513d53990709bafbf1a334b602025ba17","544aab947d3a33787c7feffc93c4a4572e957dca","2728a40ce9759fa7110bc5d0d3c8b5c193210a2d"]},
> uid=null, isDeleted=false, isImmutable=false, checksum=null,
> id=3338011748811769508, externalClientId=75662144,
> colocationId=1216693183554769678]], prevVal=[op=NOOP, val=null],
> oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
> conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
> filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=false,
> entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=11859,
> val=3338011748811769508, hasValBytes=true], val=null, startVer=1551196730698,
> ver=GridCacheVersion [topVer=156972865, order=1546089814280, nodeOrder=65],
> hash=777160356, extras=GridCacheObsoleteEntryExtras
> [obsoleteVer=GridCacheVersion [topVer=2147483647, order=0, nodeOrder=0]],
> flags=2]GridDistributedCacheEntry [super=]GridDhtCacheEntry [rdrs=ReaderId[]
> [], part=11859, super=], prepared=1, locked=false, nodeId=null,
> locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=2,
> partUpdateCntr=0, serReadVer=GridCacheVersion[topVer=156972865,
> order=1546089814280, nodeOrder=65], xidVer=null]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.checkReadConflict(GridDhtTxPrepareFuture.java:1164)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:701)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:696)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
>
[jira] [Created] (IGNITE-11291) Assertion error in time of rebalance completion lead to to critical failure node
Vladislav Pyatkov created IGNITE-11291:
--
Summary: Assertion error in time of rebalance completion lead to
to critical failure node
Key: IGNITE-11291
URL: https://issues.apache.org/jira/browse/IGNITE-11291
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
{noformat}
java.lang.AssertionError: Got removed exception on entry with dht local
candidate: [IgniteTxEntry [key=KeyCacheObjectImpl [part=11859,
val=3338011748811769508, hasValBytes=true], cacheId=-313938805,
txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=11859, val=3338011748811769508,
hasValBytes=true], cacheId=-313938805], val=[op=UPDATE,
val=com.sbt.bm.ucp.common.dpl.model.party.hashcodes.DPartyHashCode_DPL_PROXY
[idHash=1985166276, hash=1530579783, colocationKey=11859, sync Flag=null,
hashUpdateTime=Sat Feb 09 20:16:55 MSK 2019, lastChangeDate=1549732615042,
partition_DPL_id=4, ownerId=ucp, externalSystem=21,
serializedHashCodesMap={"Address":["581a1367d4f50172c41168747c99105df1d3a4c6","24d3413bc5d3151dd784e088eaf4603e8e86c40b","fd7ce1449cd539a5976d358fb15060820c630f36"],"BirthDate":["a5cc7c1ac9821a6b19a455ae7eac55f4a4475bd7","415fe3810f8c4555a7188fe62275b34cdd1384cd","1311875998ef2aaccc5860ac6f991107ad4fa558"],"BirthPlace":["2fb5ea4cf7e9cfbdf77baae18f26804a10f51d57","76ddc5f2d959d27044c180957d9d0aed7369c0a2"],"Gender":["ad99678bb0e6de91d6a2ce620ba4fa98206aa9b9"],"IndividualIdentification":["c5b73f0087461fa4b980362344d38afddd1677b6","157952428fbe8c5b80da4db12c945cb4ad1f33f8","4d2257f62b1aa9cf290728d147776dd569b226a7"],"IndividualName":["256dba12a3b9d95dc1ada524d1a67cb590eb3ec2","2302eda39fb8f3751f3646542ad54ae717f5bc2c","9b8084de661530d5dc6ea140df793f4aa417a114"],"PartyToPartyGroup":["8d41984edf2e9ff916da0a74b884554cc2fceca9"],"PhoneNumber":["c89cbfb741ba5ea0fa13091a1cc7591c69374c0c","149081529b36fe29bc72bf88c66e51bdab3ae2d7","3c6bc9cc9e47ecd2f79b1506a22799ba69b95227","389830cd794fd6748f46ab7d8d878a2fec75cf63","9d5c3ecd5c951a16745cefd771b79c17bbc8c665","dfd8959391fd18e89505bfde31e0aa9a80513fec"],"Individual":["82dc325513d53990709bafbf1a334b602025ba17","544aab947d3a33787c7feffc93c4a4572e957dca","2728a40ce9759fa7110bc5d0d3c8b5c193210a2d"]},
uid=null, isDeleted=false, isImmutable=false, checksum=null,
id=3338011748811769508, externalClientId=75662144,
colocationId=1216693183554769678]], prevVal=[op=NOOP, val=null],
oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=false,
entry=GridCacheMapEntry [key=KeyCacheObjectImpl [part=11859,
val=3338011748811769508, hasValBytes=true], val=null, startVer=1551196730698,
ver=GridCacheVersion [topVer=156972865, order=1546089814280, nodeOrder=65],
hash=777160356, extras=GridCacheObsoleteEntryExtras
[obsoleteVer=GridCacheVersion [topVer=2147483647, order=0, nodeOrder=0]],
flags=2]GridDistributedCacheEntry [super=]GridDhtCacheEntry [rdrs=ReaderId[]
[], part=11859, super=], prepared=1, locked=false, nodeId=null,
locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=2,
partUpdateCntr=0, serReadVer=GridCacheVersion[topVer=156972865,
order=1546089814280, nodeOrder=65], xidVer=null]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.checkReadConflict(GridDhtTxPrepareFuture.java:1164)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1223)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:701)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:696)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:153)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:69)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
[jira] [Commented] (IGNITE-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765003#comment-16765003
]
Ilya Suntsov commented on IGNITE-11216:
---
I've reviewed scripts code and tested them on macOS (Majave, ver 10.14.2). LGTM
> 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: 10m
> 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-11216) Ignite.sh fails on Mac OS and Linux - Java 11
[
https://issues.apache.org/jira/browse/IGNITE-11216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764998#comment-16764998
]
Ilya Suntsov commented on IGNITE-11216:
---
[~dpavlov] I see the following warning in node log:
{noformat}
isuntsovs-MBP:gridgain-professional-2.8.0-SNAPSHOT isuntsov$ export
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/
isuntsovs-MBP:gridgain-professional-2.8.0-SNAPSHOT isuntsov$ bin/ignite.sh
examples/config/example-ignite.xml
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/Users/isuntsov/Downloads/gridgain-professional-2.8.0-SNAPSHOT/libs/ignite-core-2.8.0-SNAPSHOT.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
{noformat}
Is it ok?
> 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: 10m
> 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] [Updated] (IGNITE-11288) Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing SSLSocket.close() deadlock.
[
https://issues.apache.org/jira/browse/IGNITE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-11288:
Description:
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try
{ this.writeRecordInternal(var1, var2); }
finally \{ this.writeLock.unlock(); }
} else
{ SSLException var4 = new SSLException("SO_LINGER timeout, close_notify message
cannot be sent."); if (this.isLayered() && !this.autoClose) \\{
this.fatal((byte)-1, (Throwable)var4); }
else if (debug != null && Debug.isOn("ssl")) \{
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4); }
this.sess.invalidate();
}
} catch (InterruptedException var14) \{ var3 = true; }
if (var3) \{ Thread.currentThread().interrupt(); }
} else
{ this.writeLock.lock(); try \\{ this.writeRecordInternal(var1, var2); }
finally
{ this.writeLock.unlock(); }
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which wait
forever.
U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
We need to make it configurable for TcpCommSpi and TcpDisco. I suggest default
value 0.
Similar bug https://bugs.openjdk.java.net/browse/JDK-6668261.
was:
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try
{ this.writeRecordInternal(var1, var2); } finally \{ this.writeLock.unlock(); }
} else {
SSLException var4 = new SSLException("SO_LINGER timeout, close_notify message
cannot be sent.");
if (this.isLayered() && !this.autoClose) \{ this.fatal((byte)-1,
(Throwable)var4); } else if (debug != null && Debug.isOn("ssl")) \{
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4); }
this.sess.invalidate();
}
} catch (InterruptedException var14) \{ var3 = true; }
if (var3) \{ Thread.currentThread().interrupt(); }
} else {
this.writeLock.lock();
try \{ this.writeRecordInternal(var1, var2); }
finally
{ this.writeLock.unlock(); }
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which wait
forever.
U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
We need to make it configurable for TcpCommSpi and TcpDisco. I suggest default
value 0.
> Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing
> SSLSocket.close() deadlock.
> -
>
> Key: IGNITE-11288
> URL: https://issues.apache.org/jira/browse/IGNITE-11288
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to java8 SSLSocketImpl:
> if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
> boolean var3 = Thread.interrupted();
> try {
> if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
> try
> { this.writeRecordInternal(var1, var2); }
> finally \{ this.writeLock.unlock(); }
> } else
> { SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
> message cannot be sent."); if (this.isLayered() && !this.autoClose) \\{
> this.fatal((byte)-1, (Throwable)var4); }
> else if (debug != null && Debug.isOn("ssl")) \{
> System.out.println(Thread.currentThread().getName() + ", received Exception:
> " + var4); }
> this.sess.invalidate();
> }
> } catch (InterruptedException var14) \{ var3 = true; }
> if (var3) \{ Thread.currentThread().interrupt(); }
> } else
> { this.writeLock.lock(); try \\{ this.writeRecordInternal(var1, var2); }
> finally
> { this.writeLock.unlock(); }
> }
>
> In case of soLinger is not set we fallback to this.writeLock.lock(); which
> wait forever.
> U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
> We need to make it configurable for TcpCommSpi and TcpDisco. I suggest
> default value 0.
>
> Similar bug https://bugs.openjdk.java.net/browse/JDK-6668261.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-10908:
-
Labels: MakeTeamcityGreenAgain (was: )
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11290) History of server node IDs should be passed to new nodes with NodeAddedMessage
Sergey Chugunov created IGNITE-11290: Summary: History of server node IDs should be passed to new nodes with NodeAddedMessage Key: IGNITE-11290 URL: https://issues.apache.org/jira/browse/IGNITE-11290 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.8 As part of IGNITE-5569 (bounded) history of IDs of all server nodes existed in the cluster is introduced to prevent join requests with duplicate IDs if network glitch happens during node's join process. Initial implementation maintains the history locally on each node and isn't transferred to successfully joined nodes. It is needed to pass it (in NodeAdded messages) to new nodes to cover edge-case scenarios of coordinator failover. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764966#comment-16764966 ] Dmitriy Pavlov commented on IGNITE-6879: [~GreenNun] yes, removal of spring-data is mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist Feel free to monitor dev.list and remind Ignite developers to refactor this dependency when 3.0 comes. > Support Spring Data 2.0 > --- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > Fix For: 2.7 > > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764962#comment-16764962 ] Roman Meerson commented on IGNITE-6879: --- [~GreenNun] feel free to add this to documentation! As you may found from discussion above a decision was taken to leave 2 modules with different names because of lots of downloads of first module(spring-data-1.0). AFAIU in major version change modules should be switched or old one will be removed, but i'm not responsible for that. > Support Spring Data 2.0 > --- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > Fix For: 2.7 > > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0
[
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764951#comment-16764951
]
Stanislav Bausov commented on IGNITE-6879:
--
Hi [~homich]! Just found dependency:
{code:java}
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
{code}
May be it needs to add to official documentation?
[https://apacheignite-mix.readme.io/docs/spring-data#section-maven-configuration]
> Support Spring Data 2.0
> ---
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.7
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt
> with Spring 2.0. Trying to change the Spring dependency version to
> 2.0.0.release results in compile errors like below and requires regression in
> general.
> This improvement was created to either migrate from Spring 1.1 to 2.0 or
> create another set of modules ignite-spring-xxx-2 to have backward
> compatibility with Spring 1.1.
> [ERROR]
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
> name clash: deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository and
> deleteAll(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[
https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764946#comment-16764946
]
Ignite TC Bot commented on IGNITE-11257:
{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=3039057buildTypeId=IgniteTests24Java8_RunAll]
> 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: 10m
> 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-10693) MVCC TX: Random server restart tests became failed
[ https://issues.apache.org/jira/browse/IGNITE-10693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-10693: - Assignee: Igor Seliverstov > 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 > > > [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] [Updated] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-8571: -- Description: 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. was: 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: 1. org.apache.ignite.IgniteCluster *Add* 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. > 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] [Updated] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-8571: -- Description: 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: 1. org.apache.ignite.IgniteCluster *Add* 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. was: 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 3 new 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). 3. autoAdjustMaxTimeout - time which we would wait from the first dicovery event in the chain. If we achieved it than we would change BLAT right away (no matter were another node join/exit happened or not). We need to change API next way: 1. org.apache.ignite.IgniteCluster *Add* isBaselineAutoAdjustEnabled() setBaselineAutoAdjustEnabled(boolean enabled); setBaselineAutoAdjustTimeout(long timeoutInMs); setBaselineAutoAdjustMaxTimeout(long timeoutInMs); 2. org.apache.ignite.configuration.IgniteConfiguration *Add* IgniteConfiguration setBaselineAutoAdjustEnabled(boolean enabled); IgniteConfiguration setBaselineAutoAdjustTimeout(long timeoutInMs); IgniteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs); Also, we need to ensure that all nodes would have the same parameters. And we should be able to survive coordinator left during parameters changes. > 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: > 1. org.apache.ignite.IgniteCluster > *Add* > 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] [Comment Edited] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764938#comment-16764938
]
Dmitriy Pavlov edited comment on IGNITE-11155 at 2/11/19 1:10 PM:
--
[~ibessonov] thank you for review.
[~dmagda] thank you for your valuable proposal. I'll add demarcation of
parameters in the warning.
I suggest keeping the link in the warning because
- It shows users, that product is trying to help them to solve the issue, it
is a positive thing, even if the section will be renamed. At least page should
be available.
- It is easy to find in IntelliJ Idea/Teamcity logs because the link is
{color:#59afe1}+blue+{color} (near error text, which is
{color:#d04437}red{color}). It underlines that it is not just NPE or OOME, but
the problem which has a solution and advice about it. It may help the user to
continue to try Ignite examples instead of a too fast decision that product is
not operational.
was (Author: dpavlov):
[~ibessonov] thank you for review.
[~dmagda] thank you for your valuable proposal. I'll add demarcation of
parameters in the warning.
I suggest keeping the link in the warning because
- It shows users, that product is trying to help them to solve the issue, it
is a positive thing, even if the section will be renamed. At least page should
be available.
- It is easy to find in IntelliJ Idea/Teamcity logs because the link is
{color:#59afe1}+blue +{color}(which err. text, which is
{color:#d04437}red{color}). It underlines that it is not just NPE or OOME, but
the problem which has a solution and advice about it. It may help the user to
continue to try Ignite examples instead of a too fast decision that product is
not operational.
> 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.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Ignite examples or using Ignite Embedded mode (using direct
> Ignition.start() call from a user IDE), may fail with exceptions for JDKs
> newer than 8.
> It may confuse the user. Instead of just logging an exception it is better to
> output message with advice on how to fix it. E.g.
> {noformat}
> Please make sure --add-exports=java.base/sun.nio.ch=ALL-UNNAMED is enabled.
> See
> https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11
> for more info
> {noformat}
> Modern IDEs like IntelliJ will display the link as a clickable hyperlink and
> Ignite in embedded mode will show how to set up Application configuration
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764938#comment-16764938
]
Dmitriy Pavlov commented on IGNITE-11155:
-
[~ibessonov] thank you for review.
[~dmagda] thank you for your valuable proposal. I'll add demarcation of
parameters in the warning.
I suggest keeping the link in the warning because
- It shows users, that product is trying to help them to solve the issue, it
is a positive thing, even if the section will be renamed. At least page should
be available.
- It is easy to find in IntelliJ Idea/Teamcity logs because the link is
{color:#59afe1}+blue +{color}(which err. text, which is
{color:#d04437}red{color}). It underlines that it is not just NPE or OOME, but
the problem which has a solution and advice about it. It may help the user to
continue to try Ignite examples instead of a too fast decision that product is
not operational.
> 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.png
>
> Time Spent: 10m
> 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] [Updated] (IGNITE-11155) Add JVM options analysis to Ignition.start() or handle and comment exceptions
[
https://issues.apache.org/jira/browse/IGNITE-11155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11155:
Fix Version/s: 2.8
> 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.png
>
> Time Spent: 10m
> 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-11266) Platform .NET test failed with Java 11 warning
[
https://issues.apache.org/jira/browse/IGNITE-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764916#comment-16764916
]
Pavel Tupitsyn commented on IGNITE-11266:
-
[~dpavlov] ok, I'll investigate on .NET side
> Platform .NET test failed with Java 11 warning
> --
>
> Key: IGNITE-11266
> URL: https://issues.apache.org/jira/browse/IGNITE-11266
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Following warning is unavoidable, because Java always warns about illegal
> reflective access (at least for the first time). Probably we can change some
> settings to avoid "The active test run was aborted. Reason".
> https://ci.ignite.apache.org/viewLog.html?buildId=3027650
> {noformat}
> [17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
> reflective access operation has occurred
> [17:32:56][test] WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
> field java.nio.Buffer.address
> [17:32:56][test] WARNING: Please consider reporting this to the maintainers
> of org.apache.ignite.internal.util.GridUnsafe$2
> [17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [17:32:56][test] WARNING: All illegal access operations will be denied in a
> future release
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11266) Platform .NET test failed with Java 11 warning
[
https://issues.apache.org/jira/browse/IGNITE-11266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-11266:
---
Assignee: Pavel Tupitsyn
> Platform .NET test failed with Java 11 warning
> --
>
> Key: IGNITE-11266
> URL: https://issues.apache.org/jira/browse/IGNITE-11266
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Following warning is unavoidable, because Java always warns about illegal
> reflective access (at least for the first time). Probably we can change some
> settings to avoid "The active test run was aborted. Reason".
> https://ci.ignite.apache.org/viewLog.html?buildId=3027650
> {noformat}
> [17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
> reflective access operation has occurred
> [17:32:56][test] WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
> field java.nio.Buffer.address
> [17:32:56][test] WARNING: Please consider reporting this to the maintainers
> of org.apache.ignite.internal.util.GridUnsafe$2
> [17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [17:32:56][test] WARNING: All illegal access operations will be denied in a
> future release
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page
[
https://issues.apache.org/jira/browse/IGNITE-11289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11289:
Description:
There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
page which was already excluded from the tree. The problem reproduces with a
scan query execution with put/remove load in background.
Linked PR contains reproducer and some tricks allowing to reproduce the problem
more often (it is still possible to reproduce it without tricks but likelihood
is significantly lower). Problem becomes evident when problematic page is taken
from REUSE_BUCKET. But there could be other hidden problems which do no cause
any runtime errors but lead to data inconsistency.
was:
There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
page which was already excluded from the tree. The problem reproduces with a
scan query execution with put/remove load in background.
Linked PR contains reproducer and some tricks allowing to reproduce the problem
more often. Problem becomes evident when problematic page is taken from
REUSE_BUCKET. But there could be other hidden problems which do no cause any
runtime errors but lead to data inconsistency.
> BPlusTree.AbstractForwardCursor can use obsolete page
> -
>
> Key: IGNITE-11289
> URL: https://issues.apache.org/jira/browse/IGNITE-11289
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
> page which was already excluded from the tree. The problem reproduces with a
> scan query execution with put/remove load in background.
> Linked PR contains reproducer and some tricks allowing to reproduce the
> problem more often (it is still possible to reproduce it without tricks but
> likelihood is significantly lower). Problem becomes evident when problematic
> page is taken from REUSE_BUCKET. But there could be other hidden problems
> which do no cause any runtime errors but lead to data inconsistency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page
[
https://issues.apache.org/jira/browse/IGNITE-11289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11289:
Affects Version/s: 2.7
> BPlusTree.AbstractForwardCursor can use obsolete page
> -
>
> Key: IGNITE-11289
> URL: https://issues.apache.org/jira/browse/IGNITE-11289
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
> page which was already excluded from the tree. The problem reproduces with a
> scan query execution with put/remove load in background.
> Linked PR contains a reproducer and some tricks allowing to reproduce the
> problem more often (it is still possible to reproduce it without tricks but
> likelihood is significantly lower). The problem becomes evident when a
> problematic page is taken from REUSE_BUCKET. But there could be other hidden
> problems which do not cause any runtime errors but lead to data inconsistency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11253) When a node that is not part of the baseline topology joins the cluster, it may lead to a node failure.
[
https://issues.apache.org/jira/browse/IGNITE-11253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764906#comment-16764906
]
Andrey Gura commented on IGNITE-11253:
--
[~slava.koptilin] Could you please add at least {{InterruptedException}} to
{{X.hasCause}} method's parameters. Usually any worker stops via {{cancel}}
call that interrupt worker's runner.
> When a node that is not part of the baseline topology joins the cluster, it
> may lead to a node failure.
> ---
>
> Key: IGNITE-11253
> URL: https://issues.apache.org/jira/browse/IGNITE-11253
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * In case of eager TTL is configured, a starting node creates and starts
> {{cleanupWorker}} (see {{GridCacheTtlManager.start0()}})
> * {{GridCacheSharedTtlCleanupManager.CleanupWorker}}, in its turn, has to
> wait for {{discovery().localJoin()}} future that is completed by discovery
> thread.
> * On the other hand, the exchange thread stops cache contexts and,
> therefore, it stops the {{cleanupWorker}} as well.
>
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager.stopCleanupWorker(GridCacheSharedTtlCleanupManager.java:109)
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager.unregister(GridCacheSharedTtlCleanupManager.java:82)
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.onKernalStop0(GridCacheTtlManager.java:110)
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStop(GridCacheManagerAdapter.java:111)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1495)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStopCaches(GridCacheProcessor.java:1182)
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onBaselineChange(GridCacheProcessor.java:5637)
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:910)
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:792)
> {code}
> So, exchange thread may try to stop the {{cleanupWorker}} before the
> {{localJoin}} future is completed by discovery thread. Unfortunately,
> `cleanupWorker` incorrectly handles this situation, and this fact can lead to
> a node failure:
> {code:java}
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: Got
> interrupted while waiting for future to complete.]]
> class org.apache.ignite.IgniteException: Got interrupted while waiting for
> future to complete.
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2217)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:136)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.IgniteInterruptedCheckedException: Got interrupted
> while waiting for future to complete.
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:186)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.localJoin(GridDiscoveryManager.java:2214)
> ... 3 more
> {code}
> The obvious fix is changing the catch block
> {code:java}
> catch (Throwable t) {
> if (!(t instanceof IgniteInterruptedCheckedException))
> err = t;
> throw t;
> }
> {code}
> to the following:
> {code:java}
> catch (Throwable t) {
> if (!(X.hasCause(t, IgniteInterruptedCheckedException.class)))
> err = t;
> throw t;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764905#comment-16764905 ] Stanislav Bausov commented on IGNITE-6879: -- Hi [~homich]. What is about this issue? It doesn't fix in v2.7. > Support Spring Data 2.0 > --- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > Fix For: 2.7 > > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page
[
https://issues.apache.org/jira/browse/IGNITE-11289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11289:
Description:
There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
page which was already excluded from the tree. The problem reproduces with a
scan query execution with put/remove load in background.
Linked PR contains a reproducer and some tricks allowing to reproduce the
problem more often (it is still possible to reproduce it without tricks but
likelihood is significantly lower). The problem becomes evident when a
problematic page is taken from REUSE_BUCKET. But there could be other hidden
problems which do not cause any runtime errors but lead to data inconsistency.
was:
There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
page which was already excluded from the tree. The problem reproduces with a
scan query execution with put/remove load in background.
Linked PR contains reproducer and some tricks allowing to reproduce the problem
more often (it is still possible to reproduce it without tricks but likelihood
is significantly lower). Problem becomes evident when problematic page is taken
from REUSE_BUCKET. But there could be other hidden problems which do no cause
any runtime errors but lead to data inconsistency.
> BPlusTree.AbstractForwardCursor can use obsolete page
> -
>
> Key: IGNITE-11289
> URL: https://issues.apache.org/jira/browse/IGNITE-11289
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
> page which was already excluded from the tree. The problem reproduces with a
> scan query execution with put/remove load in background.
> Linked PR contains a reproducer and some tricks allowing to reproduce the
> problem more often (it is still possible to reproduce it without tricks but
> likelihood is significantly lower). The problem becomes evident when a
> problematic page is taken from REUSE_BUCKET. But there could be other hidden
> problems which do not cause any runtime errors but lead to data inconsistency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11289) BPlusTree.AbstractForwardCursor can use obsolete page
Ivan Pavlukhin created IGNITE-11289:
---
Summary: BPlusTree.AbstractForwardCursor can use obsolete page
Key: IGNITE-11289
URL: https://issues.apache.org/jira/browse/IGNITE-11289
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Ivan Pavlukhin
There is a possibility that {{AbstractForwardCursor.nextPageId}} refers to a
page which was already excluded from the tree. The problem reproduces with a
scan query execution with put/remove load in background.
Linked PR contains reproducer and some tricks allowing to reproduce the problem
more often. Problem becomes evident when problematic page is taken from
REUSE_BUCKET. But there could be other hidden problems which do no cause any
runtime errors but lead to data inconsistency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11288) Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing SSLSocket.close() deadlock.
[
https://issues.apache.org/jira/browse/IGNITE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-11288:
Description:
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try
{ this.writeRecordInternal(var1, var2); } finally \{ this.writeLock.unlock(); }
} else {
SSLException var4 = new SSLException("SO_LINGER timeout, close_notify message
cannot be sent.");
if (this.isLayered() && !this.autoClose) \{ this.fatal((byte)-1,
(Throwable)var4); } else if (debug != null && Debug.isOn("ssl")) \{
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4); }
this.sess.invalidate();
}
} catch (InterruptedException var14) \{ var3 = true; }
if (var3) \{ Thread.currentThread().interrupt(); }
} else {
this.writeLock.lock();
try \{ this.writeRecordInternal(var1, var2); }
finally
{ this.writeLock.unlock(); }
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which wait
forever.
U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
We need to make it configurable for TcpCommSpi and TcpDisco. I suggest default
value 0.
was:
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try {
this.writeRecordInternal(var1, var2);
} finally {
this.writeLock.unlock();
}
} else {
SSLException var4 = new SSLException("SO_LINGER timeout, close_notify message
cannot be sent.");
if (this.isLayered() && !this.autoClose) {
this.fatal((byte)-1, (Throwable)var4);
} else if (debug != null && Debug.isOn("ssl")) {
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4);
}
this.sess.invalidate();
}
} catch (InterruptedException var14) {
var3 = true;
}
if (var3) {
Thread.currentThread().interrupt();
}
} else {
this.writeLock.lock();
try {
this.writeRecordInternal(var1, var2);
} finally {
this.writeLock.unlock();
}
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which
might fail forever.
> Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing
> SSLSocket.close() deadlock.
> -
>
> Key: IGNITE-11288
> URL: https://issues.apache.org/jira/browse/IGNITE-11288
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Critical
>
> According to java8 SSLSocketImpl:
> if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
> boolean var3 = Thread.interrupted();
> try {
> if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
> try
> { this.writeRecordInternal(var1, var2); } finally \{ this.writeLock.unlock();
> }
> } else {
> SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
> message cannot be sent.");
> if (this.isLayered() && !this.autoClose) \{ this.fatal((byte)-1,
> (Throwable)var4); } else if (debug != null && Debug.isOn("ssl")) \{
> System.out.println(Thread.currentThread().getName() + ", received Exception:
> " + var4); }
>
> this.sess.invalidate();
> }
> } catch (InterruptedException var14) \{ var3 = true; }
>
> if (var3) \{ Thread.currentThread().interrupt(); }
> } else {
> this.writeLock.lock();
>
> try \{ this.writeRecordInternal(var1, var2); }
> finally
> { this.writeLock.unlock(); }
> }
>
> In case of soLinger is not set we fallback to this.writeLock.lock(); which
> wait forever.
> U.closeQuiet(socket) if SSL is on will hang if soLinger() is negative.
> We need to make it configurable for TcpCommSpi and TcpDisco. I suggest
> default value 0.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764884#comment-16764884
]
Taras Ledkov commented on IGNITE-11177:
---
[~pkouznet], the mock object for cluster node's metrics is OK with me.
I guess the test checks the SQL view logic and metrics source doesn't matter.
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11288) Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing SSLSocket.close() deadlock.
[
https://issues.apache.org/jira/browse/IGNITE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin updated IGNITE-11288:
Description:
According to java8 SSLSocketImpl:
if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
boolean var3 = Thread.interrupted();
try {
if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
try {
this.writeRecordInternal(var1, var2);
} finally {
this.writeLock.unlock();
}
} else {
SSLException var4 = new SSLException("SO_LINGER timeout, close_notify message
cannot be sent.");
if (this.isLayered() && !this.autoClose) {
this.fatal((byte)-1, (Throwable)var4);
} else if (debug != null && Debug.isOn("ssl")) {
System.out.println(Thread.currentThread().getName() + ", received Exception: "
+ var4);
}
this.sess.invalidate();
}
} catch (InterruptedException var14) {
var3 = true;
}
if (var3) {
Thread.currentThread().interrupt();
}
} else {
this.writeLock.lock();
try {
this.writeRecordInternal(var1, var2);
} finally {
this.writeLock.unlock();
}
}
In case of soLinger is not set we fallback to this.writeLock.lock(); which
might fail forever.
> Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing
> SSLSocket.close() deadlock.
> -
>
> Key: IGNITE-11288
> URL: https://issues.apache.org/jira/browse/IGNITE-11288
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Voronkin
>Priority: Critical
>
> According to java8 SSLSocketImpl:
> if (var1.isAlert((byte)0) && this.getSoLinger() >= 0) {
> boolean var3 = Thread.interrupted();
> try {
> if (this.writeLock.tryLock((long)this.getSoLinger(), TimeUnit.SECONDS)) {
> try {
> this.writeRecordInternal(var1, var2);
> } finally {
> this.writeLock.unlock();
> }
> } else {
> SSLException var4 = new SSLException("SO_LINGER timeout, close_notify
> message cannot be sent.");
> if (this.isLayered() && !this.autoClose) {
> this.fatal((byte)-1, (Throwable)var4);
> } else if (debug != null && Debug.isOn("ssl")) {
> System.out.println(Thread.currentThread().getName() + ", received Exception:
> " + var4);
> }
> this.sess.invalidate();
> }
> } catch (InterruptedException var14) {
> var3 = true;
> }
> if (var3) {
> Thread.currentThread().interrupt();
> }
> } else {
> this.writeLock.lock();
> try {
> this.writeRecordInternal(var1, var2);
> } finally {
> this.writeLock.unlock();
> }
> }
>
> In case of soLinger is not set we fallback to this.writeLock.lock(); which
> might fail forever.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11288) Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing SSLSocket.close() deadlock.
Pavel Voronkin created IGNITE-11288: --- Summary: Missing SO_LINGER in TcpDiscovery and TcpCommunicationSpi causing SSLSocket.close() deadlock. Key: IGNITE-11288 URL: https://issues.apache.org/jira/browse/IGNITE-11288 Project: Ignite Issue Type: Bug Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11286) Add console prompt for password in control.(sh|bat) script
[
https://issues.apache.org/jira/browse/IGNITE-11286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov resolved IGNITE-11286.
---
Resolution: Duplicate
> Add console prompt for password in control.(sh|bat) script
> --
>
> Key: IGNITE-11286
> URL: https://issues.apache.org/jira/browse/IGNITE-11286
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> For security reasons we are to add interactive alternative to {{--password}}.
> Other password-related options already have this alternative, see [1].
> [1] https://jira.apache.org/jira/browse/IGNITE-10257
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10748) Remove dead code in TcpCommunicationSpi for the tcp client creation flow
[
https://issues.apache.org/jira/browse/IGNITE-10748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764849#comment-16764849
]
Maxim Muzafarov commented on IGNITE-10748:
--
[~dpavlov]
I've resolved conflicts with the master branch and re-run all test.
Will you have time to take a look at this PR?
> Remove dead code in TcpCommunicationSpi for the tcp client creation flow
>
>
> Key: IGNITE-10748
> URL: https://issues.apache.org/jira/browse/IGNITE-10748
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, a batch of changes can be applied over {{TcpCommunicationSpi}}
> class implementation due to:
> # {{safeTcpHandshake(..)}}
> #* {{handshakeConnIdx}} - parameter is always not null
> #* {{recovery}} - parameter is always not null
> #* {{HandhakeMessage}} - is not used in current flow at all
> # {{HandshakeMessage2}}
> #* Message size must be defined in the message class as constant
> # {{createTcpClient(..)}}
> #* Instantiation of {{GridTcpNioCommunicationClient}} must be performed
> outside the while-loop
> # Code-style issues. Fix one-liner if statements.
> # Extract internal {{HandshakeException}}, {{HandshakeTimeoutException}} from
> class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10748) Remove dead code in TcpCommunicationSpi for the tcp client creation flow
[
https://issues.apache.org/jira/browse/IGNITE-10748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764846#comment-16764846
]
Ignite TC Bot commented on IGNITE-10748:
{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=3047083buildTypeId=IgniteTests24Java8_RunAll]
> Remove dead code in TcpCommunicationSpi for the tcp client creation flow
>
>
> Key: IGNITE-10748
> URL: https://issues.apache.org/jira/browse/IGNITE-10748
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, a batch of changes can be applied over {{TcpCommunicationSpi}}
> class implementation due to:
> # {{safeTcpHandshake(..)}}
> #* {{handshakeConnIdx}} - parameter is always not null
> #* {{recovery}} - parameter is always not null
> #* {{HandhakeMessage}} - is not used in current flow at all
> # {{HandshakeMessage2}}
> #* Message size must be defined in the message class as constant
> # {{createTcpClient(..)}}
> #* Instantiation of {{GridTcpNioCommunicationClient}} must be performed
> outside the while-loop
> # Code-style issues. Fix one-liner if statements.
> # Extract internal {{HandshakeException}}, {{HandshakeTimeoutException}} from
> class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reopened IGNITE-10908:
--
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764843#comment-16764843
]
Vyacheslav Koptilin commented on IGNITE-10908:
--
Hi [~DmitriyGovorukhin] ,
It seems that the problem is still there. The root cause of the NPE is that the
name of a service, which is returned by
{{GridServiceDeploymentCompoundFuture#servicesToRollback}}, is {{null}}.
{code:java}
// code placeholderjava.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
{code}
I've created a new PR in order to address this issue:
[https://github.com/apache/ignite/pull/6077] Please take a look at this.
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10908) GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky fail with NPE in Service Grid (legacy mode)
[
https://issues.apache.org/jira/browse/IGNITE-10908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764843#comment-16764843
]
Vyacheslav Koptilin edited comment on IGNITE-10908 at 2/11/19 10:34 AM:
Hi [~DmitriyGovorukhin] ,
It seems that the problem is still there. The root cause of the NPE is that the
name of a service, which is returned by
{{GridServiceDeploymentCompoundFuture#servicesToRollback}}, is {{null}}.
{code:java}
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
{code}
I've created a new PR in order to address this issue:
[https://github.com/apache/ignite/pull/6077] Please take a look at this.
was (Author: slava.koptilin):
Hi [~DmitriyGovorukhin] ,
It seems that the problem is still there. The root cause of the NPE is that the
name of a service, which is returned by
{{GridServiceDeploymentCompoundFuture#servicesToRollback}}, is {{null}}.
{code:java}
// code placeholderjava.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
{code}
I've created a new PR in order to address this issue:
[https://github.com/apache/ignite/pull/6077] Please take a look at this.
> GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange flaky
> fail with NPE in Service Grid (legacy mode)
> --
>
> Key: IGNITE-10908
> URL: https://issues.apache.org/jira/browse/IGNITE-10908
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> [TC
> link|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1053083353985663802=testDetails]
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:646)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:589)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployAllAsync(IgniteServicesImpl.java:254)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange(GridServiceProcessorBatchDeploySelfTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11258) JDBC Thin: update connection setup logic.
[ https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-11258: - Summary: JDBC Thin: update connection setup logic. (was: JDBC: update connection setup logic.) > 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 > > # 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-11257) JDBC Thin: update handshake protocol so that the node returns its UUID.
[ https://issues.apache.org/jira/browse/IGNITE-11257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-11257: - Summary: JDBC Thin: update handshake protocol so that the node returns its UUID. (was: JDBC: update handshake protocol so that the node returns its UUID.) > 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: 10m > 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-11287) JDBC Thin: best effort affinity
Alexander Lapin created IGNITE-11287: Summary: 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 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] [Created] (IGNITE-11286) Add console prompt for password in control.(sh|bat) script
Andrey Kuznetsov created IGNITE-11286:
-
Summary: Add console prompt for password in control.(sh|bat) script
Key: IGNITE-11286
URL: https://issues.apache.org/jira/browse/IGNITE-11286
Project: Ignite
Issue Type: Task
Affects Versions: 2.7
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
For security reasons we are to add interactive alternative to {{--password}}.
Other password-related options already have this alternative, see [1].
[1] https://jira.apache.org/jira/browse/IGNITE-10257
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764814#comment-16764814
]
Pavel Kuznetsov commented on IGNITE-11177:
--
[~tledkov-gridgain] Could you please review the test logic?
We need to mock metrics to return some value that is greater than 24 hours
(converted from milliseconds).
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11276) Cache (Restarts) 1 flaky tests NPE at GridDhtPartitionsExchangeFuture.topologyVersion
[ https://issues.apache.org/jira/browse/IGNITE-11276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11276: Ignite Flags: (was: Docs Required) > Cache (Restarts) 1 flaky tests NPE at > GridDhtPartitionsExchangeFuture.topologyVersion > - > > Key: IGNITE-11276 > URL: https://issues.apache.org/jira/browse/IGNITE-11276 > Project: Ignite > Issue Type: Bug >Reporter: Stepachev Maksim >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Sometimes the Cache (Restarts) 1 suit finish with fail. The reason is NPE > into at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.topologyVersion(GridDhtPartitionsExchangeFuture.java:515) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11276) Cache (Restarts) 1 flaky tests NPE at GridDhtPartitionsExchangeFuture.topologyVersion
[ https://issues.apache.org/jira/browse/IGNITE-11276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764811#comment-16764811 ] Dmitriy Govorukhin commented on IGNITE-11276: - [~mstepachev] LGTM, thanks for the contribution. Merged to master. > Cache (Restarts) 1 flaky tests NPE at > GridDhtPartitionsExchangeFuture.topologyVersion > - > > Key: IGNITE-11276 > URL: https://issues.apache.org/jira/browse/IGNITE-11276 > Project: Ignite > Issue Type: Bug >Reporter: Stepachev Maksim >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Sometimes the Cache (Restarts) 1 suit finish with fail. The reason is NPE > into at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.topologyVersion(GridDhtPartitionsExchangeFuture.java:515) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11177) IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
[
https://issues.apache.org/jira/browse/IGNITE-11177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764799#comment-16764799
]
Pavel Kuznetsov commented on IGNITE-11177:
--
pr link : https://github.com/apache/ignite/pull/6044
> IGNITE.NODE_METRICS view fails with "Cannot parse "TIME" constant" > 24h
>
>
> Key: IGNITE-11177
> URL: https://issues.apache.org/jira/browse/IGNITE-11177
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: metrics
> Fix For: 2.8
>
>
> This is because we are using TIME type for several additive measurements:
> {quote}SqlSystemViewNodeMetrics.class:
>
> valueTimeFromMillis(metrics.getTotalJobsExecutionTime()),
> valueTimeFromMillis(metrics.getTotalBusyTime()),
>
> valueTimeFromMillis(metrics.getTotalIdleTime()),{quote}
> which will be hundreds of hours on long-running cluster, but {{TIME}} type is
> limited to 24 hours and will fail to be converted otherwise, as in:
> {quote}0: jdbc:ignite:thin://localhost> SELECT CAST('40:52:26.548' AS TIME);
> Error: Failed to parse query. Невозможно преобразование строки "40:52:26.548"
> в тип "TIME"
> Cannot parse "TIME" constant "40:52:26.548"; SQL statement:
> SELECT CAST('40:52:26.548' AS TIME) [22007-197] (state=42000,code=1001){quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11285) Conflicting javadocs for PagesFillFactor
Alexey Kuznetsov created IGNITE-11285:
-
Summary: Conflicting javadocs for PagesFillFactor
Key: IGNITE-11285
URL: https://issues.apache.org/jira/browse/IGNITE-11285
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Dmitriy Govorukhin
org.apache.ignite.MemoryMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of space that is still free and can be filled in.
*
* @return The percentage of space that is still free and can be filled in.
*/
public float getPagesFillFactor();
{code}
org.apache.ignite.DataRegionMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of the used space.
*
* @return The percentage of the used space.
*/
public float getPagesFillFactor();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11285) Conflicting javadocs for PagesFillFactor
[
https://issues.apache.org/jira/browse/IGNITE-11285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11285:
--
Description:
org.apache.ignite.MemoryMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of space that is still free and can be filled in.
*
* @return The percentage of space that is still free and can be filled in.
*/
public float getPagesFillFactor();
{code}
org.apache.ignite.DataRegionMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of the used space.
*
* @return The percentage of the used space.
*/
public float getPagesFillFactor();
{code}
Also it will be useful to add a note about meaning of this metrics, like if
close to zero - bad state, close to one - good state.
was:
org.apache.ignite.MemoryMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of space that is still free and can be filled in.
*
* @return The percentage of space that is still free and can be filled in.
*/
public float getPagesFillFactor();
{code}
org.apache.ignite.DataRegionMetrics#getPagesFillFactor
{code}
/**
* Gets the percentage of the used space.
*
* @return The percentage of the used space.
*/
public float getPagesFillFactor();
{code}
> Conflicting javadocs for PagesFillFactor
>
>
> Key: IGNITE-11285
> URL: https://issues.apache.org/jira/browse/IGNITE-11285
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Dmitriy Govorukhin
>Priority: Major
>
> org.apache.ignite.MemoryMetrics#getPagesFillFactor
> {code}
> /**
> * Gets the percentage of space that is still free and can be filled in.
> *
> * @return The percentage of space that is still free and can be filled in.
> */
> public float getPagesFillFactor();
> {code}
>
> org.apache.ignite.DataRegionMetrics#getPagesFillFactor
> {code}
> /**
> * Gets the percentage of the used space.
> *
> * @return The percentage of the used space.
> */
> public float getPagesFillFactor();
> {code}
> Also it will be useful to add a note about meaning of this metrics, like if
> close to zero - bad state, close to one - good state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[ https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764776#comment-16764776 ] Dmitriy Govorukhin commented on IGNITE-10920: - [~kbolyandra] Thanks for the contribution, merged to master. > Optimize HistoryAffinityAssignment heap usage. > -- > > Key: IGNITE-10920 > URL: https://issues.apache.org/jira/browse/IGNITE-10920 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Konstantin Bolyandra >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > With large topology and large amount of caches/partitions many server > discovery events may quickly produce large affinity history, eating gigabytes > of heap. > Solution: implement some kind of a compression for affinity cache map. > On example, affinity history could be stored as delta to some previous > version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11284) Web console: Actualize grid configuration: query entity and Pojo store
Vasiliy Sisko created IGNITE-11284: -- Summary: Web console: Actualize grid configuration: query entity and Pojo store Key: IGNITE-11284 URL: https://issues.apache.org/jira/browse/IGNITE-11284 Project: Ignite Issue Type: Improvement Components: wizards Environment: Result for class: org.apache.ignite.cache.QueryEntity Missed fieldsPrecision notNullFields fieldsScale defaultFieldValues Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory Missed types Result for class: org.apache.ignite.cache.QueryIndex Missed inlineSize Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11284) Web console: Actualize grid configuration: query entity and Pojo store
[ https://issues.apache.org/jira/browse/IGNITE-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-11284: --- Environment: (was: Result for class: org.apache.ignite.cache.QueryEntity Missed fieldsPrecision notNullFields fieldsScale defaultFieldValues Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory Missed types Result for class: org.apache.ignite.cache.QueryIndex Missed inlineSize) > Web console: Actualize grid configuration: query entity and Pojo store > -- > > Key: IGNITE-11284 > URL: https://issues.apache.org/jira/browse/IGNITE-11284 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11284) Web console: Actualize grid configuration: query entity and Pojo store
[ https://issues.apache.org/jira/browse/IGNITE-11284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-11284: --- Description: Result for class: org.apache.ignite.cache.QueryEntity Missed fieldsPrecision notNullFields fieldsScale defaultFieldValues Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory Missed types Result for class: org.apache.ignite.cache.QueryIndex Missed inlineSize > Web console: Actualize grid configuration: query entity and Pojo store > -- > > Key: IGNITE-11284 > URL: https://issues.apache.org/jira/browse/IGNITE-11284 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Result for class: org.apache.ignite.cache.QueryEntity > Missed > fieldsPrecision > notNullFields > fieldsScale > defaultFieldValues > Result for class: org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory > Missed > types > Result for class: org.apache.ignite.cache.QueryIndex > Missed > inlineSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5569) TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a cluster DDoS
[ https://issues.apache.org/jira/browse/IGNITE-5569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reassigned IGNITE-5569: --- Assignee: Sergey Chugunov (was: Dmitry Karachentsev) > TCP Discovery SPI allows multiple NODE_JOINED / NODE_FAILED leading to a > cluster DDoS > - > > Key: IGNITE-5569 > URL: https://issues.apache.org/jira/browse/IGNITE-5569 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > A firewall configuration issue may effectively lead to a cluster DDoS. The > scheme is as follows: > 1) A node G joins the cluster, and a firewall rule forbids incoming > connection from cluster to this node > 2) Cluster successfully processes NodeAddedMesage and fires a discovery > NODE_JOINED event (not sure why?) > 4) The last node in the ring fails to connect to the newly joined node and > generates NODE_FAILED event > 5) Coordinator drops the connection, joining node attempts to connect again > The issues I see here: > 1) Neither coordinator nor joining node print out the reason why the joining > node failed / did not join. A slight hint (failed to send message to the next > node) is printed on the node with the largest order (the one that attempted > to close the ring), but the root cause (connection refused) is also not > printed > 2) The joining node attempts to connect to the cluster with the same node ID. > This violates an invariant we heavily rely on that once a node ID leaves a > cluster, this ID never comes back again > 3) Each discovery event leads to a partition exchange which blocks all cache > operations for a time interval equal at least to the full ring latency time. > If several nodes are started on a malicious host, this may lead to almost > full cluster degradation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764732#comment-16764732 ] Vasiliy Sisko commented on IGNITE-11283: Actualized configuration: RendezvousAffinityFunction - already used actual field *affinityBackupFilter* PersistentStoreConfiguration - Added missed fields *walAutoArchiveAfterInactivity* and *walMode* for Ignite 2.1. TransactionConfiguration - Added missed fields. Deprecated fields not used since Ignite 1.5 ConnectorConfiguration - already used actual field *sslFactory* > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11283) Web console: Actualize grid configuration. Check deprecated fields
[ https://issues.apache.org/jira/browse/IGNITE-11283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11283: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Web console: Actualize grid configuration. Check deprecated fields > -- > > Key: IGNITE-11283 > URL: https://issues.apache.org/jira/browse/IGNITE-11283 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > > Result for class: > org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction > Deprecated > backupFilter > Result for class: org.apache.ignite.configuration.PersistentStoreConfiguration > Deprecated > walBufferSize > writeThrottlingEnabled > checkpointWriteOrder > fileIOFactory > walMode > walAutoArchiveAfterInactivity > Result for class: org.apache.ignite.configuration.TransactionConfiguration > Missed > deadlockTimeout > useJtaSynchronization > txTimeoutOnPartitionMapExchange > Deprecated > txSerializableEnabled > txManagerLookupClassName > Result for class: org.apache.ignite.configuration.ConnectorConfiguration > Deprecated > sslContextFactory -- This message was sent by Atlassian JIRA (v7.6.3#76005)
