[jira] [Updated] (IGNITE-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10421:
Description:
Reproducers:
* {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
* {{IgniteDynamicCacheStartFailWithPersistenceTest}}
{noformat}
[2018-11-27
14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
class org.apache.ignite.IgniteCheckedException: Compound exception for
CountDownFuture.
at
org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
at
org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
at
org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
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)
Suppressed: java.lang.AssertionError: off=3000,
allocated=1000, pageId=00020002,
file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
... 3 more
Suppressed: java.lang.AssertionError: off=4000,
allocated=1000, pageId=00020003,
file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
... 3 more
Suppressed: java.lang.AssertionError: off=2000,
allocated=1000, pageId=00020001,
file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
... 3 more
{noformat}
was:
Reproducer: {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
{noformat}
[2018-11-27
14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
class org.apache.ignite.IgniteCheckedException: Compound exception for
CountDownFuture.
at
[jira] [Closed] (IGNITE-9809) Web Console: Minor Fixes
[ https://issues.apache.org/jira/browse/IGNITE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9809. > Web Console: Minor Fixes > > > Key: IGNITE-9809 > URL: https://issues.apache.org/jira/browse/IGNITE-9809 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > We have a bunch of minor fixes: > # Duration filter > # i18n constants > # Minor CSS tweaks > # Minor code fixes > # Add extra methods to E2E FormField component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9809) Web Console: Minor Fixes
[ https://issues.apache.org/jira/browse/IGNITE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9809. -- > Web Console: Minor Fixes > > > Key: IGNITE-9809 > URL: https://issues.apache.org/jira/browse/IGNITE-9809 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > We have a bunch of minor fixes: > # Duration filter > # i18n constants > # Minor CSS tweaks > # Minor code fixes > # Add extra methods to E2E FormField component. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-10421:
Summary: MVCC: Assertion in checkpointer thread. (was: MVCC: Assertion in
checkpointing thread after disabling WAL.)
> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Roman Kondakov
>Priority: Major
>
> Reproducer: {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
> {noformat}
> [2018-11-27
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
> 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)
> Suppressed: java.lang.AssertionError: off=3000,
> allocated=1000, pageId=00020002,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=4000,
> allocated=1000, pageId=00020003,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=2000,
> allocated=1000, pageId=00020001,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702810#comment-16702810
]
Pavel Tupitsyn commented on IGNITE-10451:
-
[~slukyanov] yes, I've come to the same conclusion. Thanks for the pointer,
I'll try different ctor.
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
> at
>
[jira] [Created] (IGNITE-10453) Web console: Implement possibility to configure disk page compression.
Vasiliy Sisko created IGNITE-10453: -- Summary: Web console: Implement possibility to configure disk page compression. Key: IGNITE-10453 URL: https://issues.apache.org/jira/browse/IGNITE-10453 Project: Ignite Issue Type: Task Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Implemented possibility to configure disk page compression that is implemented in IGNITE-10330 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6173) SQL: do not start caches on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-6173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702794#comment-16702794
]
Ignite TC Bot commented on IGNITE-6173:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2416819buildTypeId=IgniteTests24Java8_RunAll]
> SQL: do not start caches on client nodes
>
>
> Key: IGNITE-6173
> URL: https://issues.apache.org/jira/browse/IGNITE-6173
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
>
> When cache is started, this even is distributed through custom discovery
> message. Server nodes start the cache, client nodes do nothing until cache is
> requested explicitly. At the same time H2 database objects are created only
> when cache is really started.
> For this reason query parsing could lead to {{TABLE NOT FOUND}}, {{INDEX NOT
> FOUND}}, etc. errors. If such exception is observed, we force start of all
> known cache on a client and then retry. See
> {{GridCacheProcessor#createMissingQueryCaches}} method.
> First, client node cache start leads to another custom discovery message. So
> query performance may suffer. Second, this is not needed! We already have all
> necessary cache info in discovery.
> Let's try to find a way to use available discovery data and do not start
> cache on a client for SQL query execution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10452) Inconsistent state of caches if a node stops in the process of running transactions
Roman Guseinov created IGNITE-10452: --- Summary: Inconsistent state of caches if a node stops in the process of running transactions Key: IGNITE-10452 URL: https://issues.apache.org/jira/browse/IGNITE-10452 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Roman Guseinov Attachments: NonAcidTxReproducer.java It seems it happens if several caches are used in a transaction. And there are some caches with enabled CacheStore and other ones with disabled. If all caches have CacheStore (or no one has) then the issue doesn't occur. Reproducer is attached (tested on master branch). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702684#comment-16702684
]
Stanislav Lukyanov commented on IGNITE-10451:
-
I've done some research and it seems that the issue isn't with .Net but with
how JdkMarshaller is created.
FilePageStoreManager creates its own copy of JdkMarshaller with a no-arg
constructor, but for correct serialization in all contexts JdkMarshaller needs
to have nodeName set.
Using MarshallerUtils.jdkMarshaller(String) should help.
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this
[jira] [Commented] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[
https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702610#comment-16702610
]
Roman Shtykh commented on IGNITE-10017:
---
Ran {{IgniteCacheAtomicProtocolTest#testPutReaderUpdate1}} several times
locally. Looks like flaky. TC says so too.
Same for others. [~Jokser] Could you possibly recheck?
> Infinite loop with 3rd party persistency and no value for the key in the data
> store
> ---
>
> Key: IGNITE-10017
> URL: https://issues.apache.org/jira/browse/IGNITE-10017
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Critical
> Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java
>
>
> Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_
> fails to clear its local map.
>
> The problem occurs when _IgniteBiTuple_ is used as a key, but the value for
> the key is not available. The execution path goes through
> _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for
> instance if you have an affinityCall and execute get() from within.
>
> What happens is
> # On get operation, keys are stored in the local map of _GridCacheAdapter_.
> For this, _UserKeyCacheObjectImpl#prepareForCache_ creates
> _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is
> different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is
> used further as a key to retrieve the value from the map.
> # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map
> from keys for which values were not found. It uses _UserKeyCacheObjectImpl_
> to check the map, but can’t peek and remove even if the key is in the map
> (hashes won’t match). The key is left in the map.
> # The problem comes with the 2nd get:
> - we check if the key is not in the map and create a new one, then BOOM!
> loops while _putIfAbsent == null_ succeeds (but it won’t)
> All these data types are ok –
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10017) Infinite loop with 3rd party persistency and no value for the key in the data store
[
https://issues.apache.org/jira/browse/IGNITE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702554#comment-16702554
]
Ignite TC Bot commented on IGNITE-10017:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2417474]]
{color:#d04437}MVCC Cache{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2417427]]
* IgniteCacheMvccTestSuite:
CacheMvccTransactionsTest.testRebalanceWithRemovedValuesSimple - 0,0% fails in
last 100 master runs.
{color:#d04437}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2417410]]
* IgniteSpiTestSuite:
TcpDiscoverySslSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished -
0,0% fails in last 100 master runs.
* IgniteSpiTestSuite:
TcpDiscoverySelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished - 0,0%
fails in last 100 master runs.
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2417448]]
* IgniteCacheTestSuite5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 -
0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2417478buildTypeId=IgniteTests24Java8_RunAll]
> Infinite loop with 3rd party persistency and no value for the key in the data
> store
> ---
>
> Key: IGNITE-10017
> URL: https://issues.apache.org/jira/browse/IGNITE-10017
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Critical
> Attachments: IgniteGetBinaryKeyReadThroughSelfTest.java
>
>
> Basically, it happens because _GridCacheAdapter#clearReservationsIfNeeded_
> fails to clear its local map.
>
> The problem occurs when _IgniteBiTuple_ is used as a key, but the value for
> the key is not available. The execution path goes through
> _GridDhtCacheAdapter#getDhtAllAsync_ -> _GridCacheAdapter#getAllAsync0_, for
> instance if you have an affinityCall and execute get() from within.
>
> What happens is
> # On get operation, keys are stored in the local map of _GridCacheAdapter_.
> For this, _UserKeyCacheObjectImpl#prepareForCache_ creates
> _KeyCacheObjectImpl_ with an unmarshalled val (BinaryObject), which is
> different from that of _UserKeyCacheObjectImpl_ (val is BiTuple here) that is
> used further as a key to retrieve the value from the map.
> # _GridCacheAdapter#clearReservationsIfNeeded_ is called to clear the map
> from keys for which values were not found. It uses _UserKeyCacheObjectImpl_
> to check the map, but can’t peek and remove even if the key is in the map
> (hashes won’t match). The key is left in the map.
> # The problem comes with the 2nd get:
> - we check if the key is not in the map and create a new one, then BOOM!
> loops while _putIfAbsent == null_ succeeds (but it won’t)
> All these data types are ok –
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryUtils.java#L212-L239]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
Pavel Tupitsyn created IGNITE-10451:
---
Summary: .NET: Persistence does not work with custom affinity
function
Key: IGNITE-10451
URL: https://issues.apache.org/jira/browse/IGNITE-10451
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
To reproduce: assign custom affinity function in
{{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
As a result, node restart fails with the following exception:
{code}
Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
configuration loading from file
[file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> Apache.Ignite.Core.Common.JavaException : class
org.apache.ignite.IgniteException: An error occurred during cache configuration
loading from file
[file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
during cache configuration loading from file
[file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
... 1 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
deserialize object with given class loader:
sun.misc.Launcher$AppClassLoader@18b4aac2
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
... 15 more
Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
local must be set or this method should be accessed under
org.apache.ignite.thread.IgniteThread
at
org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.threadLocalContext(GridBinaryMarshaller.java:398)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.readExternal(BinaryObjectImpl.java:695)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2116)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2065)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1571)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
[jira] [Updated] (IGNITE-9893) add hibernate-5.3 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Feldstein updated IGNITE-9893: Summary: add hibernate-5.3 module (was: add hibernate-5.2 module) > add hibernate-5.3 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Assignee: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9893) add hibernate-5.3 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702344#comment-16702344 ] Scott Feldstein commented on IGNITE-9893: - updated the ticket to reflect hibernate 5.3 [~ilyak], do you want me to blow away 4.x and 5.1 hibernate integrations when I update the code? > add hibernate-5.3 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Assignee: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
[
https://issues.apache.org/jira/browse/IGNITE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702324#comment-16702324
]
Ignite TC Bot commented on IGNITE-10079:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2415093buildTypeId=IgniteTests24Java8_RunAll]
> FileWriteAheadLogManager may return invalid lastCompactedSegment
>
>
> Key: IGNITE-10079
> URL: https://issues.apache.org/jira/browse/IGNITE-10079
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: WalCompactionAfterRestartTest.java
>
>
> As of current {{master}} branch,
> {{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after
> some segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
[
https://issues.apache.org/jira/browse/IGNITE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702321#comment-16702321
]
Ignite TC Bot commented on IGNITE-10079:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Activate | Deactivate Cluster{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2417158]]
* IgniteStandByClusterSuite:
IgniteClusterActivateDeactivateTest.testDeactivateFailover1 - 0,0% fails in
last 100 master runs.
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2417158buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster]
> FileWriteAheadLogManager may return invalid lastCompactedSegment
>
>
> Key: IGNITE-10079
> URL: https://issues.apache.org/jira/browse/IGNITE-10079
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: WalCompactionAfterRestartTest.java
>
>
> As of current {{master}} branch,
> {{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after
> some segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702315#comment-16702315 ] Andrew Mashenkov commented on IGNITE-3303: -- [~dpavlov], Done, license & inspections & SPI tests looks fine. > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Fix For: 2.8 > > Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, > testFlinkIgniteSourceWithLargeBatch.log, win7.PNG > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10079) FileWriteAheadLogManager may return invalid lastCompactedSegment
[
https://issues.apache.org/jira/browse/IGNITE-10079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702286#comment-16702286
]
Ignite TC Bot commented on IGNITE-10079:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Activate | Deactivate Cluster{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2417158]]
* IgniteStandByClusterSuite:
IgniteClusterActivateDeactivateTest.testDeactivateFailover1 - 0,0% fails in
last 100 master runs.
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2415093buildTypeId=IgniteTests24Java8_RunAll]
> FileWriteAheadLogManager may return invalid lastCompactedSegment
>
>
> Key: IGNITE-10079
> URL: https://issues.apache.org/jira/browse/IGNITE-10079
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Attachments: WalCompactionAfterRestartTest.java
>
>
> As of current {{master}} branch,
> {{FileWriteAheadLogManager#lastCompactedSegment}} may report -1 even after
> some segments have been actually compressed. Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance
[
https://issues.apache.org/jira/browse/IGNITE-10172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702256#comment-16702256
]
Aleksey Plekhanov commented on IGNITE-10172:
[~agoncharuk] done.
> Enabling cache statistics on a large cluster with a large number of caches
> can affect performance
> -
>
> Key: IGNITE-10172
> URL: https://issues.apache.org/jira/browse/IGNITE-10172
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In current implementation cache metrics are collected on each node and sent
> across whole cluster with discovery message
> ({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
> ({{MetricsUpdateFrequency}}, 2 seconds by default).
> If there are a lot of caches and a lot of nodes in the cluster, metrics
> update message (which contain metrics for each cache on each node) can reach
> a critical size.
> Also frequently collecting all cache metrics have a negative performance
> impact.
> The only way now to disable cache metrics collecting and sending with
> discovery metrics update message is to disable statistics for each cache. But
> this also makes impossible to request some of cache metrics locally (for the
> current node only). Requesting a limited set of cache metrics on the current
> node doesn't have such performance impact as the frequent collecting of all
> cache metrics, but sometimes it's enough for diagnostic purposes.
> To solve this introduce new system property which will disable cache metrics
> sending with {{TcpDiscoveryMetricsUpdateMessage}} even if
> {{statisticsEnabled}} flag is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance
[
https://issues.apache.org/jira/browse/IGNITE-10172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702253#comment-16702253
]
Ignite TC Bot commented on IGNITE-10172:
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2334055buildTypeId=IgniteTests24Java8_RunAll]
> Enabling cache statistics on a large cluster with a large number of caches
> can affect performance
> -
>
> Key: IGNITE-10172
> URL: https://issues.apache.org/jira/browse/IGNITE-10172
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In current implementation cache metrics are collected on each node and sent
> across whole cluster with discovery message
> ({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
> ({{MetricsUpdateFrequency}}, 2 seconds by default).
> If there are a lot of caches and a lot of nodes in the cluster, metrics
> update message (which contain metrics for each cache on each node) can reach
> a critical size.
> Also frequently collecting all cache metrics have a negative performance
> impact.
> The only way now to disable cache metrics collecting and sending with
> discovery metrics update message is to disable statistics for each cache. But
> this also makes impossible to request some of cache metrics locally (for the
> current node only). Requesting a limited set of cache metrics on the current
> node doesn't have such performance impact as the frequent collecting of all
> cache metrics, but sometimes it's enough for diagnostic purposes.
> To solve this introduce new system property which will disable cache metrics
> sending with {{TcpDiscoveryMetricsUpdateMessage}} even if
> {{statisticsEnabled}} flag is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702234#comment-16702234
]
Ignite TC Bot commented on IGNITE-8640:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2415518buildTypeId=IgniteTests24Java8_RunAll]
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
>
[jira] [Assigned] (IGNITE-7611) Document logger configuration options
[ https://issues.apache.org/jira/browse/IGNITE-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-7611: --- Assignee: Artem Budnikov (was: Prachi Garg) > Document logger configuration options > - > > Key: IGNITE-7611 > URL: https://issues.apache.org/jira/browse/IGNITE-7611 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Stanislav Lukyanov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > Existing documentation on readme.io > (https://apacheignite.readme.io/docs/logging) gives details on how to enable > each of the supported logging frameworks, and some info on the default > configuration (e.g. IGNITE_QUIET). > The documentation should also cover some other features of Ignite logging, > such as recently added features of automatic reconfiguration of log4j 1.x and > 2.x (IGNITE-6946) and DEV_ONLY marker in logging messages (IGNITE-7284), as > well as other features like automatic metrics logging (MetricsLogFrequency) > and performance suggestions on start > (IGNITE_PERFORMANCE_SUGGESTIONS_DISABLED). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702080#comment-16702080
]
Oleg Ignatenko edited comment on IGNITE-10450 at 11/28/18 4:42 PM:
---
[~Mmuzaf] here is ticket we discussed today. *Update:* posted to dev list to
collect feedback on this: [Change code style inspections to use red mark for
those used at Teamcity build
checks|http://apache-ignite-developers.2346864.n4.nabble.com/Change-code-style-inspections-to-use-red-mark-for-those-used-at-Teamcity-build-checks-IGNITE-10450-tt38620.html]
was (Author: oignatenko):
[~Mmuzaf] here is ticket we discussed today. I also plan to discuss this at dev
list to collect feedback, will post there shortly.
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix these earlier and
> avoid cumbersome TC runs and failure reports analysis.
> Technically this could be achieved by editing inspections config file and
> increasing respective inspections level to {{ERROR}}. I briefly checked how
> it would work in a "sandbox" project on my machine and it looked quite
> convenient: violations of inspections used by TC were shown as red in Error
> Stripe while the rest remained yellow, easy to see. (It's probably not very
> important but for the sake of completeness a thing I noticed when testing is
> that having red inspections didn't block compilation and execution of the
> code.) Screen shot of how it worked in my experiment is attached:
> [^IDEA.inspections.TC-bot.png]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-3303) Apache Flink Integration - Flink source to run a continuous query against one or multiple caches
[ https://issues.apache.org/jira/browse/IGNITE-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702101#comment-16702101 ] Dmitriy Pavlov commented on IGNITE-3303: [~amashenkov] could you please pull the latest master? I think license & inspections are coming from an old state of master. > Apache Flink Integration - Flink source to run a continuous query against one > or multiple caches > > > Key: IGNITE-3303 > URL: https://issues.apache.org/jira/browse/IGNITE-3303 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Fix For: 2.8 > > Attachments: Screen Shot 2016-10-07 at 12.44.47 AM.png, > testFlinkIgniteSourceWithLargeBatch.log, win7.PNG > > > Apache Flink integration > +++ *Ignite as a bidirectional Connector* +++ > As a Flink source => run a continuous query against one or multiple > caches [4]. > Related discussion : > http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Flink-lt-gt-Apache-Ignite-integration-td8163.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10450:
Attachment: IDEA.inspections.TC-bot.png
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix these earlier and
> avoid cumbersome TC runs and failure reports analysis.
> Technically this could be achieved by editing inspections config file and
> increasing respective inspections level to {{ERROR}}. I briefly checked how
> it would work in a "sandbox" project on my machine and it looked quite
> convenient: violations of inspections used by TC were shown as red in Error
> Stripe while the rest remained yellow, easy to see. (It's probably not very
> important but for the sake of completeness a thing I noticed when testing is
> that having red inspections didn't block compilation and execution of the
> code.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702080#comment-16702080
]
Oleg Ignatenko commented on IGNITE-10450:
-
[~Mmuzaf] here is ticket we discussed today. I also plan to discuss this at dev
list to collect feedback, will post there shortly.
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix these earlier and
> avoid cumbersome TC runs and failure reports analysis.
> Technically this could be achieved by editing inspections config file and
> increasing respective inspections level to {{ERROR}}. I briefly checked how
> it would work in a "sandbox" project on my machine and it looked quite
> convenient: violations of inspections used by TC were shown as red in Error
> Stripe while the rest remained yellow, easy to see. (It's probably not very
> important but for the sake of completeness a thing I noticed when testing is
> that having red inspections didn't block compilation and execution of the
> code.) Screen shot of how it worked in my experiment is attached:
> [^IDEA.inspections.TC-bot.png]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9290) Make remove explicit locks async when node left.
[
https://issues.apache.org/jira/browse/IGNITE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702079#comment-16702079
]
Ignite TC Bot commented on IGNITE-9290:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2360376buildTypeId=IgniteTests24Java8_RunAll]
> Make remove explicit locks async when node left.
>
>
> Key: IGNITE-9290
> URL: https://issues.apache.org/jira/browse/IGNITE-9290
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: deadlock, iep-25
> Fix For: 2.8
>
>
> GridCacheMvccManager.removeExplicitNodeLocks() run synchronously in discovery
> and exchange threads. This introduce unnecessary delays in discovery and
> exchange process.
> Also, this may cause a deadlock on node stop if user transaction holds an
> entry lock and awaits some Ignite manager response (e.g. cache store or DR or
> CQ), as manager stops right after last exchange has finished so managers
> can't detect node is stopping.
>
> [1]
> [http://apache-ignite-developers.2346864.n4.nabble.com/Synchronous-tx-entries-unlocking-in-discovery-exchange-threads-td33827.html]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10450:
Description:
Some of [Ignite code
style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
inspections are verified at Teamcity per IGNITE-9983. (Currently TC inspections
are "SizeReplaceableByIsEmpty", "UnusedImport", "MissingOverrideAnnotation",
"MissortedModifiers", "RedundantSuppression".)
Per discussion of issue IGNITE-10399 it looks like there is a room for
improvement here. Specifically, the problem occurred because it was too
difficult to find a new deviation that made TC inspections check fail because
it was buried among multiple similar looking but non-critical deviations in a
particular piece of old code
([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
It would be more convenient if programmer could easier see subset of checks
that are used at Teamcity because this would allow to fix these earlier and
avoid cumbersome TC runs and failure reports analysis.
Technically this could be achieved by editing inspections config file and
increasing respective inspections level to {{ERROR}}. I briefly checked how it
would work in a "sandbox" project on my machine and it looked quite convenient:
violations of inspections used by TC were shown as red in Error Stripe while
the rest remained yellow, easy to see. (It's probably not very important but
for the sake of completeness a thing I noticed when testing is that having red
inspections didn't block compilation and execution of the code.) Screen shot of
how it worked in my experiment is attached: [^IDEA.inspections.TC-bot.png]
was:
Some of [Ignite code
style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
inspections are verified at Teamcity per IGNITE-9983. (Currently TC inspections
are "SizeReplaceableByIsEmpty", "UnusedImport", "MissingOverrideAnnotation",
"MissortedModifiers", "RedundantSuppression".)
Per discussion of issue IGNITE-10399 it looks like there is a room for
improvement here. Specifically, the problem occurred because it was too
difficult to find a new deviation that made TC inspections check fail because
it was buried among multiple similar looking but non-critical deviations in a
particular piece of old code
([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
It would be more convenient if programmer could easier see subset of checks
that are used at Teamcity because this would allow to fix these earlier and
avoid cumbersome TC runs and failure reports analysis.
Technically this could be achieved by editing inspections config file and
increasing respective inspections level to {{ERROR}}. I briefly checked how it
would work in a "sandbox" project on my machine and it looked quite convenient:
violations of inspections used by TC were shown as red in Error Stripe while
the rest remained yellow, easy to see. (It's probably not very important but
for the sake of completeness a thing I noticed when testing is that having red
inspections didn't block compilation and execution of the code.)
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix
[jira] [Updated] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10450:
Ignite Flags: (was: Docs Required)
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix these earlier and
> avoid cumbersome TC runs and failure reports analysis.
> Technically this could be achieved by editing inspections config file and
> increasing respective inspections level to {{ERROR}}. I briefly checked how
> it would work in a "sandbox" project on my machine and it looked quite
> convenient: violations of inspections used by TC were shown as red in Error
> Stripe while the rest remained yellow, easy to see. (It's probably not very
> important but for the sake of completeness a thing I noticed when testing is
> that having red inspections didn't block compilation and execution of the
> code.) Screen shot of how it worked in my experiment is attached:
> [^IDEA.inspections.TC-bot.png]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
[
https://issues.apache.org/jira/browse/IGNITE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10450:
Labels: MakeTeamcityGreenAgain (was: )
> In Ignite code style inspections increase level for those used at Teamcity
> build checks
> ---
>
> Key: IGNITE-10450
> URL: https://issues.apache.org/jira/browse/IGNITE-10450
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: IDEA.inspections.TC-bot.png
>
>
> Some of [Ignite code
> style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
> inspections are verified at Teamcity per IGNITE-9983. (Currently TC
> inspections are "SizeReplaceableByIsEmpty", "UnusedImport",
> "MissingOverrideAnnotation", "MissortedModifiers", "RedundantSuppression".)
> Per discussion of issue IGNITE-10399 it looks like there is a room for
> improvement here. Specifically, the problem occurred because it was too
> difficult to find a new deviation that made TC inspections check fail because
> it was buried among multiple similar looking but non-critical deviations in a
> particular piece of old code
> ([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
> It would be more convenient if programmer could easier see subset of checks
> that are used at Teamcity because this would allow to fix these earlier and
> avoid cumbersome TC runs and failure reports analysis.
> Technically this could be achieved by editing inspections config file and
> increasing respective inspections level to {{ERROR}}. I briefly checked how
> it would work in a "sandbox" project on my machine and it looked quite
> convenient: violations of inspections used by TC were shown as red in Error
> Stripe while the rest remained yellow, easy to see. (It's probably not very
> important but for the sake of completeness a thing I noticed when testing is
> that having red inspections didn't block compilation and execution of the
> code.) Screen shot of how it worked in my experiment is attached:
> [^IDEA.inspections.TC-bot.png]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702069#comment-16702069 ] Igor Sapego commented on IGNITE-8212: - [~Artem Budnikov], see my comment below: 1. I like how you give a reference to a javadoc for some operations, but why don't do that for all operations? 2. Maybe it makes sense to give reference for a Header field format in every description of this field? It can help, if person is not reading the whole page from the beginning and just want to find out a format of the one specific message. 3. Maybe it makes sense to mention in the beginning of the page that standard field types like "int", "byte" and others are described in "Data format" section. > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10450) In Ignite code style inspections increase level for those used at Teamcity build checks
Oleg Ignatenko created IGNITE-10450:
---
Summary: In Ignite code style inspections increase level for those
used at Teamcity build checks
Key: IGNITE-10450
URL: https://issues.apache.org/jira/browse/IGNITE-10450
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.6
Reporter: Oleg Ignatenko
Attachments: IDEA.inspections.TC-bot.png
Some of [Ignite code
style|https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines]
inspections are verified at Teamcity per IGNITE-9983. (Currently TC inspections
are "SizeReplaceableByIsEmpty", "UnusedImport", "MissingOverrideAnnotation",
"MissortedModifiers", "RedundantSuppression".)
Per discussion of issue IGNITE-10399 it looks like there is a room for
improvement here. Specifically, the problem occurred because it was too
difficult to find a new deviation that made TC inspections check fail because
it was buried among multiple similar looking but non-critical deviations in a
particular piece of old code
([PageMemoryImpl.java|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java]).
It would be more convenient if programmer could easier see subset of checks
that are used at Teamcity because this would allow to fix these earlier and
avoid cumbersome TC runs and failure reports analysis.
Technically this could be achieved by editing inspections config file and
increasing respective inspections level to {{ERROR}}. I briefly checked how it
would work in a "sandbox" project on my machine and it looked quite convenient:
violations of inspections used by TC were shown as red in Error Stripe while
the rest remained yellow, easy to see. (It's probably not very important but
for the sake of completeness a thing I noticed when testing is that having red
inspections didn't block compilation and execution of the code.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-8212: --- Assignee: Artem Budnikov (was: Igor Sapego) > Binary Client Protocol spec: Key-Value Queries clarifications > - > > Key: IGNITE-8212 > URL: https://issues.apache.org/jira/browse/IGNITE-8212 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > > https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations > - all operations - "Flag. Pass 0 for default, or 1 to keep the value in > binary form": > -- remove words about binary form and keep "Pass 0 for default" for all > operations where this flag has no meaning. > -- clarify about binary form in operations where it has a meaning. > - OP_CACHE_GET: clarify that null is returned if the provided key does not > exist in the cache. > - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided > key does not exist in the cache, and null is returned in this case. > - OP_CACHE_GET_AND_REPLACE: > -- "if and only if there is a value currently mapped for that key" - is > confusing. Is it possible that an existing key has no associated value? > Suggest to rephrase as "if and only if the key exists in the cache" > -- clarify that null is returned if the key does not exist in the cache. > - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not > exist in the cache. > - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new > entry is created, false if the specified key already exists in the cache. > - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of > whether put happened or not" - is confusing. Suggest to rewrite "the current > value associated with the key if it already exists in the cache, null if the > new entry is created". > - OP_CACHE_GET_SIZE: clarify Peek modes > - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX: > -- what is the difference between the corresponding operations? Only in > notifying / not notifying listeners and cache writers? Or there are other > differences not clarified by the spec? > -- (the operations could be combined in one set - with a flag required/not > required notifications) > -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no > OP_CACHE_CLEAR_IF_EQUALS. Is it intentional? > -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating > whether remove happened" in the response. But OP_CACHE_CLEAR_KEY does not > have such a flag in the response. Is it intentional? > -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of > the specified keys do not exist other entries are removed anyway. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10447) thin nodejs: can't execute example AuthTlsExample.js
[
https://issues.apache.org/jira/browse/IGNITE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Petroshenko reassigned IGNITE-10447:
--
Assignee: ekaterina.vergizova
> thin nodejs: can't execute example AuthTlsExample.js
>
>
> Key: IGNITE-10447
> URL: https://issues.apache.org/jira/browse/IGNITE-10447
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: ekaterina.vergizova
>Priority: Major
>
> Trying to run script from nodejs/examples/AuthTlsExample.js but connection
> failed
> using latest [CI
> build|https://ci.ignite.apache.org/viewLog.html?buildId=2410261=Releases_NightlyRelease_ObsoleteApacheIgniteNightlyReleaseAssembleBinaries=artifacts]
> Output:
> {code}
> $ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
> Client is stopped
> [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> ERROR: [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> {code}
> config.xml
> {code}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/keystore.jks"/>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/truststore.jks"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9289) Document CPP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702040#comment-16702040 ] Denis Magda commented on IGNITE-9289: - [~pgarg], please review the changes. > Document CPP thin client > > > Key: IGNITE-9289 > URL: https://issues.apache.org/jira/browse/IGNITE-9289 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Major > Labels: documentaion > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10449) ML: Fix inspection issues
[ https://issues.apache.org/jira/browse/IGNITE-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702021#comment-16702021 ] ASF GitHub Bot commented on IGNITE-10449: - GitHub user dmitrievanthony opened a pull request: https://github.com/apache/ignite/pull/5526 IGNITE-10449: Fix javadoc and typos. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10449 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5526.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5526 commit 42d44e930ecd178da7d29f901fbc879fed4437db Author: dmitrievanthony Date: 2018-11-28T15:30:18Z IGNITE-10449: Fix javadoc and typos. > ML: Fix inspection issues > - > > Key: IGNITE-10449 > URL: https://issues.apache.org/jira/browse/IGNITE-10449 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > Static inspections found several issues: missed javadoc, typos, etc. The goal > of this task is to fix them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16702012#comment-16702012
]
Pavel Kuznetsov commented on IGNITE-10329:
--
Fixed comments, updated results in the comment above.
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701824#comment-16701824
]
Pavel Kuznetsov edited comment on IGNITE-10329 at 11/28/18 3:25 PM:
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
Added index on 'salary' field. All benchmarks now are running in single thread.
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |206.95|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |
111.08|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |167.05|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|129.69|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |315.57|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|99.75|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
was (Author: pkouznet):
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
Added index on 'salary' field. All benchmarks now are running in single thread.
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10350) Document that now it's allowed to stop caches created via SQL/DDL via Java API
[ https://issues.apache.org/jira/browse/IGNITE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701992#comment-16701992 ] Eduard Shangareev commented on IGNITE-10350: If it was never documented then I would add a comment that via SQL you could destroy only caches which were created via SQL/DDL. I think, it should be in DDL documentation. > Document that now it's allowed to stop caches created via SQL/DDL via Java API > -- > > Key: IGNITE-10350 > URL: https://issues.apache.org/jira/browse/IGNITE-10350 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Eduard Shangareev >Priority: Major > > We need to update our documentation that behavior has changed. > https://issues.apache.org/jira/browse/IGNITE-10328 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10441) Fluent API refactoring.
[
https://issues.apache.org/jira/browse/IGNITE-10441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701983#comment-16701983
]
Aleksey Zinoviev commented on IGNITE-10441:
---
Let's discuss it on the dev-list
> Fluent API refactoring.
> ---
>
> Key: IGNITE-10441
> URL: https://issues.apache.org/jira/browse/IGNITE-10441
> Project: Ignite
> Issue Type: Improvement
> Components: ml
>Reporter: Artem Malykh
>Assignee: Artem Malykh
>Priority: Major
>
> In many classes we have fluent API ("with*" methods). We have following
> problem: these methods should return exactly instance of it's own class
> (otherwise we'll have problems with subclasses, more precisely, if with
> method is declared in class A and we have class B extending A, with method
> (if we do not override it) will return A). Currently we opted to override
> "with" methods in subclasses. There is one solution which is probably more
> elegant, but involves relatively complex generics construction which reduces
> readability:
>
> {code:java}
> class A> {
> Self withX(X x) {
> this.x = x;
>
> return (Self)this;
> }
> class B> extends A {
>// No need to override "withX" here
>Self withY(Y y) {
> this.y = y;
>
> return(Self)this;
>}
> }
> class C> extends B {
>// No need to override "withX" and "withY" methods here.
> }
> //... etc
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7215) Documentation bug: "Cross-cache Query" page is dead
[ https://issues.apache.org/jira/browse/IGNITE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701971#comment-16701971 ] Artem Budnikov commented on IGNITE-7215: This was fixed in 2.7 documentation. > Documentation bug: "Cross-cache Query" page is dead > --- > > Key: IGNITE-7215 > URL: https://issues.apache.org/jira/browse/IGNITE-7215 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Priority: Major > > Could not find "Cross-cache Queries" section in the latest Ignite 2.3 docs. > The only page that references "cross-cache queries" is [JDBC Client > Driver|https://apacheignite-sql.readme.io/docs#section-jdbc-client-driver] > and it points to a [dead > link|https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7215) Documentation bug: "Cross-cache Query" page is dead
[ https://issues.apache.org/jira/browse/IGNITE-7215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov resolved IGNITE-7215. Resolution: Fixed > Documentation bug: "Cross-cache Query" page is dead > --- > > Key: IGNITE-7215 > URL: https://issues.apache.org/jira/browse/IGNITE-7215 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Priority: Major > > Could not find "Cross-cache Queries" section in the latest Ignite 2.3 docs. > The only page that references "cross-cache queries" is [JDBC Client > Driver|https://apacheignite-sql.readme.io/docs#section-jdbc-client-driver] > and it points to a [dead > link|https://apacheignite-sql.readme.io/docs/cache-queries#cross-cache-queries] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10449) ML: Fix inspection issues
[ https://issues.apache.org/jira/browse/IGNITE-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Dmitriev updated IGNITE-10449: Ignite Flags: (was: Docs Required) > ML: Fix inspection issues > - > > Key: IGNITE-10449 > URL: https://issues.apache.org/jira/browse/IGNITE-10449 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > > Static inspections found several issues: missed javadoc, typos, etc. The goal > of this task is to fix them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10449) ML: Fix inspection issues
Anton Dmitriev created IGNITE-10449: --- Summary: ML: Fix inspection issues Key: IGNITE-10449 URL: https://issues.apache.org/jira/browse/IGNITE-10449 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Assignee: Anton Dmitriev Fix For: 2.8 Static inspections found several issues: missed javadoc, typos, etc. The goal of this task is to fix them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10350) Document that now it's allowed to stop caches created via SQL/DDL via Java API
[ https://issues.apache.org/jira/browse/IGNITE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701956#comment-16701956 ] Artem Budnikov commented on IGNITE-10350: - [~EdShangGG] I think this was never mentioned in the documentation. Do you know which page (if any) should be fixed? > Document that now it's allowed to stop caches created via SQL/DDL via Java API > -- > > Key: IGNITE-10350 > URL: https://issues.apache.org/jira/browse/IGNITE-10350 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Eduard Shangareev >Priority: Major > > We need to update our documentation that behavior has changed. > https://issues.apache.org/jira/browse/IGNITE-10328 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10447) thin nodejs: can't execute example AuthTlsExample.js
[
https://issues.apache.org/jira/browse/IGNITE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov updated IGNITE-10447:
---
Description:
Trying to run script from nodejs/examples/AuthTlsExample.js but connection
failed
using latest [CI
build|https://ci.ignite.apache.org/viewLog.html?buildId=2410261=Releases_NightlyRelease_ObsoleteApacheIgniteNightlyReleaseAssembleBinaries=artifacts]
Output:
{code}
$ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
Client is stopped
[localhost:10800] Connection failed: Error: Client network socket disconnected
before secure TLS connection was established
ERROR: [localhost:10800] Connection failed: Error: Client network socket
disconnected before secure TLS connection was established
{code}
config.xml
{code}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
was:
Trying to run script from nodejs/examples/AuthTlsExample.js but connection
failed
using latest nightly build from ci.ignite.apache.org
Output:
{code}
$ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
Client is stopped
[localhost:10800] Connection failed: Error: Client network socket disconnected
before secure TLS connection was established
ERROR: [localhost:10800] Connection failed: Error: Client network socket
disconnected before secure TLS connection was established
{code}
config.xml
{code}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
> thin nodejs: can't execute example AuthTlsExample.js
>
>
> Key: IGNITE-10447
> URL: https://issues.apache.org/jira/browse/IGNITE-10447
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run script from nodejs/examples/AuthTlsExample.js but connection
> failed
> using latest [CI
> build|https://ci.ignite.apache.org/viewLog.html?buildId=2410261=Releases_NightlyRelease_ObsoleteApacheIgniteNightlyReleaseAssembleBinaries=artifacts]
> Output:
> {code}
> $ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
> Client is stopped
> [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> ERROR: [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> {code}
> config.xml
> {code}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/keystore.jks"/>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/truststore.jks"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10447) thin nodejs: can't execute example AuthTlsExample.js
[
https://issues.apache.org/jira/browse/IGNITE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov updated IGNITE-10447:
---
Description:
Trying to run script from nodejs/examples/AuthTlsExample.js but connection
failed
using latest nightly build from ci.ignite.apache.org
Output:
{code}
$ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
Client is stopped
[localhost:10800] Connection failed: Error: Client network socket disconnected
before secure TLS connection was established
ERROR: [localhost:10800] Connection failed: Error: Client network socket
disconnected before secure TLS connection was established
{code}
config.xml
{code}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
was:
Trying to run script from nodejs/examples/AuthTlsExample.js but connection
failed
Output:
{code}
$ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
Client is stopped
[localhost:10800] Connection failed: Error: Client network socket disconnected
before secure TLS connection was established
ERROR: [localhost:10800] Connection failed: Error: Client network socket
disconnected before secure TLS connection was established
{code}
config.xml
{code}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
> thin nodejs: can't execute example AuthTlsExample.js
>
>
> Key: IGNITE-10447
> URL: https://issues.apache.org/jira/browse/IGNITE-10447
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run script from nodejs/examples/AuthTlsExample.js but connection
> failed
> using latest nightly build from ci.ignite.apache.org
> Output:
> {code}
> $ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
> Client is stopped
> [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> ERROR: [localhost:10800] Connection failed: Error: Client network socket
> disconnected before secure TLS connection was established
> {code}
> config.xml
> {code}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/keystore.jks"/>
>
> value="/ignite/modules/platforms/nodejs/examples/certs/truststore.jks"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9902) ScanQuery doesn't take lost partitions into account
[ https://issues.apache.org/jira/browse/IGNITE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701945#comment-16701945 ] Ivan Bessonov commented on IGNITE-9902: --- [~aplatonov] I see now why you implemented it this way, I was wrong in my previous comment. I have no issues with your code, please proceed with merge. Thank you! > ScanQuery doesn't take lost partitions into account > --- > > Key: IGNITE-9902 > URL: https://issues.apache.org/jira/browse/IGNITE-9902 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Alexey Platonov >Priority: Major > Time Spent: 8h > Remaining Estimate: 0h > > Same as IGNITE-9841, but about scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10448) MVCC: NPE on data page eviction.
Roman Kondakov created IGNITE-10448:
---
Summary: MVCC: NPE on data page eviction.
Key: IGNITE-10448
URL: https://issues.apache.org/jira/browse/IGNITE-10448
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
NPE occurred during page eviction process.
Reproducer: {{PageEvictionMultinodeMixedRegionsTest}}.
StackTrace:
{noformat}
javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 83e7f9a5761--093b-7d30--0005
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
at
org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.createCacheAndTestEvcition(PageEvictionMultinodeAbstractTest.java:101)
at
org.apache.ignite.internal.processors.cache.eviction.paged.PageEvictionMultinodeAbstractTest.testPageEviction(PageEvictionMultinodeAbstractTest.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:150)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2104)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2119)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
Transaction has been rolled back:
83e7f9a5761--093b-7d30--0005
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:923)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:921)
... 15 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
83e7f9a5761--093b-7d30--0005
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4299)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2520)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2501)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2478)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1105)
... 12 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
backup node: [localNodeId=0d817370-17fe-46f1-85ef-ea74b6f1,
remoteNodeId=ebab34f3-abbc-47e9-90fa-a48a8260]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.onResult(GridDhtTxAbstractEnlistFuture.java:1012)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistResponse(GridDhtTransactionalCacheAdapter.java:2340)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$1200(GridDhtTransactionalCacheAdapter.java:112)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$18.apply(GridDhtTransactionalCacheAdapter.java:255)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1059)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:383)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:100)
at
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701930#comment-16701930 ] ASF GitHub Bot commented on IGNITE-10291: - GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5525 IGNITE-10291 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10291-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5525.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5525 commit 10f5f9e328c081953462c498b58edad636e307fb Author: devozerov Date: 2018-11-28T09:28:40Z WIP. commit b35634bf58a3deb903f4ba9590c36eaa16d8fa4a Author: devozerov Date: 2018-11-28T09:51:32Z Minors. commit 898e82a27dd8a0ec7773eaa5b1e641c12c6c64cd Author: devozerov Date: 2018-11-28T12:27:55Z Implemented. commit 48601580e0a87bf2c5c759f736fce3543a5e105c Author: devozerov Date: 2018-11-28T12:29:37Z Minors. commit 8a2a8610a8439b8fedc3271153379d0d57058128 Author: devozerov Date: 2018-11-28T13:55:52Z It works. commit 7749dc7e34ffadfeee43d79e4098fdbe8085ddeb Author: devozerov Date: 2018-11-28T14:00:15Z Removed "exists". commit 24092fc6828e9246873814431dddfeb142fa1c8c Author: devozerov Date: 2018-11-28T14:04:01Z Minors. commit d0c2ee7a01bb202315d7c6ffc917b9ffb0d0bfc8 Author: devozerov Date: 2018-11-28T14:07:24Z Minors. > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701915#comment-16701915 ] Vladimir Ozerov edited comment on IGNITE-10291 at 11/28/18 2:09 PM: Implemented a fix. Reproducer works now. Outstanding tasks: # Skip index rebuild for empty caches # Convert reproducer into test was (Author: vozerov): Implemented a fix. Reproducer works now. Outstanding tasks: # Remove index storage "exists" method, as it is not needed anymore # Skip index rebuild for empty caches # Convert reproducer into test > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10447) thin nodejs: can't execute example AuthTlsExample.js
Stepan Pilschikov created IGNITE-10447:
--
Summary: thin nodejs: can't execute example AuthTlsExample.js
Key: IGNITE-10447
URL: https://issues.apache.org/jira/browse/IGNITE-10447
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.7
Reporter: Stepan Pilschikov
Trying to run script from nodejs/examples/AuthTlsExample.js but connection
failed
Output:
{code}
$ ignite/modules/platforms/nodejs/examples$ node AuthTlsExample.js
Client is stopped
[localhost:10800] Connection failed: Error: Client network socket disconnected
before secure TLS connection was established
ERROR: [localhost:10800] Connection failed: Error: Client network socket
disconnected before secure TLS connection was established
{code}
config.xml
{code}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10291: - Fix Version/s: 2.8 > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701915#comment-16701915 ] Vladimir Ozerov commented on IGNITE-10291: -- Implemented a fix. Reproducer works now. Outstanding tasks: # Remove index storage "exists" method, as it is not needed anymore # Skip index rebuild for empty caches # Convert reproducer into test > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10291: - Ignite Flags: (was: Docs Required) > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10291) Unable to find row by index created on partial baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10291: - Component/s: persistence > Unable to find row by index created on partial baseline topology > > > Key: IGNITE-10291 > URL: https://issues.apache.org/jira/browse/IGNITE-10291 > Project: Ignite > Issue Type: Bug > Components: cache, persistence, sql >Affects Versions: 2.4, 2.5, 2.6 >Reporter: Pavel Vinokurov >Assignee: Vladimir Ozerov >Priority: Critical > Fix For: 2.8 > > Attachments: Reproducer.java > > > Steps to reproduce: > 1. Start two nodes cluster with persistence. > 2. Create table > CREATE TABLE PERSON ( > FIRST_NAME VARCHAR, > LAST_NAME VARCHAR, > ADDRESS VARCHAR, > LANG VARCHAR, > BIRTH_DATE TIMESTAMP, > CONSTRAINT PK_PESON PRIMARY KEY (FIRST_NAME,LAST_NAME,ADDRESS,LANG) > ) WITH "key_type=PersonKeyType, CACHE_NAME=PersonCache, > value_type=PersonValueType, > AFFINITY_KEY=FIRST_NAME,template=PARTITIONED,backups=1" > Insert 1000 rows. > 3. Stop the second node. > 4. Create index > create index PERSON_FIRST_NAME_IDX on PERSON(FIRST_NAME) > 5. Start the second node > 6. Perform select query for each row: > select * from PERSON use index(PERSON_FIRST_NAME_IDX) > where > FIRST_NAME=? > and LAST_NAME=? > and ADDRESS=? > and LANG = ? > Result: The select doesn't return row in half of cases. > The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4841) Improve TEXT Query Documentation
[
https://issues.apache.org/jira/browse/IGNITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov reassigned IGNITE-4841:
--
Assignee: Andrew Mashenkov (was: Artem Budnikov)
> Improve TEXT Query Documentation
>
>
> Key: IGNITE-4841
> URL: https://issues.apache.org/jira/browse/IGNITE-4841
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.9
>Reporter: Daniel Siviter
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: full-text-search, javadoc
> Fix For: 2.7
>
>
> The documentation for Full TEXT Queries is thin at best:
> * What syntax does it use?
> * ...is it the full [Lucene Classic Query Parser
> Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
> * ...if so how does the syntax map to the {{@QueryTextField}} annotation?
> * How is Lucene analyser customisation performed?
> * What version is supported? (looks like 3.5.0 which is pretty old, latest is
> 6.4.1)
> * The
> [{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
> JavaDoc refers to
> [{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
> but strangely this doesn't even appear in the official JavaDoc. It is
> because it's an 'internal' class?
> It's mentioned multiple times as a feature, but doesn't look like much of
> Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9283) [ML] Add Discrete Cosine preprocessor
[ https://issues.apache.org/jira/browse/IGNITE-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701911#comment-16701911 ] Yury Babak commented on IGNITE-9283: Usefull paper: https://www.researchgate.net/publication/224112688_On_the_Use_of_Distributed_DCT_in_Speaker_Identification > [ML] Add Discrete Cosine preprocessor > - > > Key: IGNITE-9283 > URL: https://issues.apache.org/jira/browse/IGNITE-9283 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Ilya Lantukh >Priority: Major > > Add [https://en.wikipedia.org/wiki/Discrete_cosine_transform] > Please look at the MinMaxScaler or Normalization packages in preprocessing > package. > Add classes if required > 1) Preprocessor > 2) Trainer > 3) custom PartitionData if shuffling is a step of algorithm > > Requirements for successful PR: > # PartitionedDataset usage > # Trainer-Model paradigm support > # Tests for Model and for Trainer (and other stuff) > # Example of usage with small, but famous dataset like IRIS, Titanic or > House Prices > # Javadocs/codestyle according guidelines > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10130) Add option for disable triggering cache interceptor in case of conflicts.
[ https://issues.apache.org/jira/browse/IGNITE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701902#comment-16701902 ] Sergey Antonov commented on IGNITE-10130: - Error in Inspections isn't related with my changes. [~amashenkov] I applied your comments. Could you review my code again? > Add option for disable triggering cache interceptor in case of conflicts. > - > > Key: IGNITE-10130 > URL: https://issues.apache.org/jira/browse/IGNITE-10130 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > > It's needed for our proprietary plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10130) Add option for disable triggering cache interceptor in case of conflicts.
[
https://issues.apache.org/jira/browse/IGNITE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701901#comment-16701901
]
Ignite TC Bot commented on IGNITE-10130:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2415308]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2408273buildTypeId=IgniteTests24Java8_RunAll]
> Add option for disable triggering cache interceptor in case of conflicts.
> -
>
> Key: IGNITE-10130
> URL: https://issues.apache.org/jira/browse/IGNITE-10130
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> It's needed for our proprietary plugin.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10446) control.sh --cache idle_verify fail with NPE when node left grid
[ https://issues.apache.org/jira/browse/IGNITE-10446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ARomantsov updated IGNITE-10446: Description: Command [IDLE_VERIFY -host=***] started at [2018-11-28 15:54:23]... Error code: 13000. java.lang.NullPointerException. Command [IDLE_VERIFY] failed with error: 13000 - command failed. > control.sh --cache idle_verify fail with NPE when node left grid > > > Key: IGNITE-10446 > URL: https://issues.apache.org/jira/browse/IGNITE-10446 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: ARomantsov >Priority: Critical > Fix For: 2.8 > > > > Command [IDLE_VERIFY -host=***] started at [2018-11-28 15:54:23]... > Error code: 13000. java.lang.NullPointerException. > Command [IDLE_VERIFY] failed with error: 13000 - command failed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10446) control.sh --cache idle_verify fail with NPE when node left grid
ARomantsov created IGNITE-10446: --- Summary: control.sh --cache idle_verify fail with NPE when node left grid Key: IGNITE-10446 URL: https://issues.apache.org/jira/browse/IGNITE-10446 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: ARomantsov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-4841) Improve TEXT Query Documentation
[
https://issues.apache.org/jira/browse/IGNITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov updated IGNITE-4841:
---
Labels: full-text-search javadoc (was: full-text-search)
> Improve TEXT Query Documentation
>
>
> Key: IGNITE-4841
> URL: https://issues.apache.org/jira/browse/IGNITE-4841
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.9
>Reporter: Daniel Siviter
>Assignee: Artem Budnikov
>Priority: Major
> Labels: full-text-search, javadoc
> Fix For: 2.7
>
>
> The documentation for Full TEXT Queries is thin at best:
> * What syntax does it use?
> * ...is it the full [Lucene Classic Query Parser
> Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
> * ...if so how does the syntax map to the {{@QueryTextField}} annotation?
> * How is Lucene analyser customisation performed?
> * What version is supported? (looks like 3.5.0 which is pretty old, latest is
> 6.4.1)
> * The
> [{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
> JavaDoc refers to
> [{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
> but strangely this doesn't even appear in the official JavaDoc. It is
> because it's an 'internal' class?
> It's mentioned multiple times as a feature, but doesn't look like much of
> Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10445) Move Tx state to offheap.
Andrew Mashenkov created IGNITE-10445: - Summary: Move Tx state to offheap. Key: IGNITE-10445 URL: https://issues.apache.org/jira/browse/IGNITE-10445 Project: Ignite Issue Type: Improvement Components: cache Reporter: Andrew Mashenkov For now TxManager track tx state in on-heap bounded map structure. Map size can be changed with system prop-ty IGNITE_MAX_COMPLETED_TX_COUNT. Let's move tx structures to offheap like it is done for Mvcc transaction (TxLog). Also seems, we can use tx writeVersion as a commitVersion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10444) MVCC: CacheMvccTxFastFinishTest fails.
[ https://issues.apache.org/jira/browse/IGNITE-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10444: -- Ignite Flags: (was: Docs Required) > MVCC: CacheMvccTxFastFinishTest fails. > -- > > Key: IGNITE-10444 > URL: https://issues.apache.org/jira/browse/IGNITE-10444 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > > Seems, read-only transaction doesn't creates prepare\finish future as classic > tx do. > Let's check correct invariants in mvcc version of CacheTxFastFinishTest test. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701857#comment-16701857
]
Pavel Kuznetsov commented on IGNITE-10329:
--
Got comments:
1) Fix sql query with join : join condition and add index on orgId
2) Run on dedicated hosts : one host for driver and one for db.
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10297) Investigate possibility of restricting API of Upstream transformer
[ https://issues.apache.org/jira/browse/IGNITE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701848#comment-16701848 ] Artem Malykh commented on IGNITE-10297: --- [~dmitrievanthony] This is already done in IGNITE-10272 > Investigate possibility of restricting API of Upstream transformer > -- > > Key: IGNITE-10297 > URL: https://issues.apache.org/jira/browse/IGNITE-10297 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Artem Malykh >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > > Signature of 'transform' method of UpstreamTransformer is > Stream -> Stream. For now it is used only for > bagging and for that purpose, UpstreamEntry -> Stream would > suffice (just use 'flatMap' on upstream), maybe we should change signature to > this form. From other hand, we'll cut some possibilities like limiting of > upstream. This question needs investigation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10444) MVCC: CacheMvccTxFastFinishTest fails.
[ https://issues.apache.org/jira/browse/IGNITE-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10444: -- Issue Type: Test (was: Bug) > MVCC: CacheMvccTxFastFinishTest fails. > -- > > Key: IGNITE-10444 > URL: https://issues.apache.org/jira/browse/IGNITE-10444 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > > Seems, read-only transaction doesn't creates prepare\finish future as classic > tx do. > Let's check correct invariants in mvcc version of CacheTxFastFinishTest test. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10444) MVCC: CacheMvccTxFastFinishTest fails.
Andrew Mashenkov created IGNITE-10444: - Summary: MVCC: CacheMvccTxFastFinishTest fails. Key: IGNITE-10444 URL: https://issues.apache.org/jira/browse/IGNITE-10444 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Andrew Mashenkov Seems, read-only transaction doesn't creates prepare\finish future as classic tx do. Let's check correct invariants in mvcc version of CacheTxFastFinishTest test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4841) Improve TEXT Query Documentation
[
https://issues.apache.org/jira/browse/IGNITE-4841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Budnikov reassigned IGNITE-4841:
--
Assignee: Artem Budnikov
> Improve TEXT Query Documentation
>
>
> Key: IGNITE-4841
> URL: https://issues.apache.org/jira/browse/IGNITE-4841
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 1.9
>Reporter: Daniel Siviter
>Assignee: Artem Budnikov
>Priority: Major
> Labels: full-text-search
> Fix For: 2.7
>
>
> The documentation for Full TEXT Queries is thin at best:
> * What syntax does it use?
> * ...is it the full [Lucene Classic Query Parser
> Syntax|https://lucene.apache.org/core/6_3_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html]?
> * ...if so how does the syntax map to the {{@QueryTextField}} annotation?
> * How is Lucene analyser customisation performed?
> * What version is supported? (looks like 3.5.0 which is pretty old, latest is
> 6.4.1)
> * The
> [{{@QueryTextField}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/annotations/QueryTextField.html]
> JavaDoc refers to
> [{{CacheQuery}}|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/internal/processors/cache/query/CacheQuery.html]
> but strangely this doesn't even appear in the official JavaDoc. It is
> because it's an 'internal' class?
> It's mentioned multiple times as a feature, but doesn't look like much of
> Lucene can actually be utilised so clarifications would help greatly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10427) GridClusterStateProcessor#changeGlobalState0() should wrap future before sending ChangeGlobalStateMessage
[
https://issues.apache.org/jira/browse/IGNITE-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701845#comment-16701845
]
Sergey Antonov commented on IGNITE-10427:
-
Errors in {{[Inspections] Core}} not relate with my changes.
> GridClusterStateProcessor#changeGlobalState0() should wrap future before
> sending ChangeGlobalStateMessage
> -
>
> Key: IGNITE-10427
> URL: https://issues.apache.org/jira/browse/IGNITE-10427
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10427) GridClusterStateProcessor#changeGlobalState0() should wrap future before sending ChangeGlobalStateMessage
[
https://issues.apache.org/jira/browse/IGNITE-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701844#comment-16701844
]
Ignite TC Bot commented on IGNITE-10427:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Inspections] Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2412646]]
{panel}
[TeamCity Run All
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2409198buildTypeId=IgniteTests24Java8_RunAll]
> GridClusterStateProcessor#changeGlobalState0() should wrap future before
> sending ChangeGlobalStateMessage
> -
>
> Key: IGNITE-10427
> URL: https://issues.apache.org/jira/browse/IGNITE-10427
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10080) IgniteCacheTestSuite6 (Cache 6) contains some long-running tests that should be optimized.
[
https://issues.apache.org/jira/browse/IGNITE-10080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701843#comment-16701843
]
ASF GitHub Bot commented on IGNITE-10080:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5243
> IgniteCacheTestSuite6 (Cache 6) contains some long-running tests that should
> be optimized.
> --
>
> Key: IGNITE-10080
> URL: https://issues.apache.org/jira/browse/IGNITE-10080
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> We found that these tests take too long to complete and need to be optimized:
> {noformat}
> TxOptimisticPrepareOnUnstableTopologyTest.testPrepareOnUnstableTopology
> IgniteOptimisticTxSuspendResumeMultiServerTest.testSuspendTxAndResumeAfterTopologyChange
> TxRollbackAsyncTest.testSynchronousRollback
> TxRollbackAsyncNearCacheTest.testSynchronousRollback
> CacheExchangeMergeTest.testConcurrentStartServersAndClients
> CacheExchangeMergeTest.testConcurrentStartServers
> {noformat}
> *update*
> {{TxRollbackAsyncTest.testSynchronousRollback}} was optimized in IGNITE-10107/
> {{testSuspendTxAndResumeAfterTopologyChange}} was refactored, reduced number
> of server restarts (from 72 to 3).
> {{testConcurrentStartServers}} reduced number of iterations using scale
> factor utility.
> {{TxOptimisticPrepareOnUnstableTopologyTest}} reduced server startup delay.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance
[
https://issues.apache.org/jira/browse/IGNITE-10172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701841#comment-16701841
]
Alexey Goncharuk commented on IGNITE-10172:
---
[~alex_pl], can you please pull the latest master and re-run inspections
(should be fixed in master now) to get green visa? I will merge the changes
then.
> Enabling cache statistics on a large cluster with a large number of caches
> can affect performance
> -
>
> Key: IGNITE-10172
> URL: https://issues.apache.org/jira/browse/IGNITE-10172
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
>
> In current implementation cache metrics are collected on each node and sent
> across whole cluster with discovery message
> ({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
> ({{MetricsUpdateFrequency}}, 2 seconds by default).
> If there are a lot of caches and a lot of nodes in the cluster, metrics
> update message (which contain metrics for each cache on each node) can reach
> a critical size.
> Also frequently collecting all cache metrics have a negative performance
> impact.
> The only way now to disable cache metrics collecting and sending with
> discovery metrics update message is to disable statistics for each cache. But
> this also makes impossible to request some of cache metrics locally (for the
> current node only). Requesting a limited set of cache metrics on the current
> node doesn't have such performance impact as the frequent collecting of all
> cache metrics, but sometimes it's enough for diagnostic purposes.
> To solve this introduce new system property which will disable cache metrics
> sending with {{TcpDiscoveryMetricsUpdateMessage}} even if
> {{statisticsEnabled}} flag is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701824#comment-16701824
]
Pavel Kuznetsov edited comment on IGNITE-10329 at 11/28/18 12:45 PM:
-
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
Added index on 'salary' field. All benchmarks now are running in single thread.
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
was (Author: pkouznet):
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
Added index on 'salary' field.
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701824#comment-16701824
]
Pavel Kuznetsov edited comment on IGNITE-10329 at 11/28/18 12:41 PM:
-
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
was (Author: pkouznet):
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10443) Fix flaky GridCommandHandlerTest.testKillHangingLocalTransactions
Alexei Scherbakov created IGNITE-10443: -- Summary: Fix flaky GridCommandHandlerTest.testKillHangingLocalTransactions Key: IGNITE-10443 URL: https://issues.apache.org/jira/browse/IGNITE-10443 Project: Ignite Issue Type: Test Reporter: Alexei Scherbakov Assignee: Alexei Scherbakov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701824#comment-16701824
]
Pavel Kuznetsov edited comment on IGNITE-10329 at 11/28/18 12:43 PM:
-
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
Added index on 'salary' field.
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
was (Author: pkouznet):
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
*MySQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-mysql |1,182.26|
|SelectWithJoinBenchmark|select-join-jdbc-mysql |189.96|
|SelectByPkBenchmark|select-pk-jdbc-mysql |1,198.67|
*PostgreSQL*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-postgresql |3,128.08|
|SelectWithJoinBenchmark|select-join-jdbc-postgresql|109.55|
|SelectByPkBenchmark|select-pk-jdbc-postgresql |2,805.02|
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-9204:
-
Description:
According to [Apache Ignite Team
City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
test org.apache.ignite.client.ReliabilityTest@testFailover fails
intermittently with this message:
{noformat}
java.lang.AssertionError: Ignite cluster is unavailable expected null, but
was: at
org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
at
org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
* Text was not loaded fully because its' size exceeds 2 MB, see full log
for the whole text *
{noformat}
Please also fix this issue:
org.apache.kafka.connect.errors.ConnectException: Failed to find any class that
implements Converter and which name matches
org.apache.kafka.connect.storage.StringConverter, available converters are:
at
org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106)
was:
According to [Apache Ignite Team
City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
test org.apache.ignite.client.ReliabilityTest@testFailover fails
intermittently with this message:
{noformat}
java.lang.AssertionError: Ignite cluster is unavailable expected null, but
was: at
org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
at
org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
* Text was not loaded fully because its' size exceeds 2 MB, see full log
for the whole text *
{noformat}
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.8
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
> Please also fix this issue:
> org.apache.kafka.connect.errors.ConnectException: Failed to find any class
> that implements Converter and which name matches
> org.apache.kafka.connect.storage.StringConverter, available converters are:
> at
> org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-9204:
-
Comment: was deleted
(was: Please also fix this issue:
org.apache.kafka.connect.errors.ConnectException: Failed to find any class that
implements Converter and which name matches
org.apache.kafka.connect.storage.StringConverter, available converters are:
at
org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106))
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.8
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
> Please also fix this issue:
> org.apache.kafka.connect.errors.ConnectException: Failed to find any class
> that implements Converter and which name matches
> org.apache.kafka.connect.storage.StringConverter, available converters are:
> at
> org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-9204:
-
Description:
According to [Apache Ignite Team
City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
test org.apache.ignite.client.ReliabilityTest@testFailover fails
intermittently with this message:
{noformat}
java.lang.AssertionError: Ignite cluster is unavailable expected null, but
was: at
org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
at
org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
* Text was not loaded fully because its' size exceeds 2 MB, see full log
for the whole text *
{noformat}
was:
According to [Apache Ignite Team
City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
test org.apache.ignite.client.ReliabilityTest@testFailover fails
intermittently with this message:
{noformat}
java.lang.AssertionError: Ignite cluster is unavailable expected null, but
was: at
org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
at
org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
* Text was not loaded fully because its' size exceeds 2 MB, see full log
for the whole text *
{noformat}
Please also fix this issue:
org.apache.kafka.connect.errors.ConnectException: Failed to find any class that
implements Converter and which name matches
org.apache.kafka.connect.storage.StringConverter, available converters are:
at
org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106)
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.8
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10442: -- Description: Test on checks that tasks canceling does not lead to node failure [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. One of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. was: [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. One of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > > Test on checks that tasks canceling does not lead to node failure > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected". > It is necessary to investigate test and fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10442) Failed checks on successful tasks canceling
[ https://issues.apache.org/jira/browse/IGNITE-10442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-10442: -- Description: [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. One of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. was: [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. On of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. > Failed checks on successful tasks canceling > --- > > Key: IGNITE-10442 > URL: https://issues.apache.org/jira/browse/IGNITE-10442 > Project: Ignite > Issue Type: Test >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > > [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] > seems flaky. > One of the reason - "Possible thread pool starvation detected". > It is necessary to investigate test and fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10442) Failed checks on successful tasks canceling
Ivan Fedotov created IGNITE-10442: - Summary: Failed checks on successful tasks canceling Key: IGNITE-10442 URL: https://issues.apache.org/jira/browse/IGNITE-10442 Project: Ignite Issue Type: Test Reporter: Ivan Fedotov Assignee: Ivan Fedotov [testFailNodesOnCanceledTask|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1511425443970810161=testDetails_IgniteTests24Java8=%3Cdefault%3E] seems flaky. On of the reason - "Possible thread pool starvation detected". It is necessary to investigate test and fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10441) Fluent API refactoring.
Artem Malykh created IGNITE-10441:
-
Summary: Fluent API refactoring.
Key: IGNITE-10441
URL: https://issues.apache.org/jira/browse/IGNITE-10441
Project: Ignite
Issue Type: Improvement
Components: ml
Reporter: Artem Malykh
Assignee: Artem Malykh
In many classes we have fluent API ("with*" methods). We have following
problem: these methods should return exactly instance of it's own class
(otherwise we'll have problems with subclasses, more precisely, if with method
is declared in class A and we have class B extending A, with method (if we do
not override it) will return A). Currently we opted to override "with" methods
in subclasses. There is one solution which is probably more elegant, but
involves relatively complex generics construction which reduces readability:
{code:java}
class A> {
Self withX(X x) {
this.x = x;
return (Self)this;
}
class B> extends A {
// No need to override "withX" here
Self withY(Y y) {
this.y = y;
return(Self)this;
}
}
class C> extends B {
// No need to override "withX" and "withY" methods here.
}
//... etc
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701826#comment-16701826
]
Alexey Kukushkin commented on IGNITE-9204:
--
Please also fix this issue:
org.apache.kafka.connect.errors.ConnectException: Failed to find any class that
implements Converter and which name matches
org.apache.kafka.connect.storage.StringConverter, available converters are:
at
org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTest(IgniteSinkConnectorTest.java:106)
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.8
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10329) Create JDBC "query" and "query join" benchmarks and compare them with Postgres and MySQL
[
https://issues.apache.org/jira/browse/IGNITE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701824#comment-16701824
]
Pavel Kuznetsov commented on IGNITE-10329:
--
Added new seelect by PK benchmark : {{SELECT id FROM PUBLIC.PERSON WHERE id
BETWEEN ? AND ?}}
*Ignite:*
||Benchmark ||Configuration ||Queries/sec, avg||
|SimpleSelectBenchmark |select-simple-jdbc-thin-inmemory |816.77|
|SelectWithJoinBenchmark|select-join-jdbc-thin-inmemory |272.61|
|SelectByPkBenchmark|select-pk-jdbc-thin-inmemory |433.11|
|SimpleSelectBenchmark |select-simple-jdbc-thin-persistence|377.92|
|SelectWithJoinBenchmark|select-join-jdbc-thin-persistence |142.39|
|SelectByPkBenchmark|select-pk-jdbc-thin-persistence|390.17|
|SimpleSelectBenchmark |select-simple-jdbc-v2-inmemory |621.42|
|SelectWithJoinBenchmark|select-join-jdbc-v2-inmemory |203.33|
|SelectByPkBenchmark|select-pk-jdbc-v2-inmemory |694.39|
|SimpleSelectBenchmark |select-simple-jdbc-v2-persistence |480.91|
|SelectWithJoinBenchmark|select-join-jdbc-v2-persistence|173.72|
|SelectByPkBenchmark|select-pk-jdbc-v2-persistence |516.76|
> Create JDBC "query" and "query join" benchmarks and compare them with
> Postgres and MySQL
>
>
> Key: IGNITE-10329
> URL: https://issues.apache.org/jira/browse/IGNITE-10329
> Project: Ignite
> Issue Type: Task
> Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> Currently we have {{IgniteSqlQueryBenchmark}} and
> {{IgniteSqlQueryJoinBenchmark}} benchmarks which query data over salary range
> and optionally joins it with second table. Let's create a set of similar
> benchmarks which will use JDBC to load and query data, and execute them
> against one-node Ignite cluster, MySQL and Postgres.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[
https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701819#comment-16701819
]
Sergey Antonov commented on IGNITE-9980:
[~v.pyatkov] I think, that method invocation more readable
{noformat}
corruptDataEntry(
storedSysCacheCtx.caches().get(0),
new GridCacheInternalKeyImpl("sq0", "default-ds-group"),
true,
false
);
{noformat}
then
{noformat}
corruptDataEntry(storedSysCacheCtx.caches().get(0), new
GridCacheInternalKeyImpl("sq0",
"default-ds-group"), true, false);
{noformat}
May be you apply my version?
> Modify ./control.sh --cache idle_verify --dump print to diff mode (user
> persistant only/user not-persistent only/system only) cache
> ---
>
> Key: IGNITE-9980
> URL: https://issues.apache.org/jira/browse/IGNITE-9980
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: ARomantsov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.8
>
>
> It will be cool , if control.sh --cache idle_verify can show
> persistent/not-persistent/system caches and it will be impliments due utility
> flag
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701802#comment-16701802 ] Vladislav Pyatkov commented on IGNITE-9980: --- Done! > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10440) Analyse test suites for possible acceleration
Alexey Platonov created IGNITE-10440: Summary: Analyse test suites for possible acceleration Key: IGNITE-10440 URL: https://issues.apache.org/jira/browse/IGNITE-10440 Project: Ignite Issue Type: Improvement Reporter: Alexey Platonov Assignee: Alexey Platonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701760#comment-16701760
]
Denis Garus commented on IGNITE-8640:
-
[~agoncharuk] , ok.
I've fixed your comments and started RunnAll on TC.bot.
Thx!
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2332)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>
[jira] [Comment Edited] (IGNITE-8640) If first createCache fail - Ignite is freezing on next createCache
[
https://issues.apache.org/jira/browse/IGNITE-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701760#comment-16701760
]
Denis Garus edited comment on IGNITE-8640 at 11/28/18 11:46 AM:
[~agoncharuk] , ok.
I've fixed your comments and started RunAll on TC.bot.
Thx!
was (Author: garus.d.g):
[~agoncharuk] , ok.
I've fixed your comments and started RunnAll on TC.bot.
Thx!
> If first createCache fail - Ignite is freezing on next createCache
> --
>
> Key: IGNITE-8640
> URL: https://issues.apache.org/jira/browse/IGNITE-8640
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolay Izhikov
>Assignee: Denis Garus
>Priority: Critical
> Fix For: 2.8
>
>
> If first {{createCache}} operation fails on some condition inside
> {{GridCacheProcessor#validate}} then second {{createCache}} will freeze
> forever.
> Reproducer:
> {code:java}
> package org.apache.ignite.internal.processors.cache;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.testframework.GridTestUtils;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> public class CreateCacheFreezeTest extends GridCommonAbstractTest {
> public void testCreateEncryptedNotPersistedCacheFail() throws Exception {
> IgniteEx ignite = startGrid(0);
>
> GridTestUtils.assertThrowsWithCause(() -> {
> CacheConfiguration cc = new
> CacheConfiguration<>("failed");
> cc.setEvictionPolicy(new FifoEvictionPolicy());
> cc.setOnheapCacheEnabled(false);
> ignite.createCache(cc);
> return 0;
> }, IgniteCheckedException.class);
> IgniteCache cache = ignite.createCache(new
> CacheConfiguration<>("default"));
> assertNotNull(cache);
> }
> }
> {code}
> Log message:
> {noformat}
> [2018-05-29
> 16:38:11,958][ERROR][exchange-worker-#38%cache.CreateCacheFreezeTest0%][GridDhtPartitionsExchangeFuture]
> Failed to reinitialize local partitions (preloading will be stopped):
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], discoEvt=DiscoveryCustomEvent
> [customMsg=DynamicCacheChangeBatch
> [id=67cce1ca361-993dd9c2-f4fe-443b-af43-27e06424e1b0,
> reqs=[DynamicCacheChangeRequest [cacheName=failed, hasCfg=true,
> nodeId=a525b74c-aec5-4c62-855a-ff96ef30, clientStartOnly=false,
> stop=false, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=[failed], stopCaches=null,
> startGrps=[failed], stopGrps=[], resetParts=null, stateChangeRequest=null],
> startCaches=false], affTopVer=AffinityTopologyVersion [topVer=1,
> minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=a525b74c-aec5-4c62-855a-ff96ef30, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1527601090538, loc=true, ver=2.5.0#19700101-sha1:,
> isClient=false], topVer=1, nodeId8=a525b74c, msg=null,
> type=DISCOVERY_CUSTOM_EVT, tstamp=1527601091938]], nodeId=a525b74c,
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: stopping=false, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:375)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:197)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:828)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions(GridDhtPartitionTopologyImpl.java:369)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.beforeExchange(GridDhtPartitionTopologyImpl.java:544)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1190)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:722)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2452)
> at
>
[jira] [Created] (IGNITE-10439) [ML] Examples of DBSCAN
Yury Babak created IGNITE-10439: --- Summary: [ML] Examples of DBSCAN Key: IGNITE-10439 URL: https://issues.apache.org/jira/browse/IGNITE-10439 Project: Ignite Issue Type: Sub-task Reporter: Yury Babak We need an example for DBSCAN usage -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10438) [ML] DBSCAN
Yury Babak created IGNITE-10438: --- Summary: [ML] DBSCAN Key: IGNITE-10438 URL: https://issues.apache.org/jira/browse/IGNITE-10438 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak Density-based spatial clustering of applications with noise (DBSCAN) [wiki description|https://en.wikipedia.org/wiki/DBSCAN] We could test this algorithm on TWO_CLASSED_IRIS and IRIS (see MLSandboxDatasets enum) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9347) Attempt to start a dynamic cache with invalid configuration leads to exchange worker death
[
https://issues.apache.org/jira/browse/IGNITE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus reassigned IGNITE-9347:
---
Assignee: Denis Garus
> Attempt to start a dynamic cache with invalid configuration leads to exchange
> worker death
> --
>
> Key: IGNITE-9347
> URL: https://issues.apache.org/jira/browse/IGNITE-9347
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5, 2.6
>Reporter: Vladimir Ozerov
>Assignee: Denis Garus
>Priority: Blocker
> Fix For: 2.8
>
>
> Reproducer - {{SqlIllegalSchemaSelfTest}}. Technically, this test pass. But
> note the following:
> 1) See logs of {{*Dynamic}} tests - instead of normal stop, node gets killed
> by failure detector:
> {code:java}
> [2018-08-22
> 14:20:39,777][ERROR][exchange-worker-#77%query.SqlIllegalSchemaSelfTest%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=class o.a.i.failure.NoOpFailureHandler,
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.AssertionError: stopping=true, groupName=null, caches=[]]]
> java.lang.AssertionError: stopping=true, groupName=null, caches=[]
> at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:371){code}
> 2) Similar behavior is observed if one tries to start caches with invalid
> configuration twice. Pick any {{*Dynamic}} test and just copy/paste
> {{GridTestUtils.assertThrows}} logic one after another. Expected - two
> expected exceptions, actual - node is killed.
>
> Possibly duplicate of IGNITE-8640 (need to double-check)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9980) Modify ./control.sh --cache idle_verify --dump print to diff mode (user persistant only/user not-persistent only/system only) cache
[ https://issues.apache.org/jira/browse/IGNITE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701728#comment-16701728 ] Vyacheslav Koptilin commented on IGNITE-9980: - Hello [~v.pyatkov] , In general, I have no objections related to the proposed change, i.e. LGTM :) Please fix minor code style issues. > Modify ./control.sh --cache idle_verify --dump print to diff mode (user > persistant only/user not-persistent only/system only) cache > --- > > Key: IGNITE-9980 > URL: https://issues.apache.org/jira/browse/IGNITE-9980 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > It will be cool , if control.sh --cache idle_verify can show > persistent/not-persistent/system caches and it will be impliments due utility > flag -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8903) IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701685#comment-16701685
]
Ivan Fedotov edited comment on IGNITE-8903 at 11/28/18 10:49 AM:
-
Hi [~ruslangm], [~SomeFire]! I faced with the same problem in
[IGNITE-10343|https://issues.apache.org/jira/browse/IGNITE-10343]. This test
fails because a grid was not stopped in the previous test , so I wrapped it in
try/finally block and now
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails]
looks better. Also I investigated the reason of the failed test - it's
testGetRestartPartitioned1: it is muted now and it failes on this
[check|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L253]:
seems like some data was lost.
So I propose close this issue as a duplicate and create a ticket for fix
testGetRestartPartitioned1. What do you think?
was (Author: ivanan.fed):
Hi [~ruslangm], [~SomeFire]! I faced with the same problem in
[IGNITE-10343|https://issues.apache.org/jira/browse/IGNITE-10343]. This test
fails because grid was not stopped in the previous test , so I wrapped it in
try/finally block and now
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails]
looks better. Also I investigated the reason of failed test - it's
testGetRestartPartitioned1: it is muted now and it failes on this
[check|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L253]:
seems like some data was lost.
So I propose close this issue as a duplicate and create ticket for fix
testGetRestartPartitioned1. What do you think?
> IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
> --
>
> Key: IGNITE-8903
> URL: https://issues.apache.org/jira/browse/IGNITE-8903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Ruslan Gilemzyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> Test {{IgniteCacheGetRestartTest.testGetRestartReplicated}} fails with
> message:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Ignite instance with this name has
> already been started: distributed.IgniteCacheGetRestartTest5{code}
> Probably some grids remains not stopped between test-cases within
> IgniteCacheGetRestartTest.
>
> TC (master):
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8903) IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701685#comment-16701685
]
Ivan Fedotov edited comment on IGNITE-8903 at 11/28/18 10:48 AM:
-
Hi [~ruslangm], [~SomeFire]! I faced with the same problem in
[IGNITE-10343|https://issues.apache.org/jira/browse/IGNITE-10343]. This test
fails because grid was not stopped in the previous test , so I wrapped it in
try/finally block and now
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails]
looks better. Also I investigated the reason of failed test - it's
testGetRestartPartitioned1: it is muted now and it failes on this
[check|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L253]:
seems like some data was lost.
So I propose close this issue as a duplicate and create ticket for fix
testGetRestartPartitioned1. What do you think?
was (Author: ivanan.fed):
Hi [~ruslangm], [~SomeFire]! I faced with the same problem in
[IGNITE-10343|https://issues.apache.org/jira/browse/IGNITE-10343]. This test
fails because grid was not stopped in the previous test , so I wrapped it in
try/finally block and now
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails]
looks better. testGetRestartPartitioned1
Also I investigated the reason of failed test - it's
testGetRestartPartitioned1: it is muted now and it failes on this
[check|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L253]:
seems like some data was lost.
So I propose close this issue as a duplicate and create ticket for fix
testGetRestartPartitioned1. What do you think?
> IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
> --
>
> Key: IGNITE-8903
> URL: https://issues.apache.org/jira/browse/IGNITE-8903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Ruslan Gilemzyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> Test {{IgniteCacheGetRestartTest.testGetRestartReplicated}} fails with
> message:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Ignite instance with this name has
> already been started: distributed.IgniteCacheGetRestartTest5{code}
> Probably some grids remains not stopped between test-cases within
> IgniteCacheGetRestartTest.
>
> TC (master):
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8903) IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
[
https://issues.apache.org/jira/browse/IGNITE-8903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701685#comment-16701685
]
Ivan Fedotov commented on IGNITE-8903:
--
Hi [~ruslangm], [~SomeFire]! I faced with the same problem in
[IGNITE-10343|https://issues.apache.org/jira/browse/IGNITE-10343]. This test
fails because grid was not stopped in the previous test , so I wrapped it in
try/finally block and now
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails]
looks better. testGetRestartPartitioned1
Also I investigated the reason of failed test - it's
testGetRestartPartitioned1: it is muted now and it failes on this
[check|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/IgniteCacheGetRestartTest.java#L253]:
seems like some data was lost.
So I propose close this issue as a duplicate and create ticket for fix
testGetRestartPartitioned1. What do you think?
> IgniteCacheGetRestartTest.testGetRestartReplicated fails in master
> --
>
> Key: IGNITE-8903
> URL: https://issues.apache.org/jira/browse/IGNITE-8903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Ruslan Gilemzyanov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> Test {{IgniteCacheGetRestartTest.testGetRestartReplicated}} fails with
> message:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Ignite instance with this name has
> already been started: distributed.IgniteCacheGetRestartTest5{code}
> Probably some grids remains not stopped between test-cases within
> IgniteCacheGetRestartTest.
>
> TC (master):
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7917326378982816549=testDetails_IgniteTests24Java8=%3Cdefault%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10298) Possible deadlock between restore partition states and checkpoint begin
[
https://issues.apache.org/jira/browse/IGNITE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701683#comment-16701683
]
ASF GitHub Bot commented on IGNITE-10298:
-
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5517
> Possible deadlock between restore partition states and checkpoint begin
> ---
>
> Key: IGNITE-10298
> URL: https://issues.apache.org/jira/browse/IGNITE-10298
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
>
> There is possible deadlock between "restorePartitionStates" phase during
> caches starting and currently running checkpointer:
> {noformat}
> "db-checkpoint-thread-#50" #89 prio=5 os_prio=0 tid=0x1ad57800
> nid=0x2b58 waiting on condition [0x7e42e000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xddabfcc8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7515)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1331)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:1459)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3397)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3009)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2934)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> "exchange-worker-#42" #69 prio=5 os_prio=0 tid=0x1c1cd800 nid=0x259c
> waiting on condition [0x249ae000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x80b634a0> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1328)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1212)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.initialUpdateCounter(GridCacheOffheapManager.java:1537)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onPartitionInitialCounterUpdated(GridCacheOffheapManager.java:633)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2365)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1174)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1119)
> at
>
