[jira] [Updated] (IGNITE-6657) API report for Ignite Core since 1.7.0
[ https://issues.apache.org/jira/browse/IGNITE-6657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Ponomarenko updated IGNITE-6657: --- Attachment: ignite-core-2.png ignite-core-1.png > API report for Ignite Core since 1.7.0 > -- > > Key: IGNITE-6657 > URL: https://issues.apache.org/jira/browse/IGNITE-6657 > Project: Ignite > Issue Type: Test > Security Level: Public(Viewable by anyone) >Reporter: Andrey Ponomarenko > Attachments: ignite-core-1.png, ignite-core-2.png > > > Hi, > I'd like to share report on API changes and backward binary compatibility for > the Ignite Core library: > https://abi-laboratory.pro/java/tracker/timeline/ignite-core/ > The report is generated by the https://github.com/lvc/japi-tracker tool for > jars found at http://central.maven.org/maven2/org/apache/ignite/ignite-core/ > according to the article https://wiki.eclipse.org/Evolving_Java-based_APIs_2. > The tool checks all public API methods and classes by default. Please let me > know if it should not check some parts of the API (private, undocumented, > etc.). > Thank you. > !ignite-core-2.png|API symbols timeline! > !ignite-core-1.png|API changes review! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6657) API report for Ignite Core since 1.7.0
Andrey Ponomarenko created IGNITE-6657: -- Summary: API report for Ignite Core since 1.7.0 Key: IGNITE-6657 URL: https://issues.apache.org/jira/browse/IGNITE-6657 Project: Ignite Issue Type: Test Security Level: Public (Viewable by anyone) Reporter: Andrey Ponomarenko Hi, I'd like to share report on API changes and backward binary compatibility for the Ignite Core library: https://abi-laboratory.pro/java/tracker/timeline/ignite-core/ The report is generated by the https://github.com/lvc/japi-tracker tool for jars found at http://central.maven.org/maven2/org/apache/ignite/ignite-core/ according to the article https://wiki.eclipse.org/Evolving_Java-based_APIs_2. The tool checks all public API methods and classes by default. Please let me know if it should not check some parts of the API (private, undocumented, etc.). Thank you. !ignite-core-2.png|API symbols timeline! !ignite-core-1.png|API changes review! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5909) Web console: Implement editable list
[ https://issues.apache.org/jira/browse/IGNITE-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-5909: Assignee: Andrey Novikov (was: Dmitriy Shabalin) [~anovikov] added new component, pls review it > Web console: Implement editable list > > > Key: IGNITE-5909 > URL: https://issues.apache.org/jira/browse/IGNITE-5909 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Andrey Novikov > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6647) Web Console: Implement schema migration
[ https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208748#comment-16208748 ] Andrey Novikov commented on IGNITE-6647: Reviewed. Added minor changes, please test and merge. > Web Console: Implement schema migration > --- > > Key: IGNITE-6647 > URL: https://issues.apache.org/jira/browse/IGNITE-6647 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.4 > > > We need to support schema updates for Web Console new versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration
[ https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-6647: -- Assignee: Alexey Kuznetsov (was: Andrey Novikov) > Web Console: Implement schema migration > --- > > Key: IGNITE-6647 > URL: https://issues.apache.org/jira/browse/IGNITE-6647 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > We need to support schema updates for Web Console new versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6030) Allow enabling persistence per-cache
[ https://issues.apache.org/jira/browse/IGNITE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-6030: --- Description: Also, when cache native persistence is disabled, we need to make sure that different {{CacheStores}} can be configured on per-cache basis. New storage configuration design draft: {noformat} DataStorageConfiguration // memory configuration getConcurrencyLevel getDefaultDataRegionConfiguration getDataRegionConfigurations getPageSize getSystemRegionInitialSize getSystemRegionMaxSize // persistence coniguration getCheckpointFrequency getCheckpointPageBufferSize getCheckpointThreads getCheckpointWriteOrder getFileIOFactory getLockWaitTime getStoragePath // storage for index and partition files getMetricsRateTimeInterval getMetricsSubIntervalCount getWalTlbSize getWalArchivePath // archived WAL segments getWalAutoArchiveAfterInactivity getWalFlushFrequency getWalFsyncDelayNanos getWalHistorySize getWalMode getWalRecordIteratorBufferSize getWalSegments getWalSegmentSize getWalPath // working set of WAL segments isAlwaysWriteFullPages isMetricsEnabled isWriteThrottlingEnabled DataRegionConfiguration // memory policy configuration isPersistenceEnabled (default = false) getEmptyPagesPoolSize getEvictionThreshold getInitialSize getMaxSize getName getPageEvictionMode getMetricsRateTimeInterval getMetricsSubIntervalCount getSwapPath isMetricsEnabled {noformat} New metrics and MBean classes: {noformat} PersistenceMetrics -> DataStorageMetrics PersistenceMetricsMXBean -> DataStorageMetricsMXBean MemoryMetrics -> DataRegionMetrics MemoryMetricsMXBean -> DataRegionMetricsMXBean {noformat} Please note that old versions of all classes and methods are retained in codebase as deprecated. was: Also, when cache native persistence is disabled, we need to make sure that different {{CacheStores}} can be configured on per-cache basis. New storage configuration design draft: {noformat} DataStorageConfiguration // memory configuration getConcurrencyLevel getDefaultDataRegionConfiguration getDataRegionConfigurations getPageSize getSystemRegionInitialSize getSystemRegionMaxSize // persistence coniguration getCheckpointingFrequency getCheckpointingPageBufferSize getCheckpointingThreads getCheckpointWriteOrder getFileIOFactory getLockWaitTime getStoragePath // storage for index and partition files getMetricsRateTimeInterval getMetricsSubIntervalCount getWalTlbSize getWalArchivePath // archived WAL segments getWalAutoArchiveAfterInactivity getWalFlushFrequency getWalFsyncDelayNanos getWalHistorySize getWalMode getWalRecordIteratorBufferSize getWalSegments getWalSegmentSize getWalPath // working set of WAL segments isAlwaysWriteFullPages isMetricsEnabled isWriteThrottlingEnabled DataRegionConfiguration // memory policy configuration isPersistenceEnabled (default = false) getEmptyPagesPoolSize getEvictionThreshold getInitialSize getMaxSize getName getPageEvictionMode getMetricsRateTimeInterval getMetricsSubIntervalCount getSwapPath isMetricsEnabled {noformat} New metrics and MBean classes: {noformat} PersistenceMetrics -> DataStorageMetrics PersistenceMetricsMXBean -> DataStorageMetricsMXBean MemoryMetrics -> DataRegionMetrics MemoryMetricsMXBean -> DataRegionMetricsMXBean {noformat} Please note that old versions of all classes and methods are retained in codebase as deprecated. > Allow enabling persistence per-cache > > > Key: IGNITE-6030 > URL: https://issues.apache.org/jira/browse/IGNITE-6030 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Ivan Rakov >Priority: Critical > Labels: important > Fix For: 2.3 > > > Also, when cache native persistence is disabled, we need to make sure that > different {{CacheStores}} can be configured on per-cache basis. > New storage configuration design draft: > {noformat} > DataStorageConfiguration > // memory configuration > getConcurrencyLevel > getDefaultDataRegionConfiguration > getDataRegionConfigurations > getPageSize >
[jira] [Updated] (IGNITE-6030) Allow enabling persistence per-cache
[ https://issues.apache.org/jira/browse/IGNITE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-6030: --- Description: Also, when cache native persistence is disabled, we need to make sure that different {{CacheStores}} can be configured on per-cache basis. New storage configuration design draft: {noformat} DataStorageConfiguration // memory configuration getConcurrencyLevel getDefaultDataRegionConfiguration getDataRegionConfigurations getPageSize getSystemRegionInitialSize getSystemRegionMaxSize // persistence coniguration getCheckpointingFrequency getCheckpointingPageBufferSize getCheckpointingThreads getCheckpointWriteOrder getFileIOFactory getLockWaitTime getStoragePath // storage for index and partition files getMetricsRateTimeInterval getMetricsSubIntervalCount getWalTlbSize getWalArchivePath // archived WAL segments getWalAutoArchiveAfterInactivity getWalFlushFrequency getWalFsyncDelayNanos getWalHistorySize getWalMode getWalRecordIteratorBufferSize getWalSegments getWalSegmentSize getWalPath // working set of WAL segments isAlwaysWriteFullPages isMetricsEnabled isWriteThrottlingEnabled DataRegionConfiguration // memory policy configuration isPersistenceEnabled (default = false) getEmptyPagesPoolSize getEvictionThreshold getInitialSize getMaxSize getName getPageEvictionMode getMetricsRateTimeInterval getMetricsSubIntervalCount getSwapPath isMetricsEnabled {noformat} New metrics and MBean classes: {noformat} PersistenceMetrics -> DataStorageMetrics PersistenceMetricsMXBean -> DataStorageMetricsMXBean MemoryMetrics -> DataRegionMetrics MemoryMetricsMXBean -> DataRegionMetricsMXBean {noformat} Please note that old versions of all classes and methods are retained in codebase as deprecated. was: Also, when cache native persistence is disabled, we need to make sure that different {{CacheStores}} can be configured on per-cache basis. New storage configuration design draft: {noformat} DataStorageConfiguration // memory configuration getConcurrencyLevel getDefaultDataRegionConfiguration getDataRegionConfigurations getPageSize getSystemRegionInitialSize getSystemRegionMaxSize // persistence coniguration getCheckpointingFrequency getCheckpointingPageBufferSize getCheckpointingThreads getCheckpointWriteOrder getFileIOFactory getLockWaitTime getStoragePath // storage for index and partition files getMetricsRateTimeInterval getMetricsSubIntervalCount getWalTlbSize getWalArchivePath // archived WAL segments getWalAutoArchiveAfterInactivity getWalFlushFrequency getWalFsyncDelayNanos getWalHistorySize getWalMode getWalRecordIteratorBufferSize getWalSegments getWalSegmentSize getWalPath // working set of WAL segments isAlwaysWriteFullPages isMetricsEnabled isWriteThrottlingEnabled DataRegionConfiguration // memory policy configuration isPersistenceEnabled (default = false) getEmptyPagesPoolSize getEvictionThreshold getInitialSize getMaxSize getName getPageEvictionMode getMetricsRateTimeInterval getMetricsSubIntervalCount getSwapFilePath isMetricsEnabled {noformat} New metrics and MBean classes: {noformat} PersistenceMetrics -> DataStorageMetrics PersistenceMetricsMXBean -> DataStorageMetricsMXBean MemoryMetrics -> DataRegionMetrics MemoryMetricsMXBean -> DataRegionMetricsMXBean {noformat} Please note that old versions of all classes and methods are retained in codebase as deprecated. > Allow enabling persistence per-cache > > > Key: IGNITE-6030 > URL: https://issues.apache.org/jira/browse/IGNITE-6030 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Ivan Rakov >Priority: Critical > Labels: important > Fix For: 2.3 > > > Also, when cache native persistence is disabled, we need to make sure that > different {{CacheStores}} can be configured on per-cache basis. > New storage configuration design draft: > {noformat} > DataStorageConfiguration > // memory configuration > getConcurrencyLevel > getDefaultDataRegionConfiguration > getDataRegionConfigurations >
[jira] [Closed] (IGNITE-6608) .NET: Thin client documentation
[ https://issues.apache.org/jira/browse/IGNITE-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-6608. --- > .NET: Thin client documentation > --- > > Key: IGNITE-6608 > URL: https://issues.apache.org/jira/browse/IGNITE-6608 > Project: Ignite > Issue Type: Task > Components: documentation, platforms, thin client >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Assignee: Prachi Garg > Labels: .NET > Fix For: 2.3 > > > Document new Thin Client API on readme.io: > https://apacheignite-net.readme.io/docs -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names
[ https://issues.apache.org/jira/browse/IGNITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208155#comment-16208155 ] Dmitriy Setrakyan commented on IGNITE-6111: --- Is there any update on this ticket? Would be nice to support this feature in 2.4. > SQL: Add ability to do INSERT without specifying the column names > - > > Key: IGNITE-6111 > URL: https://issues.apache.org/jira/browse/IGNITE-6111 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Alexandr Fedotov >Assignee: Sergey Kalashnikov > Labels: sql, usability > Fix For: 2.4 > > > Having the following classes > {code:java} > class PersonKey { > private Long id; > } > class Person { > private Long id; > private String name; > } > {code} > with proper configuration it should be possible to execute queries > of the following type passing {{id}} and {{name}} as the arguments > {code:sql}"insert into Person values(?,?)"{code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6656) SQLLine Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6656: Fix Version/s: 2.3 > SQLLine Documentation > - > > Key: IGNITE-6656 > URL: https://issues.apache.org/jira/browse/IGNITE-6656 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Blocker > Labels: docuentation > Fix For: 2.3 > > > SQLLine is officially used as a default command line tool for SQL > connectivity in Ignite. Document the tool usage on a dedicated page: > https://apacheignite-sql.readme.io/docs/sqlline > Consider the following sections: > # The tool overview with a list of commands that are supported and not by > Ignite. The current list is here [1]. Split the list into 2 parts on > readme.io (supported and not) and briefly describe eache command. > # Connectivity section. Start a cluster and connect to the tool using > {{./ignitesql.sh --color=true --verbose=true -u > jdbc:ignite:thin://127.0.0.1/}} script. Add a tab for ignite.bat file as well. > # Usage section. Execute DDL and DML commands taken from the getting started > as it's done here [2]. When tables and indexes are created, run {{!metadata}} > to show the structure. > Use private 2.3 builds generated by TC to make sure the doc is ready for the > release. > [1] https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool > [2] https://apacheignite-sql.readme.io/v2.1/docs/sql-tooling -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6656) SQLLine Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6656: Labels: docuentation (was: ) > SQLLine Documentation > - > > Key: IGNITE-6656 > URL: https://issues.apache.org/jira/browse/IGNITE-6656 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Blocker > Labels: docuentation > Fix For: 2.3 > > > SQLLine is officially used as a default command line tool for SQL > connectivity in Ignite. Document the tool usage on a dedicated page: > https://apacheignite-sql.readme.io/docs/sqlline > Consider the following sections: > # The tool overview with a list of commands that are supported and not by > Ignite. The current list is here [1]. Split the list into 2 parts on > readme.io (supported and not) and briefly describe eache command. > # Connectivity section. Start a cluster and connect to the tool using > {{./ignitesql.sh --color=true --verbose=true -u > jdbc:ignite:thin://127.0.0.1/}} script. Add a tab for ignite.bat file as well. > # Usage section. Execute DDL and DML commands taken from the getting started > as it's done here [2]. When tables and indexes are created, run {{!metadata}} > to show the structure. > Use private 2.3 builds generated by TC to make sure the doc is ready for the > release. > [1] https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool > [2] https://apacheignite-sql.readme.io/v2.1/docs/sql-tooling -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6656) SQLLine Documentation
Denis Magda created IGNITE-6656: --- Summary: SQLLine Documentation Key: IGNITE-6656 URL: https://issues.apache.org/jira/browse/IGNITE-6656 Project: Ignite Issue Type: Task Security Level: Public (Viewable by anyone) Reporter: Denis Magda Assignee: Prachi Garg Priority: Blocker SQLLine is officially used as a default command line tool for SQL connectivity in Ignite. Document the tool usage on a dedicated page: https://apacheignite-sql.readme.io/docs/sqlline Consider the following sections: # The tool overview with a list of commands that are supported and not by Ignite. The current list is here [1]. Split the list into 2 parts on readme.io (supported and not) and briefly describe eache command. # Connectivity section. Start a cluster and connect to the tool using {{./ignitesql.sh --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1/}} script. Add a tab for ignite.bat file as well. # Usage section. Execute DDL and DML commands taken from the getting started as it's done here [2]. When tables and indexes are created, run {{!metadata}} to show the structure. Use private 2.3 builds generated by TC to make sure the doc is ready for the release. [1] https://cwiki.apache.org/confluence/display/IGNITE/Overview+sqlline+tool [2] https://apacheignite-sql.readme.io/v2.1/docs/sql-tooling -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-6649: - Attachment: EvictionPolicyTest.java > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Fix For: 2.4 > > Attachments: EvictionPolicyTest.java > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6638) Add an ability for auto activate BLT
[ https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin closed IGNITE-6638. -- > Add an ability for auto activate BLT > > > Key: IGNITE-6638 > URL: https://issues.apache.org/jira/browse/IGNITE-6638 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.2 >Reporter: Sergey Puchnin > Fix For: 2.4 > > > For further improvement BLT it'd be great to add auto activation > functionality. It allow to reduce stuff intervention. > Next subtasks should be solved: > * To change the metasrore format. Choose a format to store a node list (whole > node list, only id+hash, etc) > * Add a BLT management to WebConsole > * Add a BLT management to CLI > * Save affinity function attributes to metastore > * Check equality configuration between metasore and XML. Reject to start a > cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6638) Add an ability for auto activate BLT
[ https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin resolved IGNITE-6638. Resolution: Duplicate looks like a duplicate for https://issues.apache.org/jira/browse/IGNITE-5851 > Add an ability for auto activate BLT > > > Key: IGNITE-6638 > URL: https://issues.apache.org/jira/browse/IGNITE-6638 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.2 >Reporter: Sergey Puchnin > Fix For: 2.4 > > > For further improvement BLT it'd be great to add auto activation > functionality. It allow to reduce stuff intervention. > Next subtasks should be solved: > * To change the metasrore format. Choose a format to store a node list (whole > node list, only id+hash, etc) > * Add a BLT management to WebConsole > * Add a BLT management to CLI > * Save affinity function attributes to metastore > * Check equality configuration between metasore and XML. Reject to start a > cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT
[ https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6638: --- Labels: (was: IEP-4) > Add an ability for auto activate BLT > > > Key: IGNITE-6638 > URL: https://issues.apache.org/jira/browse/IGNITE-6638 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.2 >Reporter: Sergey Puchnin >Assignee: Dmitriy Pavlov > Fix For: 2.4 > > > For further improvement BLT it'd be great to add auto activation > functionality. It allow to reduce stuff intervention. > Next subtasks should be solved: > * To change the metasrore format. Choose a format to store a node list (whole > node list, only id+hash, etc) > * Add a BLT management to WebConsole > * Add a BLT management to CLI > * Save affinity function attributes to metastore > * Check equality configuration between metasore and XML. Reject to start a > cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6638) Add an ability for auto activate BLT
[ https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin reassigned IGNITE-6638: -- Assignee: (was: Dmitriy Pavlov) > Add an ability for auto activate BLT > > > Key: IGNITE-6638 > URL: https://issues.apache.org/jira/browse/IGNITE-6638 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.2 >Reporter: Sergey Puchnin > Fix For: 2.4 > > > For further improvement BLT it'd be great to add auto activation > functionality. It allow to reduce stuff intervention. > Next subtasks should be solved: > * To change the metasrore format. Choose a format to store a node list (whole > node list, only id+hash, etc) > * Add a BLT management to WebConsole > * Add a BLT management to CLI > * Save affinity function attributes to metastore > * Check equality configuration between metasore and XML. Reject to start a > cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6655) gracefully handle AmazonS3Exception: Slow Down in TcpDiscoveryS3IpFinder
Konstantin Dudkov created IGNITE-6655: - Summary: gracefully handle AmazonS3Exception: Slow Down in TcpDiscoveryS3IpFinder Key: IGNITE-6655 URL: https://issues.apache.org/jira/browse/IGNITE-6655 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Affects Versions: 2.1 Reporter: Konstantin Dudkov Assignee: Konstantin Dudkov for now if we got "AmazonS3Exception: Slow Down" in TcpDiscoveryS3IpFinder node stops we should handle this situation with some kind of backoff algorithm -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207817#comment-16207817 ] Eduard Shangareev commented on IGNITE-5852: --- Now there is the bug - if we are already active, we will call callbacks for activation in any case. It causes to 2, 3 ... Checkpointers per node. > Cache affinity should be calculated wrt baseline topology > - > > Key: IGNITE-5852 > URL: https://issues.apache.org/jira/browse/IGNITE-5852 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh > Labels: IEP-4 > Fix For: 2.4 > > > After we have an API for baseline topology management, we need to provide a > way to operate when real topology differs from the baseline. To facilitate > this, we need to calculate the affinity on the set of nodes which is an > intersection of the baseline topology and current topology -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-5852: Assignee: Ilya Lantukh (was: Alexey Goncharuk) > Cache affinity should be calculated wrt baseline topology > - > > Key: IGNITE-5852 > URL: https://issues.apache.org/jira/browse/IGNITE-5852 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh > Labels: IEP-4 > Fix For: 2.4 > > > After we have an API for baseline topology management, we need to provide a > way to operate when real topology differs from the baseline. To facilitate > this, we need to calculate the affinity on the set of nodes which is an > intersection of the baseline topology and current topology -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6653) Check equality configuration between metasore and XML
[ https://issues.apache.org/jira/browse/IGNITE-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6653: --- Description: To introduce another point of configuration validation between cluster (XML, java code) and metasore. Provide detailed information and decline to start cluster if different was:As another point of validation need to avoid join old version nodes > Check equality configuration between metasore and XML > - > > Key: IGNITE-6653 > URL: https://issues.apache.org/jira/browse/IGNITE-6653 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Sergey Puchnin > Labels: IEP-4 > > To introduce another point of configuration validation between cluster (XML, > java code) and metasore. > Provide detailed information and decline to start cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6654) Ignite client can hang in case IgniteOOM on server
Mikhail Cherkasov created IGNITE-6654: - Summary: Ignite client can hang in case IgniteOOM on server Key: IGNITE-6654 URL: https://issues.apache.org/jira/browse/IGNITE-6654 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: cache, general Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Ignite client can hang in case IgniteOOM on server -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6653) Check equality configuration between metasore and XML
Sergey Puchnin created IGNITE-6653: -- Summary: Check equality configuration between metasore and XML Key: IGNITE-6653 URL: https://issues.apache.org/jira/browse/IGNITE-6653 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Sergey Puchnin As another point of validation need to avoid join old version nodes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up
[ https://issues.apache.org/jira/browse/IGNITE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6652: --- Description: As another point of validation need to avoid join old version nodes (was: As an another point of validation ) > Gracefully deny joins of nodes with older version when baseline topology is > set up > -- > > Key: IGNITE-6652 > URL: https://issues.apache.org/jira/browse/IGNITE-6652 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Sergey Puchnin > Labels: IEP-4 > > As another point of validation need to avoid join old version nodes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up
[ https://issues.apache.org/jira/browse/IGNITE-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6652: --- Description: As an another point of validation (was: Baseline should save attributes for AF to metasore) > Gracefully deny joins of nodes with older version when baseline topology is > set up > -- > > Key: IGNITE-6652 > URL: https://issues.apache.org/jira/browse/IGNITE-6652 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Sergey Puchnin > Labels: IEP-4 > > As an another point of validation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6652) Gracefully deny joins of nodes with older version when baseline topology is set up
Sergey Puchnin created IGNITE-6652: -- Summary: Gracefully deny joins of nodes with older version when baseline topology is set up Key: IGNITE-6652 URL: https://issues.apache.org/jira/browse/IGNITE-6652 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Sergey Puchnin Baseline should save attributes for AF to metasore -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6651) Baseline includes attributes required for affinity function
[ https://issues.apache.org/jira/browse/IGNITE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6651: --- Description: Baseline should save attributes for AF to metasore (was: We need to design and implement an effective baseline topology format for metastore so that metastore does not grow too fast.) > Baseline includes attributes required for affinity function > --- > > Key: IGNITE-6651 > URL: https://issues.apache.org/jira/browse/IGNITE-6651 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Sergey Puchnin > Labels: IEP-4 > > Baseline should save attributes for AF to metasore -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6651) Baseline includes only attributes required for affinity function
Sergey Puchnin created IGNITE-6651: -- Summary: Baseline includes only attributes required for affinity function Key: IGNITE-6651 URL: https://issues.apache.org/jira/browse/IGNITE-6651 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Sergey Puchnin We need to design and implement an effective baseline topology format for metastore so that metastore does not grow too fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6651) Baseline includes attributes required for affinity function
[ https://issues.apache.org/jira/browse/IGNITE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6651: --- Summary: Baseline includes attributes required for affinity function (was: Baseline includes only attributes required for affinity function) > Baseline includes attributes required for affinity function > --- > > Key: IGNITE-6651 > URL: https://issues.apache.org/jira/browse/IGNITE-6651 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Sergey Puchnin > Labels: IEP-4 > > We need to design and implement an effective baseline topology format for > metastore so that metastore does not grow too fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5854) Validate baseline topology change history during node joins
[ https://issues.apache.org/jira/browse/IGNITE-5854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-5854: --- Labels: IEP-4 (was: ) > Validate baseline topology change history during node joins > --- > > Key: IGNITE-5854 > URL: https://issues.apache.org/jira/browse/IGNITE-5854 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk > Labels: IEP-4 > Fix For: 2.4 > > > It is possible to have a cluster-split restarts when persistence enabled: > Start 1, 2, 3, 4, update data. Stop > Start 1, 2. Update data. Stop > Start 3, 4. Update data. Stop. > Start 1, 2, 3, 4. Stop > We need to make sure that the second start is not allowed. This can be done > by introducing baseline topology history and topology hash generation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5851) Automatically activate cluster if baseline topology is reached
[ https://issues.apache.org/jira/browse/IGNITE-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-5851: --- Labels: IEP-4 (was: ) > Automatically activate cluster if baseline topology is reached > -- > > Key: IGNITE-5851 > URL: https://issues.apache.org/jira/browse/IGNITE-5851 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk > Labels: IEP-4 > Fix For: 2.4 > > > When we have an API for baseline topology management, we can automatically > activate the cluster once all the nodes from the baseline topology are > started. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5853) Provide a way to determine which user attributes are used in affinity calculation
[ https://issues.apache.org/jira/browse/IGNITE-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-5853: --- Labels: IEP-4 (was: ) > Provide a way to determine which user attributes are used in affinity > calculation > - > > Key: IGNITE-5853 > URL: https://issues.apache.org/jira/browse/IGNITE-5853 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk > Labels: IEP-4 > Fix For: 2.4 > > > Since an affinity function may use user attributes to calculate affinity > distribution, we need to save these attributes to the metastore. However, > storing all the attributes is not very effective, so we need to have a way to > determine which attributes should be stored. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5852) Cache affinity should be calculated wrt baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-5852: --- Labels: IEP-4 (was: ) > Cache affinity should be calculated wrt baseline topology > - > > Key: IGNITE-5852 > URL: https://issues.apache.org/jira/browse/IGNITE-5852 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk > Labels: IEP-4 > Fix For: 2.4 > > > After we have an API for baseline topology management, we need to provide a > way to operate when real topology differs from the baseline. To facilitate > this, we need to calculate the affinity on the set of nodes which is an > intersection of the baseline topology and current topology -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5850) Introduce an API for baseline topology for persistence-enabled clusters
[ https://issues.apache.org/jira/browse/IGNITE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-5850: --- Labels: IEP-4 (was: ) > Introduce an API for baseline topology for persistence-enabled clusters > --- > > Key: IGNITE-5850 > URL: https://issues.apache.org/jira/browse/IGNITE-5850 > Project: Ignite > Issue Type: New Feature > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk > Labels: IEP-4 > Fix For: 2.4 > > > Since the persistence was introduced, we require that cluster be started in > an inactive mode and activation happens only manually. > We need to add a concept of baseline topology which is fixed on the first > cluster activation and may be changed later by a user. We need to develop a > consistent API facade for this purpose. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment
[ https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707 ] Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:30 PM: This is not a bug, this is a [https://issues.apache.org/jira/browse/IGNITE-5846] (not implemented yet) was (Author: zaleslaw): This is not a bug, this is a feature (not implemented yet) > Adapt Linear regression for distributed environment > --- > > Key: IGNITE-6222 > URL: https://issues.apache.org/jira/browse/IGNITE-6222 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev > Fix For: 2.4 > > > Currently our implementation of linear regression works only locally which is > useless. So we need fix this implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment
[ https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707 ] Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:30 PM: This is not a bug, this is a [IGNITE-5846] (not implemented yet) was (Author: zaleslaw): This is not a bug, this is a [https://issues.apache.org/jira/browse/IGNITE-5846] (not implemented yet) > Adapt Linear regression for distributed environment > --- > > Key: IGNITE-6222 > URL: https://issues.apache.org/jira/browse/IGNITE-6222 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev > Fix For: 2.4 > > > Currently our implementation of linear regression works only locally which is > useless. So we need fix this implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6222) Adapt Linear regression for distributed environment
[ https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207707#comment-16207707 ] Aleksey Zinoviev edited comment on IGNITE-6222 at 10/17/17 2:29 PM: This is not a bug, this is a feature (not implemented yet) was (Author: zaleslaw): This is not a bug, this is a feature (not implemented yet) > Adapt Linear regression for distributed environment > --- > > Key: IGNITE-6222 > URL: https://issues.apache.org/jira/browse/IGNITE-6222 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev > Fix For: 2.4 > > > Currently our implementation of linear regression works only locally which is > useless. So we need fix this implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6222) Adapt Linear regression for distributed environment
[ https://issues.apache.org/jira/browse/IGNITE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-6222. -- Resolution: Duplicate This is not a bug, this is a feature (not implemented yet) > Adapt Linear regression for distributed environment > --- > > Key: IGNITE-6222 > URL: https://issues.apache.org/jira/browse/IGNITE-6222 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev > Fix For: 2.4 > > > Currently our implementation of linear regression works only locally which is > useless. So we need fix this implementation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.
[ https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-5195: Assignee: Ilya Lantukh (was: Anton Vinogradov) > DataStreamer can fails if non-data node enter\leave the grid. > - > > Key: IGNITE-5195 > URL: https://issues.apache.org/jira/browse/IGNITE-5195 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Ilya Lantukh > Fix For: 2.4 > > Attachments: DataStreamerFailure.java > > > DataStreamer failed with "too many remaps" message even if non-data node > enter\leave topology. > PFA repro attached. > Seems, we should ignore topology changes when non-data node enter\leave the > grid. > And also we need to sure that remapping doesn't occurs when there is no data > nodes in grid any more, as remapping make no sense and more suitable message > should be logged. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.
[ https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207684#comment-16207684 ] ASF GitHub Bot commented on IGNITE-5195: GitHub user ilantukh opened a pull request: https://github.com/apache/ignite/pull/2872 IGNITE-5195 : DataStreamer remap optimization. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5195 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2872.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2872 commit caa7f7c833a162a01edacb241634515cdce67ec2 Author: Ilya LantukhDate: 2017-10-16T14:56:18Z ignite-5195 : DataStreamer remap optimization. commit 68b13fa248393c8ab75686c2956e84a2c5177839 Author: Ilya Lantukh Date: 2017-10-16T15:03:48Z ignite-5195 : Added test. commit e35b2d6508bd8b96c10d245253e066cdc2839a01 Author: Ilya Lantukh Date: 2017-10-17T13:50:53Z ignite-5195 : Fixed failing tests, simplified solution. > DataStreamer can fails if non-data node enter\leave the grid. > - > > Key: IGNITE-5195 > URL: https://issues.apache.org/jira/browse/IGNITE-5195 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Anton Vinogradov > Fix For: 2.4 > > Attachments: DataStreamerFailure.java > > > DataStreamer failed with "too many remaps" message even if non-data node > enter\leave topology. > PFA repro attached. > Seems, we should ignore topology changes when non-data node enter\leave the > grid. > And also we need to sure that remapping doesn't occurs when there is no data > nodes in grid any more, as remapping make no sense and more suitable message > should be logged. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.
[ https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207683#comment-16207683 ] ASF GitHub Bot commented on IGNITE-5195: Github user ilantukh closed the pull request at: https://github.com/apache/ignite/pull/2862 > DataStreamer can fails if non-data node enter\leave the grid. > - > > Key: IGNITE-5195 > URL: https://issues.apache.org/jira/browse/IGNITE-5195 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Anton Vinogradov > Fix For: 2.4 > > Attachments: DataStreamerFailure.java > > > DataStreamer failed with "too many remaps" message even if non-data node > enter\leave topology. > PFA repro attached. > Seems, we should ignore topology changes when non-data node enter\leave the > grid. > And also we need to sure that remapping doesn't occurs when there is no data > nodes in grid any more, as remapping make no sense and more suitable message > should be logged. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6650) Introduce effective storage format for baseline topology
[ https://issues.apache.org/jira/browse/IGNITE-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6650: --- Labels: IEP-4 (was: ) > Introduce effective storage format for baseline topology > > > Key: IGNITE-6650 > URL: https://issues.apache.org/jira/browse/IGNITE-6650 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.3 >Reporter: Alexey Goncharuk > Labels: IEP-4 > > We need to design and implement an effective baseline topology format for > metastore so that metastore does not grow too fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
[ https://issues.apache.org/jira/browse/IGNITE-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov reassigned IGNITE-5553: Assignee: Andrey Kuznetsov > Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error > - > > Key: IGNITE-5553 > URL: https://issues.apache.org/jira/browse/IGNITE-5553 > Project: Ignite > Issue Type: Bug > Components: data structures, persistence >Affects Versions: 2.1 >Reporter: Dmitriy Pavlov >Assignee: Andrey Kuznetsov >Priority: Critical > Labels: MakeTeamcityGreenAgain, Muted_test, test-fail > > h2. Notes-4435 > When IgniteSet is restored from persistence, size of set is always 0, [link > to test > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails]. > h2. Detailed description > Unlike *IgniteQueue* which uses separate cache key to store its size > *IgniteSet* stores it in a field of some class. > Test from the link above shows very clearly that after restoring memory state > from PDS all set values are restored correctly but size is lost. > h2. Proposed solution > One possible solution might be to do the same thing as *IgniteQueue* does: > size of *IgniteSet* must be stored is cache instead of volatile in-memory > fields of random classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6650) Introduce effective storage format for baseline topology
Alexey Goncharuk created IGNITE-6650: Summary: Introduce effective storage format for baseline topology Key: IGNITE-6650 URL: https://issues.apache.org/jira/browse/IGNITE-6650 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Alexey Goncharuk We need to design and implement an effective baseline topology format for metastore so that metastore does not grow too fast. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5195) DataStreamer can fails if non-data node enter\leave the grid.
[ https://issues.apache.org/jira/browse/IGNITE-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh reassigned IGNITE-5195: Assignee: Anton Vinogradov > DataStreamer can fails if non-data node enter\leave the grid. > - > > Key: IGNITE-5195 > URL: https://issues.apache.org/jira/browse/IGNITE-5195 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 1.8 >Reporter: Andrew Mashenkov >Assignee: Anton Vinogradov > Fix For: 2.4 > > Attachments: DataStreamerFailure.java > > > DataStreamer failed with "too many remaps" message even if non-data node > enter\leave topology. > PFA repro attached. > Seems, we should ignore topology changes when non-data node enter\leave the > grid. > And also we need to sure that remapping doesn't occurs when there is no data > nodes in grid any more, as remapping make no sense and more suitable message > should be logged. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6320) SQL: ANTLR performance assessment
[ https://issues.apache.org/jira/browse/IGNITE-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207666#comment-16207666 ] Sergey Kalashnikov commented on IGNITE-6320: I've made some benchmarking with parsers generated by ANTLR with MySQL and P/L SQL grammars versus H2 prepared statement. Also included the ANTLR based parser prototype I created earlier for . The measurements for ANTLR parsers were made with two stage parsing strategy (SLL prediction mode). Here are the results: ||Benchmark||ops/s|| |Complex Query ANTLR/MySQL Grammar|7830,615| |Complex Query ANTLR/MySQL(Lexer only)|53441,816| |Complex Query ANTLR/PL-SQL Grammar|3310,900| |Complex Query H2|25368,322| |Simple Query ANTLR/MySQL Grammar|28813,159| |Simple Query ANTLR/PL-SQL Grammar|12581,615| |Simple Query H2|118872,767| |Trivial Query ANTLR/MySQL Grammar|120041,528| |Trivial Query ANTLR/PL-SQL Grammar|63138,856| |Trivial Query H2|546905,758| |Drop index ANTLR/MySQL Grammar|350599,019| |Drop index H2|2373889,332| |Drop index ANTLR/IgniteProto|474410,677| |Drop index JFLEX+BYACC/IgniteProto|389347,251| |Batched Queries 1 Thread ANTLR/MySQL|35,256| |Batched Queries 2 Threads ANTLR/MySQL|60,010| |Batched Queries 4 Threads ANTLR/MySQL|95,171| |Batched Queries 8 Threads ANLR/MySQL|135,311| It looks like ANTLR parser doesn't scale well enough in multi-threaded environment, although single thread performance is good. > SQL: ANTLR performance assessment > - > > Key: IGNITE-6320 > URL: https://issues.apache.org/jira/browse/IGNITE-6320 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > > Proposed process: > 1) Download MySQL grammar [1] > 2) Generate parser > 3) Measure parsing performance for both simple and complex SQL queries with > JMH. > 4) Analyze the numbers > [1] https://github.com/antlr/grammars-v4/tree/master/mysql -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6638) Add an ability for auto activate BLT
[ https://issues.apache.org/jira/browse/IGNITE-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Puchnin updated IGNITE-6638: --- Labels: IEP-4 (was: ) > Add an ability for auto activate BLT > > > Key: IGNITE-6638 > URL: https://issues.apache.org/jira/browse/IGNITE-6638 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.2 >Reporter: Sergey Puchnin >Assignee: Dmitriy Pavlov > Labels: IEP-4 > Fix For: 2.4 > > > For further improvement BLT it'd be great to add auto activation > functionality. It allow to reduce stuff intervention. > Next subtasks should be solved: > * To change the metasrore format. Choose a format to store a node list (whole > node list, only id+hash, etc) > * Add a BLT management to WebConsole > * Add a BLT management to CLI > * Save affinity function attributes to metastore > * Check equality configuration between metasore and XML. Reject to start a > cluster if different -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-6649: Assignee: Andrew Mashenkov > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov > Fix For: 2.4 > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-2766) Cache instance is closed when client disconnects
[ https://issues.apache.org/jira/browse/IGNITE-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207599#comment-16207599 ] ASF GitHub Bot commented on IGNITE-2766: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/2870 IGNITE-2766 Deterministically reopen cache after client reconnect. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2766ex Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2870.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2870 commit 843566b74b3afdf78d3ede1a46adc927878c89e2 Author: Ilya KasnacheevDate: 2017-10-17T12:53:05Z IGNITE-2766 Deterministically reopen cache after client reconnect bis. > Cache instance is closed when client disconnects > > > Key: IGNITE-2766 > URL: https://issues.apache.org/jira/browse/IGNITE-2766 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Ilya Kasnacheev > > In case client disconnects and reconnects after network timeout (i.e., with a > new ID), all cache instances acquired by this client are closed and are not > functional. User has to create a special logic to handle this case. > Cache proxy should be able to handle this automatically. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207600#comment-16207600 ] Andrew Mashenkov commented on IGNITE-6649: -- Todo: 1. add eviction policy factory methods to IgniteConfiguration. 2. deprecate setEvictionPolicy method and update javadoc. 3. create a ticket for old method discontinuation in next major release. > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov > Fix For: 2.4 > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-6649: - Summary: Add EvictionPolicy factory support in IgniteConfiguration. (was: Add EvitionPolicy factory support in IgniteConfiguration.) > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov > Fix For: 2.4 > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6649) Add EvitionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-6649: - Description: For now the only way to set EvictionPolicy to IgniteConfiguration is to use EvictionPolicy instance. That looks error prone as user can easily share instance between caches or cache reincarnations and got unexpected results. E.g. it can cause an AssertionError if EvictionPolicy is reused. Steps to reproduce. 1. Create CacheConfiguration object that will be reused. 2. Create and fill a cache. 3. Destroy cache and create cache again with same CacheConfiguration object. 4. One of next put can fails with stacktrace below. The error is throws when EvictionPolicy tries to evict entries from cache that has just been destroyed. Also, EvictionPolicy object can be implicitly holds by some user objects (together with IgniteConfiguration) that can cause memory leak. java.lang.AssertionError at org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) was: For now the only way to set EvictionPolicy to IgniteConfiguration is to use EvictionPolicy instance. That looks error prone as user can easily share instance between caches or cache reincarnations and got unexpected results. E.g. it can cause an AssertionError if EvictionPolicy is reused. Steps to reproduce. 1. Create CacheConfiguration object that will be reused. 2. Create and fill a cache. 3. Destroy cache and create cache again with same CacheConfiguration object. 4. One of next put can fails with stacktrace below. The error is throws when EvictionPolicy tries to evict entries from cache that has just been destroyed. java.lang.AssertionError at org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) at
[jira] [Created] (IGNITE-6649) Add EvitionPolicy factory support in IgniteConfiguration.
Andrew Mashenkov created IGNITE-6649: Summary: Add EvitionPolicy factory support in IgniteConfiguration. Key: IGNITE-6649 URL: https://issues.apache.org/jira/browse/IGNITE-6649 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: cache Reporter: Andrew Mashenkov Fix For: 2.4 For now the only way to set EvictionPolicy to IgniteConfiguration is to use EvictionPolicy instance. That looks error prone as user can easily share instance between caches or cache reincarnations and got unexpected results. E.g. it can cause an AssertionError if EvictionPolicy is reused. Steps to reproduce. 1. Create CacheConfiguration object that will be reused. 2. Create and fill a cache. 3. Destroy cache and create cache again with same CacheConfiguration object. 4. One of next put can fails with stacktrace below. The error is throws when EvictionPolicy tries to evict entries from cache that has just been destroyed. java.lang.AssertionError at org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) at org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) at org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619 ] Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 12:32 PM: - The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 ({color:#d04437}-5%{color}) | 782.23 ({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 ({color:#d04437}-1%{color}) | | JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 ({color:#d04437}-25%{color}) | 94.90 ({color:#d04437}-11%{color}) | 0.886 ({color:#d04437}-5%{color}) | The parameters {{pageSize}} and {{fetchSize}} are default (1024). was (Author: tledkov-gridgain): The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 ({color:#d04437}-5%{color}) | 782.23 ({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 ({color:#d04437}-1%{color}) | | JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 ({color:#d04437}-5%{color}) | 94.90 ({color:#d04437}-11%{color}) | 0.886 ({color:#d04437}-5%{color}) | The parameters {{pageSize}} and {{fetchSize}} are default (1024). > Add benchmark to compare JDBC drivers and native SQL execution > -- > > Key: IGNITE-6217 > URL: https://issues.apache.org/jira/browse/IGNITE-6217 > Project: Ignite > Issue Type: Task > Components: jdbc, sql, yardstick >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.4 > > > We have to compare performance of the native SQL execution (via Ignite SQL > API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC > thin client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6648) ML javadoc is missing in 2.2 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-6648. -- Resolution: Fixed Merged to 2.3 and master. Thanks for contribution. > ML javadoc is missing in 2.2 binary release > > > Key: IGNITE-6648 > URL: https://issues.apache.org/jira/browse/IGNITE-6648 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Critical > Fix For: 2.3 > > > ML javadoc is missing in binary releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema
[ https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207556#comment-16207556 ] Denis Mekhanikov commented on IGNITE-6572: -- [~vozerov] All calls to registerCache, unregisterCache and registerType of IgniteH2Indexing class are performed under the same mutex in GridQueryProcessor. So there is no need to make this logic thread-safe, as it is never performed concurrently. > Allow multiple caches use one SQL schema > > > Key: IGNITE-6572 > URL: https://issues.apache.org/jira/browse/IGNITE-6572 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Labels: usability > Fix For: 2.4 > > > When trying to create more than one cache with the same SQL schema name, the > following exception is thrown: > {noformat} > Exception in thread "main" class org.apache.ignite.IgniteException: Schema > already registered: TEST_SCHEMA > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957) > at org.apache.ignite.Ignition.start(Ignition.java:350) > at > org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7) > Caused by: class org.apache.ignite.IgniteCheckedException: Schema already > registered: TEST_SCHEMA > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} > It should be allowed to share schema between caches. Currently it works for > PUBLIC schema only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6648) ML javadoc is missing in 2.2 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207553#comment-16207553 ] Oleg Ostanin commented on IGNITE-6648: -- [~avinogradov] Please review the changes: https://github.com/apache/ignite/pull/2868 Here is the example build: https://ci.ignite.apache.org/viewLog.html?buildId=894883=artifacts=IgniteRelease_XxxFromMirrorIgniteRelease3PrepareVote#!1rrb2,-wpvx2aopzexz,-1wknai9u1u6n4,1oz6l8xp9zo0n,-14amd5eyzzgpi,-1i6ixr10ypdh6 > ML javadoc is missing in 2.2 binary release > > > Key: IGNITE-6648 > URL: https://issues.apache.org/jira/browse/IGNITE-6648 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Critical > Fix For: 2.3 > > > ML javadoc is missing in binary releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema
[ https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207545#comment-16207545 ] Vladimir Ozerov commented on IGNITE-6572: - [~dmekhanikov], I did a review. Implementation is not thread-safe. Please wrap the schema register/unregister logic into a critical section. > Allow multiple caches use one SQL schema > > > Key: IGNITE-6572 > URL: https://issues.apache.org/jira/browse/IGNITE-6572 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Labels: usability > Fix For: 2.4 > > > When trying to create more than one cache with the same SQL schema name, the > following exception is thrown: > {noformat} > Exception in thread "main" class org.apache.ignite.IgniteException: Schema > already registered: TEST_SCHEMA > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957) > at org.apache.ignite.Ignition.start(Ignition.java:350) > at > org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7) > Caused by: class org.apache.ignite.IgniteCheckedException: Schema already > registered: TEST_SCHEMA > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} > It should be allowed to share schema between caches. Currently it works for > PUBLIC schema only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema
[ https://issues.apache.org/jira/browse/IGNITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207536#comment-16207536 ] Vladimir Ozerov commented on IGNITE-6572: - PR: https://github.com/apache/ignite/pull/2850 > Allow multiple caches use one SQL schema > > > Key: IGNITE-6572 > URL: https://issues.apache.org/jira/browse/IGNITE-6572 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov > Labels: usability > Fix For: 2.4 > > > When trying to create more than one cache with the same SQL schema name, the > following exception is thrown: > {noformat} > Exception in thread "main" class org.apache.ignite.IgniteException: Schema > already registered: TEST_SCHEMA > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957) > at org.apache.ignite.Ignition.start(Ignition.java:350) > at > org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7) > Caused by: class org.apache.ignite.IgniteCheckedException: Schema already > registered: TEST_SCHEMA > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} > It should be allowed to share schema between caches. Currently it works for > PUBLIC schema only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207528#comment-16207528 ] Pavel Tupitsyn commented on IGNITE-6627: Looks good to me. Merged to master: {{93bf555a98c472ff7028a641b32ef5d8ba8df7cd}}. Great job, [~alexey.tank2]. > .NET: cache deserialization fails with complex value type & enum > > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: cache, platforms >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov > Labels: .NET > Fix For: 2.4 > > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCacheDictionary >>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary > > to > Dictionary > > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207529#comment-16207529 ] ASF GitHub Bot commented on IGNITE-6627: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2864 > .NET: cache deserialization fails with complex value type & enum > > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: cache, platforms >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov > Labels: .NET > Fix For: 2.4 > > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCacheDictionary >>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary > > to > Dictionary > > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration
[ https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6647: Assignee: Andrey Novikov (was: Alexey Kuznetsov) Please review. > Web Console: Implement schema migration > --- > > Key: IGNITE-6647 > URL: https://issues.apache.org/jira/browse/IGNITE-6647 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.4 > > > We need to support schema updates for Web Console new versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration
[ https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6647: Assignee: Alexey Kuznetsov (was: Andrey Novikov) > Web Console: Implement schema migration > --- > > Key: IGNITE-6647 > URL: https://issues.apache.org/jira/browse/IGNITE-6647 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov > Fix For: 2.4 > > > We need to support schema updates for Web Console new versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6647) Web Console: Implement schema migration
[ https://issues.apache.org/jira/browse/IGNITE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6647: Assignee: Andrey Novikov (was: Alexey Kuznetsov) > Web Console: Implement schema migration > --- > > Key: IGNITE-6647 > URL: https://issues.apache.org/jira/browse/IGNITE-6647 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > Fix For: 2.4 > > > We need to support schema updates for Web Console new versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6648) ML javadoc is missing in 2.2 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin updated IGNITE-6648: - Priority: Critical (was: Major) > ML javadoc is missing in 2.2 binary release > > > Key: IGNITE-6648 > URL: https://issues.apache.org/jira/browse/IGNITE-6648 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin >Priority: Critical > Fix For: 2.3 > > > ML javadoc is missing in binary releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6648) ML javadoc is missing in 2.2 binary release
Oleg Ostanin created IGNITE-6648: Summary: ML javadoc is missing in 2.2 binary release Key: IGNITE-6648 URL: https://issues.apache.org/jira/browse/IGNITE-6648 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Oleg Ostanin Assignee: Oleg Ostanin ML javadoc is missing in binary releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6648) ML javadoc is missing in 2.2 binary release
[ https://issues.apache.org/jira/browse/IGNITE-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ostanin updated IGNITE-6648: - Fix Version/s: 2.3 > ML javadoc is missing in 2.2 binary release > > > Key: IGNITE-6648 > URL: https://issues.apache.org/jira/browse/IGNITE-6648 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Oleg Ostanin >Assignee: Oleg Ostanin > Fix For: 2.3 > > > ML javadoc is missing in binary releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3840) Continue investigation: High memory utilization when OFFHEAP_TIERED mode and expiry policy are enabled.
[ https://issues.apache.org/jira/browse/IGNITE-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207268#comment-16207268 ] ASF GitHub Bot commented on IGNITE-3840: Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/1037 > Continue investigation: High memory utilization when OFFHEAP_TIERED mode and > expiry policy are enabled. > --- > > Key: IGNITE-3840 > URL: https://issues.apache.org/jira/browse/IGNITE-3840 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final >Reporter: Andrew Mashenkov >Priority: Critical > Labels: community, important > Fix For: 2.0 > > Attachments: IgniteExpiryIssue.java, config.xml > > > Continue investigation of high memory utilization. > The problem is originally reported by Neil Wightman: > http://apache-ignite-users.70518.x6.nabble.com/Off-Heap-cache-using-lots-of-heap-memory-td3414.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5593) Affinity change message leak on massive topology updates
[ https://issues.apache.org/jira/browse/IGNITE-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207261#comment-16207261 ] ASF GitHub Bot commented on IGNITE-5593: Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/2210 > Affinity change message leak on massive topology updates > > > Key: IGNITE-5593 > URL: https://issues.apache.org/jira/browse/IGNITE-5593 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Andrew Mashenkov >Priority: Critical > Fix For: 2.1 > > > When late affinity assignment is enabled, we complete the exchange future > with custom discovery event. Since discovery topology events usually are much > faster than exchange futures completion, it is possible that a newly joined > node can 'see' the affinity change messages that are related to previous > topology versions when this node even was not present in the topology. > When this message is received, an exchange future is created and this message > is added to discoEvts list. However, this future never completes on this node > because init() is never called. This means that this exchange future sits in > the exchange set with the affinity change message. > Since the number of topology changes (and, thus, messages) can be quite > large, this leads to excessive memory consumption on the starting node. I've > observed ~3Gb of heap wasted on one of the nodes when > 200 nodes were > restarted. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5839) Unclear exception from BinaryObjectBuilder::build call when builder is reused
[ https://issues.apache.org/jira/browse/IGNITE-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16207258#comment-16207258 ] ASF GitHub Bot commented on IGNITE-5839: Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/2532 > Unclear exception from BinaryObjectBuilder::build call when builder is reused > - > > Key: IGNITE-5839 > URL: https://issues.apache.org/jira/browse/IGNITE-5839 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergey Chugunov >Assignee: Andrew Mashenkov > Fix For: 2.3 > > > Simple test where {{BinaryObjectBuilder}} builder object is reused fails with > exception {noformat}org.apache.ignite.binary.BinaryObjectException: Wrong > value has been set [typeName=SimpleCls, fieldName=str, fieldType=String, > assignedValueType=Object]{noformat} > {noformat} > IgniteCache
[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619 ] Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 10:06 AM: - The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 ({color:#d04437}-5%{color}) | 782.23 ({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 ({color:#d04437}-1%{color}) | | JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 ({color:#d04437}-5%{color}) | 94.90 ({color:#d04437}-11%{color}) | 0.886 ({color:#d04437}-5%{color}) | The parameters {{pageSize}} and {{fetchSize}} are default (1024). was (Author: tledkov-gridgain): The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 ({color:#d04437}-5%{color}) | 782.23 ({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 ({color:#d04437}-1%{color}) | | JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 ({color:#d04437}-5%{color}) | 94.90 ({color:#d04437}-11%{color}) | 0.886 ({color:#d04437}-5%{color}) | > Add benchmark to compare JDBC drivers and native SQL execution > -- > > Key: IGNITE-6217 > URL: https://issues.apache.org/jira/browse/IGNITE-6217 > Project: Ignite > Issue Type: Task > Components: jdbc, sql, yardstick >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.4 > > > We have to compare performance of the native SQL execution (via Ignite SQL > API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC > thin client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619 ] Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 10:03 AM: - The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 ({color:#d04437}-5%{color}) | 782.23 ({color:#d04437}-13%{color}) | 105.27 ({color:#d04437}-1%{color}) | 0.919 ({color:#d04437}-1%{color}) | | JDBC thin | 4367.87 ({color:#d04437}-53%{color}) | 673.16 ({color:#d04437}-5%{color}) | 94.90 ({color:#d04437}-11%{color}) | 0.886 ({color:#d04437}-5%{color}) | was (Author: tledkov-gridgain): The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 | 782.23 | 105.27| 0.919 | | JDBC thin | 4367.87 | 673.16 | 94.90 | 0.886 | > Add benchmark to compare JDBC drivers and native SQL execution > -- > > Key: IGNITE-6217 > URL: https://issues.apache.org/jira/browse/IGNITE-6217 > Project: Ignite > Issue Type: Task > Components: jdbc, sql, yardstick >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.4 > > > We have to compare performance of the native SQL execution (via Ignite SQL > API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC > thin client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6217) Add benchmark to compare JDBC drivers and native SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205619#comment-16205619 ] Taras Ledkov edited comment on IGNITE-6217 at 10/17/17 9:55 AM: The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || Ops/sec (1000 rows) || Ops / sec (1 rows) || Ops / sec (1M rows) || | Nativa SQL | 9385.99 | 903.53 | 106.77 | 0.931 | | JDBC v2 | .48 | 782.23 | 105.27| 0.919 | | JDBC thin | 4367.87 | 673.16 | 94.90 | 0.886 | was (Author: tledkov-gridgain): The other benchmark result. Configurations: # Native SQL: 1 server, 1 client. SQL queries are execute4d on client on separate host # JDBCv2: 2 1 server, queries are executed on JDBC v2 client on separate host. # JDBC thin: 1 server, 1 client, JDBC thin client runs on separate host and connects to the client node. SQL queries are executed on JDBC client on separate4 host. SQL query: {{SELECT val FROM test WHERE id = }} where TEST table contains two columns: {{id long, val long}} The table contains 1M unique rows. || Benchmark || Ops /sec (1 row) || | Nativa SQL | 9385.99 | | JDBC v2 | .48 | | JDBC thin | 4367.87 | > Add benchmark to compare JDBC drivers and native SQL execution > -- > > Key: IGNITE-6217 > URL: https://issues.apache.org/jira/browse/IGNITE-6217 > Project: Ignite > Issue Type: Task > Components: jdbc, sql, yardstick >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.4 > > > We have to compare performance of the native SQL execution (via Ignite SQL > API), JDBC v2 driver, that uses Ignite client to connect to grid and JDBC > thin client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum
[ https://issues.apache.org/jira/browse/IGNITE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov updated IGNITE-6627: - Component/s: cache > .NET: cache deserialization fails with complex value type & enum > > > Key: IGNITE-6627 > URL: https://issues.apache.org/jira/browse/IGNITE-6627 > Project: Ignite > Issue Type: Bug > Components: cache, platforms >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov > Labels: .NET > Fix For: 2.4 > > > There is an deserialization issue with complex structure. > Please see the sample code below: > {noformat} > public enum SampleEnum : byte > { > One = 0, > Two = 1, > Three = 2 > } > {noformat} > {noformat} > var cache = ignite.GetOrCreateCacheDictionary >>("mySampleCache"); > cache.Put("DictData", Dict); > var result = cache.Get("DictData"); > {noformat} > var result = cache.Get("DictData"); fails with exception: > {"The constructor to deserialize an object of type > 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' > was not found."} > If we change > Dictionary > > to > Dictionary > > then everything works fine -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (IGNITE-6308) BaselineTopology is created on first cluster activation
[ https://issues.apache.org/jira/browse/IGNITE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reopened IGNITE-6308: - > BaselineTopology is created on first cluster activation > --- > > Key: IGNITE-6308 > URL: https://issues.apache.org/jira/browse/IGNITE-6308 > Project: Ignite > Issue Type: Sub-task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.3 > > > h2. Use Cases > * User starts up and activates brand-new grid. On activation BaselineTopology > is created and persisted. > * User starts up some (not all) nodes of old grid (BLT might be already > presented on them) and activates new smaller grid. > BLT is recreated with fewer number of nodes and replaces previous BLT in > persistent storage. > * User starts nodes of old grid (each node already has a BLT available > locally). When all nodes presented in BLT are started grid is activated > automatically. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6336) .NET: Thin client: Create cache
[ https://issues.apache.org/jira/browse/IGNITE-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-6336: --- Fix Version/s: 2.4 > .NET: Thin client: Create cache > --- > > Key: IGNITE-6336 > URL: https://issues.apache.org/jira/browse/IGNITE-6336 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.4 > > > Create caches from thin client (by name and from {{CacheConfiguration}}). > Implement {{ICache.GetConfiguration}}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)