[jira] [Commented] (IGNITE-12228) Implement an Apache Beam runner on top of Ignite compute grid?
[ https://issues.apache.org/jira/browse/IGNITE-12228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937244#comment-16937244 ] Denis Magda commented on IGNITE-12228: -- [~romain.manni-bucau] are you willing to contribute? The dev community can help you along the way. > Implement an Apache Beam runner on top of Ignite compute grid? > -- > > Key: IGNITE-12228 > URL: https://issues.apache.org/jira/browse/IGNITE-12228 > Project: Ignite > Issue Type: Wish >Reporter: Romain Manni-Bucau >Priority: Major > > Apache Ignite provides a compute grid. > It is therefore feasible to use that to execute a DAG pipeline. > Therefore implementing a Apache Beam runner executing a DAG on an ignite > cluster would be very valuable for users and would provide a very interesting > alternative to Spark, Dataflow etc...which would be very valuable when using > data from ignite itself. > Hoping it can help, here is Hazelcast Jet implementation which is not that > far even if Jet is a bit more advanced in term of DAG support: > [https://github.com/apache/beam/tree/master/runners/jet-experimental/src/main/java/org/apache/beam/runners/jet] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12054) Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937242#comment-16937242 ] Denis Magda commented on IGNITE-12054: -- [~NIzhikov], let's follow your original plan by producing 2 new modules. This modularization story will take a while. > Upgrade Spark module to 2.4 > --- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.7.5 >Reporter: Denis Magda >Assignee: Nikolay Izhikov >Priority: Blocker > Fix For: 2.8 > > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-12174:
-
Environment:
Ignite modules
* ignite-core
* ignite-indexing
* ignite-geospatial
Durable memory activated
Geospatial indexing in use
was:
Ignite 2.7.5
* ignite-core
* ignite-indexing
* ignite-geospatial
Durable memory activated
Geospatial indexing in use
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.6
> Environment: Ignite modules
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
> Attachments: IgniteBug.java
>
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian
[jira] [Updated] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-12174:
-
Affects Version/s: (was: 2.7.5)
2.7.6
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.6
> Environment: Ignite 2.7.5
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
> Attachments: IgniteBug.java
>
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937236#comment-16937236
]
Jan Schäfer commented on IGNITE-12174:
--
After deeper debugging it looks like the GridH2SpatialIndex is not filled again
when Ignite restarts and reads the data from the durable memory.
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.5
> Environment: Ignite 2.7.5
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
> Attachments: IgniteBug.java
>
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-12174:
-
Affects Version/s: 2.8
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.5
> Environment: Ignite 2.7.5
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
> Attachments: IgniteBug.java
>
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-12220:
--
Description: Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions
are enforced to be system-level permissions, see for instance
{{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks inflexible:
Ignite Security implementations are not able to manage cache creation and
deletion permissions on per-cache basis (unlike get/put/remove permissions).
All such limitations should be found and removed in order to allow all
{{CACHE_*}} permissions to be set both at system and per-cache levels. (was:
Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
be system-level permissions, see for instance
{{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks inflexible:
Ignite Security implementations are not able to manage cache creation and
deletion permissions on per-cache basis (unlike get/put/remove permissions).
All such limitations should be found and removed on order to allow all
{{CACHE_*}} permissions to be set both at system and per-cache levels.)
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12229) Column not found when using CASE named column from result
[
https://issues.apache.org/jira/browse/IGNITE-12229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-12229:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Column not found when using CASE named column from result
> -
>
> Key: IGNITE-12229
> URL: https://issues.apache.org/jira/browse/IGNITE-12229
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7.6
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> Consider the following SQL:
> {code}
> create table main (key varchar primary key, val int, grouper int);
> create table joiner (key varchar primary key, value int, grouper int);
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper;
> {code}
> Expected behavior - success.
> Observed behavior:
> {code}
> [20:31:13,498][SEVERE][jdbc-request-handler-worker-#1828][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select m.key, case when
> m.grouper > j.grouper then 1 else -1 end d_grouper from main m join joiner j
> on m.key = j.key where d_grouper = 1 order by d_grouper, args=[],
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query. Столбец "D_GROUPER" не найден
> Column "D_GROUPER" not found; SQL statement:
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper [42122-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2653)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2356)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2128)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2123)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2693)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2137)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.h2.jdbc.JdbcSQLException: Столбец "D_GROUPER" не найден
> Column "D_GROUPER" not found; SQL statement:
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper [42122-197]
> at
> org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at
> org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:150)
> at org.h2.expression.Comparison.optimize(Comparison.java:177)
> at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:130)
> at org.h2.command.dml.Select.prepare(Select.java:861)
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> at
> org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:539)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:509)
> at
>
[jira] [Commented] (IGNITE-12229) Column not found when using CASE named column from result
[
https://issues.apache.org/jira/browse/IGNITE-12229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937031#comment-16937031
]
Ilya Kasnacheev commented on IGNITE-12229:
--
I think I also saw this issue with GROUP BY and count(m.key) but now I can't
reproduce. Hopefully we'll fix all cases.
> Column not found when using CASE named column from result
> -
>
> Key: IGNITE-12229
> URL: https://issues.apache.org/jira/browse/IGNITE-12229
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7.6
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> Consider the following SQL:
> {code}
> create table main (key varchar primary key, val int, grouper int);
> create table joiner (key varchar primary key, value int, grouper int);
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper;
> {code}
> Expected behavior - success.
> Observed behavior:
> {code}
> [20:31:13,498][SEVERE][jdbc-request-handler-worker-#1828][JdbcRequestHandler]
> Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
> [schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select m.key, case when
> m.grouper > j.grouper then 1 else -1 end d_grouper from main m join joiner j
> on m.key = j.key where d_grouper = 1 order by d_grouper, args=[],
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query. Столбец "D_GROUPER" не найден
> Column "D_GROUPER" not found; SQL statement:
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper [42122-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2653)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2356)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2196)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2128)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2123)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2693)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2137)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.h2.jdbc.JdbcSQLException: Столбец "D_GROUPER" не найден
> Column "D_GROUPER" not found; SQL statement:
> select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper
> from main m join joiner j on m.key = j.key where d_grouper = 1 order by
> d_grouper [42122-197]
> at
> org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at
> org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:150)
> at org.h2.expression.Comparison.optimize(Comparison.java:177)
> at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:130)
> at org.h2.command.dml.Select.prepare(Select.java:861)
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> at
> org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:539)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:509)
> at
>
[jira] [Created] (IGNITE-12229) Column not found when using CASE named column from result
Ilya Kasnacheev created IGNITE-12229:
Summary: Column not found when using CASE named column from result
Key: IGNITE-12229
URL: https://issues.apache.org/jira/browse/IGNITE-12229
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 2.7.6
Reporter: Ilya Kasnacheev
Consider the following SQL:
{code}
create table main (key varchar primary key, val int, grouper int);
create table joiner (key varchar primary key, value int, grouper int);
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper;
{code}
Expected behavior - success.
Observed behavior:
{code}
[20:31:13,498][SEVERE][jdbc-request-handler-worker-#1828][JdbcRequestHandler]
Failed to execute SQL query [reqId=0, req=JdbcQueryExecuteRequest
[schemaName=PUBLIC, pageSize=1024, maxRows=0, sqlQry=select m.key, case when
m.grouper > j.grouper then 1 else -1 end d_grouper from main m join joiner j on
m.key = j.key where d_grouper = 1 order by d_grouper, args=[],
stmtType=ANY_STATEMENT_TYPE, autoCommit=true]]
class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
parse query. Столбец "D_GROUPER" не найден
Column "D_GROUPER" not found; SQL statement:
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper
[42122-197]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2653)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:2356)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:2196)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2128)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2123)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2693)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2137)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:511)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:245)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandlerWorker.body(JdbcRequestHandlerWorker.java:90)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.h2.jdbc.JdbcSQLException: Столбец "D_GROUPER" не найден
Column "D_GROUPER" not found; SQL statement:
select m.key, case when m.grouper > j.grouper then 1 else -1 end d_grouper from
main m join joiner j on m.key = j.key where d_grouper = 1 order by d_grouper
[42122-197]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at
org.h2.expression.ExpressionColumn.optimize(ExpressionColumn.java:150)
at org.h2.expression.Comparison.optimize(Comparison.java:177)
at org.h2.expression.ConditionAndOr.optimize(ConditionAndOr.java:130)
at org.h2.command.dml.Select.prepare(Select.java:861)
at org.h2.command.Parser.prepareCommand(Parser.java:283)
at org.h2.engine.Session.prepareLocal(Session.java:611)
at org.h2.engine.Session.prepareCommand(Session.java:549)
at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
at
org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepare0(IgniteH2Indexing.java:539)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:509)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatement(IgniteH2Indexing.java:476)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2635)
... 12 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12228) Implement an Apache Beam runner on top of Ignite compute grid?
Romain Manni-Bucau created IGNITE-12228: --- Summary: Implement an Apache Beam runner on top of Ignite compute grid? Key: IGNITE-12228 URL: https://issues.apache.org/jira/browse/IGNITE-12228 Project: Ignite Issue Type: Wish Reporter: Romain Manni-Bucau Apache Ignite provides a compute grid. It is therefore feasible to use that to execute a DAG pipeline. Therefore implementing a Apache Beam runner executing a DAG on an ignite cluster would be very valuable for users and would provide a very interesting alternative to Spark, Dataflow etc...which would be very valuable when using data from ignite itself. Hoping it can help, here is Hazelcast Jet implementation which is not that far even if Jet is a bit more advanced in term of DAG support: [https://github.com/apache/beam/tree/master/runners/jet-experimental/src/main/java/org/apache/beam/runners/jet] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12206) Partition state validation warns are not printed to log
[
https://issues.apache.org/jira/browse/IGNITE-12206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936946#comment-16936946
]
Pavel Kovalenko commented on IGNITE-12206:
--
[~mstepachev] Thank you for contribution. Merged to master.
> Partition state validation warns are not printed to log
> ---
>
> Key: IGNITE-12206
> URL: https://issues.apache.org/jira/browse/IGNITE-12206
> Project: Ignite
> Issue Type: Bug
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GridDhtPartitionsExchangeFuture.java
>
> {code:java}
> if (grpCtx == null
> || grpCtx.config().isReadThrough()
> || grpCtx.config().isWriteThrough()
> || grpCtx.config().getCacheStoreFactory() != null
> || grpCtx.config().getRebalanceDelay() == -1
> || grpCtx.config().getRebalanceMode() ==
> CacheRebalanceMode.NONE
> || grpCtx.config().getExpiryPolicyFactory() == null
> || SKIP_PARTITION_SIZE_VALIDATION)
> return null;{code}
>
> Looks like a typo, probably it should be
> grpCtx.config().getExpiryPolicyFactory() != null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12206) Partition state validation warns are not printed to log
[
https://issues.apache.org/jira/browse/IGNITE-12206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kovalenko updated IGNITE-12206:
-
Affects Version/s: 2.7
> Partition state validation warns are not printed to log
> ---
>
> Key: IGNITE-12206
> URL: https://issues.apache.org/jira/browse/IGNITE-12206
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GridDhtPartitionsExchangeFuture.java
>
> {code:java}
> if (grpCtx == null
> || grpCtx.config().isReadThrough()
> || grpCtx.config().isWriteThrough()
> || grpCtx.config().getCacheStoreFactory() != null
> || grpCtx.config().getRebalanceDelay() == -1
> || grpCtx.config().getRebalanceMode() ==
> CacheRebalanceMode.NONE
> || grpCtx.config().getExpiryPolicyFactory() == null
> || SKIP_PARTITION_SIZE_VALIDATION)
> return null;{code}
>
> Looks like a typo, probably it should be
> grpCtx.config().getExpiryPolicyFactory() != null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12227) Default auto-adjust baseline enabled flag calculated incorrectly in some cases
[ https://issues.apache.org/jira/browse/IGNITE-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-12227: --- Priority: Blocker (was: Major) > Default auto-adjust baseline enabled flag calculated incorrectly in some cases > -- > > Key: IGNITE-12227 > URL: https://issues.apache.org/jira/browse/IGNITE-12227 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.8 > > > baselineAutoAdjustEnabled can be been different on different nodes because of > the calculation of default value happening locally on each node and including > only local configuration. It issue can happen by the following reasons: > * If IGNITE_BASELINE_AUTO_ADJUST_ENABLED flag set to a different value on > different nodes it leads to cluster hanging due to baseline calculation > finishing with the unpredictable state on each node. > * if cluster in mixed mode(included in-memory and persistent nodes) sometimes > flag is set to a different value due to calculation doesn't consider remote > nodes configuration. > Possible solution(both points required): > * Get rid of IGNITE_BASELINE_AUTO_ADJUST_ENABLED and replace it by the > explicit call of IgniteCluster#baselineAutoAdjustEnabled where it > required(test only). > * Calculating default value on the first started node as early as > possible(instead of activation) and this value always should be set to > distributed metastorage(unlike it happening now). It means that instead of > awaiting activation, the default value would be calculated by the first > started node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12227) Default auto-adjust baseline enabled flag calculated incorrectly in some cases
[ https://issues.apache.org/jira/browse/IGNITE-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kalashnikov updated IGNITE-12227: --- Fix Version/s: 2.8 > Default auto-adjust baseline enabled flag calculated incorrectly in some cases > -- > > Key: IGNITE-12227 > URL: https://issues.apache.org/jira/browse/IGNITE-12227 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > baselineAutoAdjustEnabled can be been different on different nodes because of > the calculation of default value happening locally on each node and including > only local configuration. It issue can happen by the following reasons: > * If IGNITE_BASELINE_AUTO_ADJUST_ENABLED flag set to a different value on > different nodes it leads to cluster hanging due to baseline calculation > finishing with the unpredictable state on each node. > * if cluster in mixed mode(included in-memory and persistent nodes) sometimes > flag is set to a different value due to calculation doesn't consider remote > nodes configuration. > Possible solution(both points required): > * Get rid of IGNITE_BASELINE_AUTO_ADJUST_ENABLED and replace it by the > explicit call of IgniteCluster#baselineAutoAdjustEnabled where it > required(test only). > * Calculating default value on the first started node as early as > possible(instead of activation) and this value always should be set to > distributed metastorage(unlike it happening now). It means that instead of > awaiting activation, the default value would be calculated by the first > started node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12227) Default auto-adjust baseline enabled flag calculated incorrectly in some cases
Anton Kalashnikov created IGNITE-12227: -- Summary: Default auto-adjust baseline enabled flag calculated incorrectly in some cases Key: IGNITE-12227 URL: https://issues.apache.org/jira/browse/IGNITE-12227 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov baselineAutoAdjustEnabled can be been different on different nodes because of the calculation of default value happening locally on each node and including only local configuration. It issue can happen by the following reasons: * If IGNITE_BASELINE_AUTO_ADJUST_ENABLED flag set to a different value on different nodes it leads to cluster hanging due to baseline calculation finishing with the unpredictable state on each node. * if cluster in mixed mode(included in-memory and persistent nodes) sometimes flag is set to a different value due to calculation doesn't consider remote nodes configuration. Possible solution(both points required): * Get rid of IGNITE_BASELINE_AUTO_ADJUST_ENABLED and replace it by the explicit call of IgniteCluster#baselineAutoAdjustEnabled where it required(test only). * Calculating default value on the first started node as early as possible(instead of activation) and this value always should be set to distributed metastorage(unlike it happening now). It means that instead of awaiting activation, the default value would be calculated by the first started node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12226) Improve BinaryObjectException message
Kirill Tkalenko created IGNITE-12226:
Summary: Improve BinaryObjectException message
Key: IGNITE-12226
URL: https://issues.apache.org/jira/browse/IGNITE-12226
Project: Ignite
Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 2.8
We are getting the following exception in case of different type IDs:
{noformat}
org.apache.ignite.binary.BinaryObjectException: Failed to get field because
type ID of passed object differs from type ID this BinaryField belongs to
[expected=-635374417, actual=1778229603]
at
org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
at
org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
at
org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
at
org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:106)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:350)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:56)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4614)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4534)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$1300(BPlusTree.java:92)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:296)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4967)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:276)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4952)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:161)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:348)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2450)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2203)
{noformat}
This message isn't informative. We should print more detailes about types, for
example classname, class structure (if applicable), which field in class we
tried to read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> {{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
--activate, --deactivate, --read-only-on, --read-only-off
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate, --read-only-on, --read-only-off
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}}
> # Add warn message that command is depricated in control.sh. Commands:
> {{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
# Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
## Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
## Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
## Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> ## {{ClusterState state()}} returns current cluster state
> ## {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}}
> # Add warn message that command is depricated in control.sh. Commands:
> {{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12225) Add enum for cluster state
Sergey Antonov created IGNITE-12225:
---
Summary: Add enum for cluster state
Key: IGNITE-12225
URL: https://issues.apache.org/jira/browse/IGNITE-12225
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
## {{ClusterState state()}} returns current cluster state
## {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
## Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
## Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}}
## Add warn message that command is depricated in control.sh. Commands:
{{--activate}}, {{--deactivate}}, {{--read-only-on}}, {{--read-only-off}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-5302. -- Resolution: Won't Fix > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-5302: - Release Note: (was: Folks, this issue is outdated: test testPartitionLossAndRecover does not exist anymore we have baseline topology now I would like to close it. Fill free to reopen it if I am wrong.) > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reopened IGNITE-5302: -- > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-5302. -- Resolution: Fixed Folks, this issue is outdated: test testPartitionLossAndRecover does not exist anymore we have baseline topology now I would like to close it. Fill free to reopen it if I am wrong. > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reopened IGNITE-5302: -- > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-5302. -- Release Note: Folks, this issue is outdated: test testPartitionLossAndRecover does not exist anymore we have baseline topology now I would like to close it. Fill free to reopen it if I am wrong. Resolution: Won't Fix > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-5302) Empty LOST partition may be used as OWNING after resetting lost partitions
[ https://issues.apache.org/jira/browse/IGNITE-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-5302: Assignee: (was: Pavel Pereslegin) > Empty LOST partition may be used as OWNING after resetting lost partitions > -- > > Key: IGNITE-5302 > URL: https://issues.apache.org/jira/browse/IGNITE-5302 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > Fix For: 2.8 > > > h2. Notes > Test *testPartitionLossAndRecover* reproducing the issue can be found in > ignite-5267 branch with PDS functionality. > h2. Steps to reproduce > # Four nodes are started, some key is added to partitioned cache > # Primary and backup nodes for the key are stopped, key's partition is > declared LOST on remaining nodes > # Primary and backup nodes are started again, cache's lost partitions are > reset > # Key is requested from cache > h2. Expected behavior > Correct value is returned from primary for this partition > h2. Actual behavior > Request for value is sent to node where partition is empty (not to primary > node), null is returned > h2. Latest findings > # The main problem with the scenario is that request for key gets mapped not > only to P/B nodes with real value but also to the node where that partition > existed only in LOST state after P/B shutdown on step #2 > # It was found that on step #3 after primary and backup are joined partition > counter is increased for empty partition in LOST state which looks wrong -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5792) IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint is failing on TC
[ https://issues.apache.org/jira/browse/IGNITE-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936748#comment-16936748 ] Pavel Pereslegin commented on IGNITE-5792: -- [~sergey-chugunov], I don't see any failures now on TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=7381166856692257748=TEST_STATUS_DESC_IgniteTests24Java8=%3Cdefault%3E=50 Does this mean that this issue is outdated and we can close this ticket? > IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint > is failing on TC > > > Key: IGNITE-5792 > URL: https://issues.apache.org/jira/browse/IGNITE-5792 > Project: Ignite > Issue Type: Test > Components: persistence >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Labels: MakeTeamcityGreenAgain, test-fail > > Test > IgnitePdsAtomicCacheRebalancingTest.testRebalancingOnRestartAfterCheckpoint > started failing on TC. > Failures must be investigated and fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11848: - Issue Type: Improvement (was: Task) > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, important > Fix For: 2.8 > > Time Spent: 7h > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9410) Add transactions support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9410: Issue Type: Improvement (was: Task) > Add transactions support to thin clients > > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Improvement > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34, important > Fix For: 2.8 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11848: - Labels: IEP-35 important (was: IEP-35) > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, important > Fix For: 2.8 > > Time Spent: 7h > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11848) [IEP-35] Monitoring Phase 1
[ https://issues.apache.org/jira/browse/IGNITE-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11848: - Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > [IEP-35] Monitoring Phase 1 > -- > > Key: IGNITE-11848 > URL: https://issues.apache.org/jira/browse/IGNITE-11848 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 7h > Remaining Estimate: 0h > > Umbrella ticket for the IEP-35. Monitoring and profiling. > Phase 1 should include: > * NextGen monitoring subsystem implementation to manage > ** metrics > ** -lists- (will be implemented in the following tickets) > ** exporters > * JMX, SQLView, Log exporters > * Migration of existing metrics to new manager > * -Lists for all Ignite user API- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11905) [IEP-35] Monitoring Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11905: - Labels: IEP-35 important (was: IEP-35) > [IEP-35] Monitoring Phase 2 > -- > > Key: IGNITE-11905 > URL: https://issues.apache.org/jira/browse/IGNITE-11905 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, important > Fix For: 2.8 > > > Phase 2 should introduce: > Ability to collect lists of some internal object Ignite manage. > Examples of such objects: > * Caches > * Queries (including continuous queries) > * Services > * Compute tasks > * Distributed Data Structures > * etc... > 1. Fields for each list should be discussed in separate tickets > 2. Metric Exporters (optionally) can support list export. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11905) [IEP-35] Monitoring Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11905: - Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > [IEP-35] Monitoring Phase 2 > -- > > Key: IGNITE-11905 > URL: https://issues.apache.org/jira/browse/IGNITE-11905 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > Phase 2 should introduce: > Ability to collect lists of some internal object Ignite manage. > Examples of such objects: > * Caches > * Queries (including continuous queries) > * Services > * Compute tasks > * Distributed Data Structures > * etc... > 1. Fields for each list should be discussed in separate tickets > 2. Metric Exporters (optionally) can support list export. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12145) [IEP-35] Monitoring list engine
[ https://issues.apache.org/jira/browse/IGNITE-12145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12145: - Labels: IEP-35 (was: IEP-35 important) > [IEP-35] Monitoring list engine > --- > > Key: IGNITE-12145 > URL: https://issues.apache.org/jira/browse/IGNITE-12145 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 20h 40m > Remaining Estimate: 0h > > The base engine for the monitoring list. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12145) [IEP-35] Monitoring list engine
[ https://issues.apache.org/jira/browse/IGNITE-12145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12145: - Labels: IEP-35 important (was: IEP-35) > [IEP-35] Monitoring list engine > --- > > Key: IGNITE-12145 > URL: https://issues.apache.org/jira/browse/IGNITE-12145 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.5 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, important > Fix For: 2.8 > > Time Spent: 20h 40m > Remaining Estimate: 0h > > The base engine for the monitoring list. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9607) Service Grid redesign - phase 1
[ https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9607: Labels: important (was: ) > Service Grid redesign - phase 1 > --- > > Key: IGNITE-9607 > URL: https://issues.apache.org/jira/browse/IGNITE-9607 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: important > Fix For: 2.8 > > > This is an umbrella ticket for tasks which should be implemented atomically > in phase #1 of Service Grid redesign. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9607) Service Grid redesign - phase 1
[ https://issues.apache.org/jira/browse/IGNITE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9607: Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > Service Grid redesign - phase 1 > --- > > Key: IGNITE-9607 > URL: https://issues.apache.org/jira/browse/IGNITE-9607 > Project: Ignite > Issue Type: Improvement > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Fix For: 2.8 > > > This is an umbrella ticket for tasks which should be implemented atomically > in phase #1 of Service Grid redesign. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936714#comment-16936714
]
Ivan Pavlukhin commented on IGNITE-7285:
[~samaitra], thank you for continuing work on it. I left
[comments|https://github.com/apache/ignite/pull/6490#pullrequestreview-292345841].
If you agree with them please proceed with tests.
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
>Priority: Major
> Labels: sql-stability
> Fix For: 2.8
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6903) Implement new JMX metrics for Indexing
[ https://issues.apache.org/jira/browse/IGNITE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6903: Fix Version/s: (was: 2.8) > Implement new JMX metrics for Indexing > -- > > Key: IGNITE-6903 > URL: https://issues.apache.org/jira/browse/IGNITE-6903 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Anton Vinogradov >Priority: Critical > Labels: iep-6, important > > These additional metrics and methods should be implemented: > - Space occupied by indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9410) Add transactions support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9410: Labels: iep-34 important (was: iep-34) > Add transactions support to thin clients > > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34, important > Fix For: 2.8 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9410) Add transactions support to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9410: Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) > Add transactions support to thin clients > > > Key: IGNITE-9410 > URL: https://issues.apache.org/jira/browse/IGNITE-9410 > Project: Ignite > Issue Type: Task > Components: mvcc, thin client >Reporter: Vladimir Ozerov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-34 > Fix For: 2.8 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently only ODBC and JDBC drivers support transactions and in not very > efficient way. We need to add transactional API to .NET, Java, CPP, NodeJS > and Python clients. > Key pieces: > # Add API to relevant clients > # Review listener logic - currently we create separate threads. But is it > really needed? > ## If there is an implicit operation and no ongoing transaction, then > operation might be executed right away > ## If cache operations are decoupled from threads, then we can resort to > reactive approach, when multiple transactions could be executed from the same > thread -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5473) Create ignite troubleshooting logger
[ https://issues.apache.org/jira/browse/IGNITE-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936705#comment-16936705 ] Maxim Muzafarov commented on IGNITE-5473: - [~agoncharuk] Are we planning to include this issue to 2.8 release? It seems to me that we can shift it to the next release? > Create ignite troubleshooting logger > > > Key: IGNITE-5473 > URL: https://issues.apache.org/jira/browse/IGNITE-5473 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Critical > Labels: important, observability > Fix For: 2.8 > > > Currently, we have two extremes of logging - either INFO wich logs almost > nothing, or DEBUG, which will pollute logs with too verbose messages. > We should create a 'troubleshooting' logger, which should be easily enabled > (via a system property, for example) and log all stability-critical node and > cluster events: > * Connection events (both communication and discovery), handshake status > * ALL ignored messages and skipped actions (even those we assume are safe to > ignore) > * Partition exchange stages and timings > * Verbose discovery state changes (this should make it easy to understand > the reason for 'Node has not been connected to the topology') > * Transaction failover stages and actions > * All unlogged exceptions > * Responses that took more than N milliseconds when in normal they should > return right away > * Long discovery SPI messages processing times > * Managed service deployment stages > * Marshaller mappings registration and notification > * Binary metadata registration and notification > * Continuous query registration / notification > (add more) > The amount of logging should be chosen accurately so that it would be safe to > enable this logger in production clusters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov updated IGNITE-6893:
-
Fix Version/s: (was: 2.8)
> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
> Labels: iep-7
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock.
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a
> warning on UI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov reassigned IGNITE-6893:
Assignee: (was: Andrey Kuznetsov)
> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
> Labels: iep-7
> Fix For: 2.8
>
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock.
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a
> warning on UI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10790) Control.sh add ability to check tx on deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936701#comment-16936701
]
Maxim Muzafarov commented on IGNITE-10790:
--
Sergey,
I've removed the 2.8 release label due to the issue inactivity. If we are
planning to include it to 2.8 release, let's discuss it on dev-list.
> Control.sh add ability to check tx on deadlock
> --
>
> Key: IGNITE-10790
> URL: https://issues.apache.org/jira/browse/IGNITE-10790
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We should have ability to check selected transaction on deadlock in this
> moment. The typical scenario: we have long running transaction and we can't
> separate deadlock and normal transaction.
> Possible command: {{control.sh --tx detect_deadlock [,xid1,xid2]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10790) Control.sh add ability to check tx on deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10790:
-
Fix Version/s: (was: 2.8)
> Control.sh add ability to check tx on deadlock
> --
>
> Key: IGNITE-10790
> URL: https://issues.apache.org/jira/browse/IGNITE-10790
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Priority: Major
>
> We should have ability to check selected transaction on deadlock in this
> moment. The typical scenario: we have long running transaction and we can't
> separate deadlock and normal transaction.
> Possible command: {{control.sh --tx detect_deadlock [,xid1,xid2]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6895: Ignite Flags: Docs Required,Release Notes Required > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6895: Fix Version/s: (was: 2.8) > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936699#comment-16936699 ] Maxim Muzafarov commented on IGNITE-6895: - Folks, I've removed 2.8 label due to the issue inactivity > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > Fix For: 2.8 > > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10790) Control.sh add ability to check tx on deadlock
[
https://issues.apache.org/jira/browse/IGNITE-10790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10790:
-
Ignite Flags: Docs Required,Release Notes Required (was: Docs Required)
> Control.sh add ability to check tx on deadlock
> --
>
> Key: IGNITE-10790
> URL: https://issues.apache.org/jira/browse/IGNITE-10790
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We should have ability to check selected transaction on deadlock in this
> moment. The typical scenario: we have long running transaction and we can't
> separate deadlock and normal transaction.
> Possible command: {{control.sh --tx detect_deadlock [,xid1,xid2]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6980) Automatic cancelling of hanging Ignite operations
[ https://issues.apache.org/jira/browse/IGNITE-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-6980: -- Fix Version/s: (was: 2.8) > Automatic cancelling of hanging Ignite operations > - > > Key: IGNITE-6980 > URL: https://issues.apache.org/jira/browse/IGNITE-6980 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Priority: Blocker > Labels: iep-7, important > > If an Ignite operation hangs due to some reason due to an internal problem or > buggy application code it needs to eventual fail after a timeout fires. > An application must not freeze waiting for a human being intervention if an > atomic update fails internally. > Even more, I would let all possible operation to fail after a timeout fires: > - Ignite compute computations (covered by IGNITE-6940). > - Ignite services calls. > - Atomic cache updates (see devlist discussion - > [http://apache-ignite-developers.2346864.n4.nabble.com/Timeouts-in-atomic-cache-td19839.html]). > - Transactional cache updates (covered by IGNITE-6894 and IGNITE-6895). > - SQL queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-6980) Automatic cancelling of hanging Ignite operations
[ https://issues.apache.org/jira/browse/IGNITE-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-6980: - Assignee: (was: Aleksey Plekhanov) > Automatic cancelling of hanging Ignite operations > - > > Key: IGNITE-6980 > URL: https://issues.apache.org/jira/browse/IGNITE-6980 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Magda >Priority: Blocker > Labels: iep-7, important > Fix For: 2.8 > > > If an Ignite operation hangs due to some reason due to an internal problem or > buggy application code it needs to eventual fail after a timeout fires. > An application must not freeze waiting for a human being intervention if an > atomic update fails internally. > Even more, I would let all possible operation to fail after a timeout fires: > - Ignite compute computations (covered by IGNITE-6940). > - Ignite services calls. > - Atomic cache updates (see devlist discussion - > [http://apache-ignite-developers.2346864.n4.nabble.com/Timeouts-in-atomic-cache-td19839.html]). > - Transactional cache updates (covered by IGNITE-6894 and IGNITE-6895). > - SQL queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11008) JDBC Metadata: redundant spaces IS_GENERATEDCOLUMN & BUFFER_LENGTH
[ https://issues.apache.org/jira/browse/IGNITE-11008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936681#comment-16936681 ] Maxim Muzafarov commented on IGNITE-11008: -- [~kcheng.mvp] Why not? Can you ask a `jira-user` right on dev-list? > JDBC Metadata: redundant spaces IS_GENERATEDCOLUMN & BUFFER_LENGTH > -- > > Key: IGNITE-11008 > URL: https://issues.apache.org/jira/browse/IGNITE-11008 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: kcheng.mvp >Priority: Minor > Fix For: 2.8 > > > Found redundant spaces in > org.apache.ignite.internal.jdbc.thin.JdbcThinDatabaseMetadata#getColumns > "IS_GENERATEDCOLUMN " > "BUFFER_LENGTH " -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12206) Partition state validation warns are not printed to log
[
https://issues.apache.org/jira/browse/IGNITE-12206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936588#comment-16936588
]
Ignite TC Bot commented on IGNITE-12206:
{panel:title=Branch: [pull/6888/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4617294buildTypeId=IgniteTests24Java8_RunAll]
> Partition state validation warns are not printed to log
> ---
>
> Key: IGNITE-12206
> URL: https://issues.apache.org/jira/browse/IGNITE-12206
> Project: Ignite
> Issue Type: Bug
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> GridDhtPartitionsExchangeFuture.java
>
> {code:java}
> if (grpCtx == null
> || grpCtx.config().isReadThrough()
> || grpCtx.config().isWriteThrough()
> || grpCtx.config().getCacheStoreFactory() != null
> || grpCtx.config().getRebalanceDelay() == -1
> || grpCtx.config().getRebalanceMode() ==
> CacheRebalanceMode.NONE
> || grpCtx.config().getExpiryPolicyFactory() == null
> || SKIP_PARTITION_SIZE_VALIDATION)
> return null;{code}
>
> Looks like a typo, probably it should be
> grpCtx.config().getExpiryPolicyFactory() != null
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11945) [IEP-35] Performance drop on cache stop
[ https://issues.apache.org/jira/browse/IGNITE-11945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11945: - Fix Version/s: 2.8 > [IEP-35] Performance drop on cache stop > --- > > Key: IGNITE-11945 > URL: https://issues.apache.org/jira/browse/IGNITE-11945 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > `MetricRegistry` implementation drop performance on cache stops. > Has to be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11921) [IEP-35] Migrate CacheGroupMetrics
[ https://issues.apache.org/jira/browse/IGNITE-11921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11921: - Fix Version/s: 2.8 > [IEP-35] Migrate CacheGroupMetrics > -- > > Key: IGNITE-11921 > URL: https://issues.apache.org/jira/browse/IGNITE-11921 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `CacheGroupMetricsMXBean` to > the new metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11941) [IEP-35] Rewrite GridLocalMetrics using new framework
[ https://issues.apache.org/jira/browse/IGNITE-11941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11941: - Fix Version/s: 2.8 > [IEP-35] Rewrite GridLocalMetrics using new framework > - > > Key: IGNITE-11941 > URL: https://issues.apache.org/jira/browse/IGNITE-11941 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > 1. GridLocalMetrics should be moved to GridMetricManager > 2. Standard JVM JMX beans should be registered as metrics on startup. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11922) [IEP-35] Migrate ClusterMetricsMxBean
[ https://issues.apache.org/jira/browse/IGNITE-11922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11922: - Fix Version/s: 2.8 > [IEP-35] Migrate ClusterMetricsMxBean > - > > Key: IGNITE-11922 > URL: https://issues.apache.org/jira/browse/IGNITE-11922 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Ivan Fedotov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 4h > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `ClusterMetricsMxBean` to the > new metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11920) [IEP-35] Improve Metric API
[
https://issues.apache.org/jira/browse/IGNITE-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11920:
-
Fix Version/s: 2.8
> [IEP-35] Improve Metric API
> ---
>
> Key: IGNITE-11920
> URL: https://issues.apache.org/jira/browse/IGNITE-11920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> MetricRegistry may be made safer if we explicitly extract a group of metrics
> for some Ignite entity(cache, service, etc.).
> Internally, the registry will stay the same.
> API proposition is:
> {code:java}
> MetricRegistry {
> MetricSet default();
> MetricSet group(String name);
> }
> MetricSet {
> LongCounter counter();
> void registrer(Metric m);
> //other methods.
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11927) [IEP-35] Add ability to enable\disable subset of metrics
[ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11927: - Fix Version/s: 2.8 > [IEP-35] Add ability to enable\disable subset of metrics > > > Key: IGNITE-11927 > URL: https://issues.apache.org/jira/browse/IGNITE-11927 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Andrey Gura >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite should be able to: > * Enable or disable an arbitrary subset of the metrics. User should be able > to do it in runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11923: - Fix Version/s: 2.8 > [IEP-35] Migrate IgniteMXBean > - > > Key: IGNITE-11923 > URL: https://issues.apache.org/jira/browse/IGNITE-11923 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Ivan Fedotov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new > metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11926) [IEP-35] Migrage GridJobMetricsProcessor
[ https://issues.apache.org/jira/browse/IGNITE-11926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11926: - Fix Version/s: 2.8 > [IEP-35] Migrage GridJobMetricsProcessor > > > Key: IGNITE-11926 > URL: https://issues.apache.org/jira/browse/IGNITE-11926 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `GridJobMetricsProcessor` to > the new metric framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12219) Cache operations histogram
[ https://issues.apache.org/jira/browse/IGNITE-12219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12219: - Fix Version/s: 2.8 > Cache operations histogram > -- > > Key: IGNITE-12219 > URL: https://issues.apache.org/jira/browse/IGNITE-12219 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We need to provide cache operations histogram metrics > Next API and its variants should be covered: > * get > * getEntry > * getAll > * put > * remove > * replace > * lock > * invoke > * containsKey -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11912) [IEP-35] Research possibility to optimize MetricRegistry
[ https://issues.apache.org/jira/browse/IGNITE-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11912: - Fix Version/s: 2.8 > [IEP-35] Research possibility to optimize MetricRegistry > > > Key: IGNITE-11912 > URL: https://issues.apache.org/jira/browse/IGNITE-11912 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We should research and benchmark different data structure for a > MetricRegistry implementation. > A basic assumption of `MetricRegistry` usage: > 1. Collection of metrics almost constant during Ignite lifetime. It will be > changed on cache creation(destroy) and other not frequent operations. > 2. Collection of metrics will be read very frequently(each several seconds or > frequently) by configured metric exporters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
[
https://issues.apache.org/jira/browse/IGNITE-12188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12188:
-
Fix Version/s: 2.8
> Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly
> if there is more then one cache in cache group
>
>
> Key: IGNITE-12188
> URL: https://issues.apache.org/jira/browse/IGNITE-12188
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> Initial partitions counter is set to a total number of partitions for cache
> group but decremented each time partition processed for each cache.
> Reproducer:
> {code:java}
> @Test
> public void testIndexRebuildMetrics() throws Exception {
> IgniteEx ignite = startGrid(new IgniteConfiguration()
> .setConsistentId("ignite")
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)))
> .setCacheConfiguration(
> new CacheConfiguration Integer>("c1").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class),
> new CacheConfiguration Integer>("c2").setGroupName("grp").setIndexedTypes(Integer.class,
> Integer.class)
> ));
> ignite.cluster().active(true);
> for (int i = 0; i < 10_000; i++)
> ignite.cache("c1").put(i, i);
> ignite.cluster().active(false);
> File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
> DFLT_STORE_DIR, false);
> U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
> ignite.cluster().active(true);
> doSleep(1_000L);
>
> assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
> >= 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12191) Add support of system view and metric to Visor
[
https://issues.apache.org/jira/browse/IGNITE-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12191:
-
Fix Version/s: 2.8
> Add support of system view and metric to Visor
> --
>
> Key: IGNITE-12191
> URL: https://issues.apache.org/jira/browse/IGNITE-12191
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> After Ignite obtain new {{SystemView}} and {{Metric}} API we should add
> support of it to the Visor.
> User should be able to query and view any system view content or Metric
> Registry values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12184) [IEP-35] Add metrics - status rebuild indexes
[ https://issues.apache.org/jira/browse/IGNITE-12184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12184: - Fix Version/s: 2.8 > [IEP-35] Add metrics - status rebuild indexes > -- > > Key: IGNITE-12184 > URL: https://issues.apache.org/jira/browse/IGNITE-12184 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Brazhnikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We want to see when the node is rebild indexes (index.bin), the result must > be represented as binary logic (1/0). The information must be in JMX, with no > statistics enabled on the caches. > If an occurs error CorruptTreeExeption(H2) is necessary: > 1. Stop the node > 2. Remove index.bin cache or group cache where the error occurred. > 3. Introduce the node in the topology > After automatic start process of rebild of indexes for a cache or a cache of > group where deleted index is started.bin. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12185) [IEP-35] Add metrics - how many indexes are left to rebuild
[ https://issues.apache.org/jira/browse/IGNITE-12185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12185: - Fix Version/s: 2.8 > [IEP-35] Add metrics - how many indexes are left to rebuild > --- > > Key: IGNITE-12185 > URL: https://issues.apache.org/jira/browse/IGNITE-12185 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Brazhnikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We want to know how many indexes are left to rebuild at the moment. The > result must be an integer. The information must be in JMX, with no statistics > enabled on the caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12085) ThreadPool metrics register after all components start
[
https://issues.apache.org/jira/browse/IGNITE-12085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12085:
-
Fix Version/s: 2.8
> ThreadPool metrics register after all components start
> --
>
> Key: IGNITE-12085
> URL: https://issues.apache.org/jira/browse/IGNITE-12085
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> For now, thread pool metrics register after all {{GridComponent}} starts.
> But there are specific scenarios when some component blocks {{onKernalStart}}
> execution for a long time. {{GridCacheProcessor}} can be taken as an example.
> This leads to the situation when some metric info is lost.
> Seems, we can register thread pool metrics right after only **required**
> components are started and don't wait for all components.
> {code:java}
> // Callbacks.
> for (GridComponent comp : ctx) {
> comp.onKernalStart(active);
> }
> // Start plugins.
> for (PluginProvider provider : ctx.plugins().allProviders())
> provider.onIgniteStart();
> ctx.metric().registerThreadPools(utilityCachePool, execSvc,
> svcExecSvc, sysExecSvc, stripedExecSvc,
> p2pExecSvc, mgmtExecSvc, igfsExecSvc, dataStreamExecSvc,
> restExecSvc, affExecSvc, idxExecSvc,
> callbackExecSvc, qryExecSvc, schemaExecSvc, rebalanceExecSvc,
> rebalanceStripedExecSvc, customExecSvcs);
> // Register MBeans.
> mBeansMgr.registerAllMBeans(utilityCachePool, execSvc,
> svcExecSvc, sysExecSvc, stripedExecSvc, p2pExecSvc,
> mgmtExecSvc, igfsExecSvc, dataStreamExecSvc, restExecSvc,
> affExecSvc, idxExecSvc, callbackExecSvc,
> qryExecSvc, schemaExecSvc, rebalanceExecSvc,
> rebalanceStripedExecSvc, customExecSvcs, ctx.workersRegistry());
> {code}
> {code:java}
> public class GridCacheProcessor {
> @Override public void onKernalStart(boolean active) throws
> IgniteCheckedException {
> //.
> final List syncFuts = new
> ArrayList<>(caches.size());
> sharedCtx.forAllCaches(new CIX1() {
> @Override public void applyx(GridCacheContext cctx) {
> CacheConfiguration cfg = cctx.config();
> if (cctx.affinityNode() &&
> cfg.getRebalanceMode() == SYNC &&
> startTopVer.equals(cctx.startTopologyVersion())) {
> CacheMode cacheMode = cfg.getCacheMode();
> if (cacheMode == REPLICATED || (cacheMode == PARTITIONED
> && cfg.getRebalanceDelay() >= 0))
> // Need to wait outside to avoid a deadlock
> syncFuts.add(cctx.preloader().syncFuture());
> }
> }
> });
> for (int i = 0, size = syncFuts.size(); i < size; i++)
> syncFuts.get(i).get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12183) Rebalancing process metrics for cache groups
[
https://issues.apache.org/jira/browse/IGNITE-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12183:
-
Fix Version/s: 2.8
> Rebalancing process metrics for cache groups
>
>
> Key: IGNITE-12183
> URL: https://issues.apache.org/jira/browse/IGNITE-12183
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Brazhnikov
>Assignee: Surkov Aleksandr
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> h3. Intro
> Currently, some of the Apache Ignite rebalance process metrics are not
> working well enough. For instance, `EstimatedRebalancingKeys` keys time to
> time returns `-1` value due to a bug, or `rebalanceKeysReceived` metric
> treated as CacheMetric in fact calculated for the whole cache group (e.g.
> historical rebalance, see IGNITE-11330 and code block comment below).
> All the rebalance process metrics must be re-worked.
> {code:java}
> /**
> * Update rebalancing metrics.
> */
> private void updateGroupMetrics() {
> // TODO: IGNITE-11330: Update metrics for touched cache only.
> // Due to historical rebalancing "EstimatedRebalancingKeys" metric is
> currently calculated for the whole cache
> // group (by partition counters), so "RebalancedKeys" and
> "RebalancingKeysRate" is calculated in the same way.
> for (GridCacheContext cctx0 : grp.caches()) {
> if (cctx0.statisticsEnabled())
> cctx0.cache().metrics0().onRebalanceKeyReceived();
> }
> }
> {code}
> h3. What we have
> _CacheMetrics_ - statistics must be enabled to see these metrics.
> * getRebalancedKeys
> * getKeysToRebalanceLeft
> * getEstimatedRebalancingKeys
> * getEstimatedRebalancingFinishTime
> * getRebalancingStartTime
> * getRebalanceClearingPartitionsLeft
> * getRebalancingKeysRate
> * getRebalancingBytesRate
> h3. What to do
> All such metrics (or their analogue) must be available for the
> _CacheGroupMetrics_. I'd suggest to do the following:
> # Phase-1
> #* rebalancingPartitionsLeft long metric
> #* rebalancingReceivedKeys long metric
> #* rebalancingReceivedBytes long metric
> #* rebalancingStartTime long metric
> #* rebalancingFinishTime long metric
> # Phase-2
> #* rebalancingExpectedKeys long metric
> #* rebalancingExpectedBytes long metric
> #* rebalancingEvictedPartitionsLeft long metric
> # Phase-3 (statistics must be enabled)
> #* rebalancingKeysRate HitRate metric
> #* rebalancingBytesRate HitRate metric
> # Phase-4
> #* Mark rebalancing _CacheMetrics_ deprecated and remove from metrics
> framework IGNITE-11961.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11960) Throw on attemp to create existing metric
[ https://issues.apache.org/jira/browse/IGNITE-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11960: - Fix Version/s: 2.8 > Throw on attemp to create existing metric > - > > Key: IGNITE-11960 > URL: https://issues.apache.org/jira/browse/IGNITE-11960 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > Currently, `MetricRegistry` returns an existing metric instance on a second > creation attempt. > We should add assert and throw in such cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11981) [IEP-35] Create MU shortcut instead of static import of MetricUtils
[
https://issues.apache.org/jira/browse/IGNITE-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11981:
-
Fix Version/s: 2.8
> [IEP-35] Create MU shortcut instead of static import of MetricUtils
> ---
>
> Key: IGNITE-11981
> URL: https://issues.apache.org/jira/browse/IGNITE-11981
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
>
> More Ignite-way of coding is the usage of short cut classes.
> We should use MU instead of static import of {{MetricUtils}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11987) [IEP-35] Add ability to configure metrics
[ https://issues.apache.org/jira/browse/IGNITE-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11987: - Fix Version/s: 2.8 > [IEP-35] Add ability to configure metrics > - > > Key: IGNITE-11987 > URL: https://issues.apache.org/jira/browse/IGNITE-11987 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Ignite should be able to: > * Configure Histogram metrics > * Configure HitRate metrics. > We should provide 2 ways to configure metric: > 1. -Configuration file.- Discussed on dev-list. Agreed to go with the > simplest solution - JMX method. > 2. JMX method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12211) Client connections system view
[ https://issues.apache.org/jira/browse/IGNITE-12211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12211: - Fix Version/s: 2.8 > Client connections system view > -- > > Key: IGNITE-12211 > URL: https://issues.apache.org/jira/browse/IGNITE-12211 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add client connections to the system views. > System view should track JDBC, ODBC and thin connections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12212) Nodes system view
[ https://issues.apache.org/jira/browse/IGNITE-12212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12212: - Fix Version/s: 2.8 > Nodes system view > - > > Key: IGNITE-12212 > URL: https://issues.apache.org/jira/browse/IGNITE-12212 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > IGNITE-12145 finished > We should add nodes system views. > System view should track current topology nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12221) Javadoc generation fail
[
https://issues.apache.org/jira/browse/IGNITE-12221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12221:
-
Fix Version/s: 2.8
> Javadoc generation fail
> ---
>
> Key: IGNITE-12221
> URL: https://issues.apache.org/jira/browse/IGNITE-12221
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8
>
>
> javadoc generation command fails
> {code}
>
> System view SPI
>
> org.apache.ignite.spi.systemview*
>
> {code}
> should be added to the parent pom.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12214) Continuous query system view
[ https://issues.apache.org/jira/browse/IGNITE-12214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12214: - Fix Version/s: 2.8 > Continuous query system view > > > Key: IGNITE-12214 > URL: https://issues.apache.org/jira/browse/IGNITE-12214 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > IGNITE-12145 finished > We should add continuous query system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12213) Sql objects system views
[ https://issues.apache.org/jira/browse/IGNITE-12213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12213: - Fix Version/s: 2.8 > Sql objects system views > > > Key: IGNITE-12213 > URL: https://issues.apache.org/jira/browse/IGNITE-12213 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > IGNITE-12145 finished > We should add SQL objects system views. > * Schemas > * Tables > * Indexes > * SQL queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12224) SQL query system view
Nikolay Izhikov created IGNITE-12224: Summary: SQL query system view Key: IGNITE-12224 URL: https://issues.apache.org/jira/browse/IGNITE-12224 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov We need to add system view for a SQL queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12224) SQL query system view
[ https://issues.apache.org/jira/browse/IGNITE-12224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12224: - Labels: IEP-35 (was: ) > SQL query system view > - > > Key: IGNITE-12224 > URL: https://issues.apache.org/jira/browse/IGNITE-12224 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > We need to add system view for a SQL queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12224) SQL query system view
[ https://issues.apache.org/jira/browse/IGNITE-12224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12224: - Fix Version/s: 2.8 > SQL query system view > - > > Key: IGNITE-12224 > URL: https://issues.apache.org/jira/browse/IGNITE-12224 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We need to add system view for a SQL queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12223) Text query, scan query system view
[ https://issues.apache.org/jira/browse/IGNITE-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12223: - Labels: IEP-35 (was: ) > Text query, scan query system view > -- > > Key: IGNITE-12223 > URL: https://issues.apache.org/jira/browse/IGNITE-12223 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > We need to add a system views for > * Scan queries > * Text queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11905) [IEP-35] Monitoring Phase 2
[ https://issues.apache.org/jira/browse/IGNITE-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11905: - Fix Version/s: 2.8 > [IEP-35] Monitoring Phase 2 > -- > > Key: IGNITE-11905 > URL: https://issues.apache.org/jira/browse/IGNITE-11905 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > Phase 2 should introduce: > Ability to collect lists of some internal object Ignite manage. > Examples of such objects: > * Caches > * Queries (including continuous queries) > * Services > * Compute tasks > * Distributed Data Structures > * etc... > 1. Fields for each list should be discussed in separate tickets > 2. Metric Exporters (optionally) can support list export. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12223) Create text query, scan query system view
Nikolay Izhikov created IGNITE-12223: Summary: Create text query, scan query system view Key: IGNITE-12223 URL: https://issues.apache.org/jira/browse/IGNITE-12223 Project: Ignite Issue Type: Sub-task Affects Versions: 2.7.6 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.8 We need to add a system views for * Scan queries * Text queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12223) Text query, scan query system view
[ https://issues.apache.org/jira/browse/IGNITE-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12223: - Summary: Text query, scan query system view (was: Create text query, scan query system view) > Text query, scan query system view > -- > > Key: IGNITE-12223 > URL: https://issues.apache.org/jira/browse/IGNITE-12223 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Fix For: 2.8 > > > We need to add a system views for > * Scan queries > * Text queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lev Agafonov updated IGNITE-11312: -- Fix Version/s: 2.8 > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Suraj Singh >Priority: Major > Labels: newbie > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936453#comment-16936453 ] Lev Agafonov commented on IGNITE-11312: --- Hello, Igniters! I investigated the issue and prepared PR. Could you please assign this ticket on me? > JDBC: Thin driver doesn't reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Suraj Singh >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
