[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782014#comment-16782014
]
Roman Kondakov commented on IGNITE-10104:
-
[~gvvinblade], patch is ready for review. TC looks good.
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782012#comment-16782012
]
Ignite TC Bot commented on IGNITE-10104:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3194165buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
[ https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11461: Description: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io Ignite compatibility with Jigsaw is tested in a separate project. See details in https://github.com/apache/ignite/tree/ignite-11461-java11/modules/dev-utils/ignite-modules-test#ignite-modular-environment-test-project Currenly investigated modules to be used as automatic modules: ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x) [IGNITE-11464] | |ignite-direct-io|(x) blocked by indexing | |ignite-spring|(x) | was: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x) [IGNITE-11464] | |ignite-direct-io|(x) blocked by indexing | |ignite-spring|(x) | > Automatic modules support for Apache Ignite: find and resolve packages > conflicts > > > Key: IGNITE-11461 > URL: https://issues.apache.org/jira/browse/IGNITE-11461 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Example of failure in a modular environment: > Error:java: the unnamed module reads package > org.apache.ignite.internal.processors.cache.persistence.file from both > ignite.core and ignite.direct.io > Ignite compatibility with Jigsaw is tested in a separate project. See details > in > https://github.com/apache/ignite/tree/ignite-11461-java11/modules/dev-utils/ignite-modules-test#ignite-modular-environment-test-project > > Currenly investigated modules to be used as automatic modules: > ||Module||Run In Modular Environment|| > |ignite-code|(/)| > |ignite-indexing|(x) [IGNITE-11464] | > |ignite-direct-io|(x) blocked by indexing | > |ignite-spring|(x) | -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11190) Fix Apache Ignite tests of Camel Streamer under Java 11
[ https://issues.apache.org/jira/browse/IGNITE-11190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781978#comment-16781978 ] Dmitriy Pavlov commented on IGNITE-11190: - [~roman_s] about class version is it ok, most libs use older Java class versions. Could you please share details about errors you have? I've used maven build from Idea interface and it works well. Probably some additional profiles need to be enabled. > Fix Apache Ignite tests of Camel Streamer under Java 11 > --- > > Key: IGNITE-11190 > URL: https://issues.apache.org/jira/browse/IGNITE-11190 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Roman Shtykh >Priority: Major > > Under Java 11 tests failed with an Error 500 - internal server error > https://ci.ignite.apache.org/viewLog.html?buildId=2973663=buildResultsDiv=IgniteTests24Java8_Streamers > Probably we need to pass startup parameters to 3rd party product/JVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11277) Use maven plugin as default code style checker for project
[
https://issues.apache.org/jira/browse/IGNITE-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771200#comment-16771200
]
Maxim Muzafarov edited comment on IGNITE-11277 at 3/1/19 6:55 PM:
--
Сhanges that have been made:
# Configured {{maven-checkstyle-plugin}} for all the Apache Ignite project
# {{checkstyle}} profile configured and is active by default
# These checkstyle rules are configured
** {{FileTabCharacter}} (an {{ProblematicWhitespace}} analogue inspection)
** {{UnusedImports}} (an {{UnusedImport}} analogue inspection)
** {{ModifierOrder}} (a {{MissortedModifiers}} analogue inspection)
** {{MissingOverrideAnnotation}} inspection has a
[{{MissingOverride}}|http://checkstyle.sourceforge.net/config_annotation.html#MissingOverride]
analogue module for the checkstyle plugin. It is working not the same way.
# These inspections rules don't have direct analogue or working not the same
** {{SizeReplaceableByIsEmpty}} doesn't have a direct analogue of checkstyle
modules
** {{RedundantSuppression}} inspection doesn't have the direct analogue of
checkstyle module
# All additional files have been fixed (e.g. all unused imports removed) to
make project compile.
was (Author: mmuzaf):
Сhanges that have been made:
# Configured {{maven-checkstyle-plugin}} for all the Apache Ignite project
# {{checkstyle}} profile configured and is active by default
# These checkstyle rules are configured
** {{FileTabCharacter}} (an {{ProblematicWhitespace}} analogue inspection)
** {{UnusedImports}} (an {{UnusedImport}} analogue inspection)
** {{ModifierOrder}} (a {{MissortedModifiers}} analogue inspection)
# These inspections rules don't have direct analogue or working not the same
** {{SizeReplaceableByIsEmpty}} doesn't have a direct analogue of checkstyle
modules
** {{MissingOverrideAnnotation}} inspection has a
[{{MissingOverride}}|http://checkstyle.sourceforge.net/config_annotation.html#MissingOverride]
analogue module for the checkstyle plugin. It is working not the same way.
Must be implemented in the separate ticket
** {{RedundantSuppression}} inspection doesn't have the direct analogue of
checkstyle module
# All additional files have been fixed (e.g. all unused imports removed) to
make project compile.
> Use maven plugin as default code style checker for project
> --
>
> Key: IGNITE-11277
> URL: https://issues.apache.org/jira/browse/IGNITE-11277
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: inspections
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, {{[Inspections] Core suite}} [1] on TC doesn't work well enough.
> The suite has a {{FAILED}} status for more than 2 months due to some issues
> on TeamCity application [2]. It confuses most of the members of the Apache
> Ignite community.
> Moreover, this suite is no longer checks configured rules. For instance, in
> the master branch, 11 {{Unused imports}} can be found (e.g. for
> {{IgniteCachePutAllRestartTest}
> [3]).
> I think the maven-checkstyle-plugin should be used as the default code style
> checker.
> _Advantages:_
> * An IDE agnostic way for code checks
> * Can be used with different CI and build tools
> * Executable from the command line
> * Single configuration
> [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_InspectionsCore_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> [2] https://youtrack.jetbrains.com/issue/TW-58504
> [3]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.java#L29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781783#comment-16781783
]
Ivan Pavlukhin commented on IGNITE-9470:
[~amashenkov], a particular test always goes in a following way: there are 2
explicit transactions modifying the same key, and one of them always fails with
_write conflict_ (the test simulates it). As a result there is only one
transaction inserting new version of a key and all checks from multiple threads
seem useless. I believe that the test was written in order to guarantee that
initial implementation of MVCC for cache API (storing all entries in near tx)
works as expected. And the test is rather fine-grained, I do not see it's value
for current MVCC implementation.
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
> Pay attention that tx could be aborted at different stages, but we should
> fail consistently. Some examples:
> 1. Before next operation in tx started.
> 2. While operation in tx is in progress.
> 3. When {{tx.commit()}} is called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10561) MVCC: Fix MVCC cache rebalance.
[
https://issues.apache.org/jira/browse/IGNITE-10561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781757#comment-16781757
]
Ignite TC Bot commented on IGNITE-10561:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3211244buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Fix MVCC cache rebalance.
> ---
>
> Key: IGNITE-10561
> URL: https://issues.apache.org/jira/browse/IGNITE-10561
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unexpected transaction state may be observed on some nodes after rebalance.
> Reproducer: {{GridCacheRebalancingSyncSelfTest#testComplexRebalancing}}
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=149236, crdVer=1544033736224,
> cntr=800063, opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:931)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:251)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:213)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.testComplexRebalancing(GridCacheRebalancingSyncSelfTest.java:588)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccSnapshotSearchRow [res=null, snapshot=MvccSnapshotResponse
> [futId=149236, crdVer=1544033736224, cntr=800063, opCntr=1073741823,
> txs=null, cleanupVer=0, tracking=0]], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1035)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2849)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:695)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2024)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
>
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[ https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781732#comment-16781732 ] Pavel Kuznetsov commented on IGNITE-5962: - Ok, I've commited another approach: 1) Both tree name and segmentName are now generated directly in the H2TreeIndex and no masking is performed in IndexingStorageImpl 2) Index name is validated by creating name of segment with biggestId. Then this name length in utf-8 is validated. > Increase max length of index name > - > > Key: IGNITE-5962 > URL: https://issues.apache.org/jira/browse/IGNITE-5962 > Project: Ignite > Issue Type: Improvement > Components: general, sql >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Pavel Kuznetsov >Priority: Major > > In https://issues.apache.org/jira/browse/IGNITE-5941 max index name length > was reduced from 768 to 256 bytes. If we need to support longer names, we > need to change format of metastore data pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
[ https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11461: Description: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x) [IGNITE-11464] | |ignite-direct-io|(x) blocked by indexing | |ignite-spring|(x) | was: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x) [IGNITE-11464] | |ignite-direct-io|(x) blocked by indexing | |ignite-spring|(x) blocked by indexing | > Automatic modules support for Apache Ignite: find and resolve packages > conflicts > > > Key: IGNITE-11461 > URL: https://issues.apache.org/jira/browse/IGNITE-11461 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Example of failure in a modular environment: > Error:java: the unnamed module reads package > org.apache.ignite.internal.processors.cache.persistence.file from both > ignite.core and ignite.direct.io > ||Module||Run In Modular Environment|| > |ignite-code|(/)| > |ignite-indexing|(x) [IGNITE-11464] | > |ignite-direct-io|(x) blocked by indexing | > |ignite-spring|(x) | -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
[ https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11461: Description: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x) [IGNITE-11464] | |ignite-direct-io|(x) blocked by indexing | |ignite-spring|(x) blocked by indexing | was: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x)| > Automatic modules support for Apache Ignite: find and resolve packages > conflicts > > > Key: IGNITE-11461 > URL: https://issues.apache.org/jira/browse/IGNITE-11461 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Example of failure in a modular environment: > Error:java: the unnamed module reads package > org.apache.ignite.internal.processors.cache.persistence.file from both > ignite.core and ignite.direct.io > ||Module||Run In Modular Environment|| > |ignite-code|(/)| > |ignite-indexing|(x) [IGNITE-11464] | > |ignite-direct-io|(x) blocked by indexing | > |ignite-spring|(x) blocked by indexing | -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11464) Support Automatic modules for ignite-indexing: bypass or fix H2, Lucene, fix queries and visor package conflicts
[
https://issues.apache.org/jira/browse/IGNITE-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11464:
Comment: was deleted
(was: It seems Lucene should be upgraded to version 7+ to fix its issues.)
> Support Automatic modules for ignite-indexing: bypass or fix H2, Lucene, fix
> queries and visor package conflicts
>
>
> Key: IGNITE-11464
> URL: https://issues.apache.org/jira/browse/IGNITE-11464
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> {noformat}
> error: the unnamed module reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: the unnamed module reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: the unnamed module reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module ignite.indexing reads package org.apache.lucene.search from
> both lucene.sandbox and lucene.core
> error: module ignite.indexing reads package org.apache.lucene.document from
> both lucene.sandbox and lucene.core
> error: module ignite.indexing reads package
> org.apache.lucene.analysis.standard from both lucene.core and
> lucene.analyzers.common
> error: module ignite.indexing reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module ignite.indexing reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module cache.api reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module cache.api reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module cache.api reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module cache.api reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module cache.api reads package org.apache.ignite.internal.visor.verify
> from both ignite.indexing and ignite.core
> error: module annotations reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module annotations reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module annotations reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module annotations reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module annotations reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module ignite.shmem reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module ignite.shmem reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module ignite.shmem reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module ignite.shmem reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module ignite.shmem reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module org.apache.commons.codec reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> error: module org.apache.commons.codec reads package
> org.apache.lucene.document from both lucene.sandbox and lucene.core
> error: module org.apache.commons.codec reads package
> org.apache.lucene.analysis.standard from both lucene.core and
> lucene.analyzers.common
> error: module org.apache.commons.codec reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module org.apache.commons.codec reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module lucene.analyzers.common reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> error: module lucene.analyzers.common reads package
> org.apache.lucene.document from both lucene.sandbox and lucene.core
> error: module lucene.analyzers.common reads package
> org.apache.lucene.analysis.standard from both lucene.core and
>
[jira] [Commented] (IGNITE-11464) Support Automatic modules for ignite-indexing: bypass or fix H2, Lucene, fix queries and visor package conflicts
[
https://issues.apache.org/jira/browse/IGNITE-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781703#comment-16781703
]
Dmitriy Pavlov commented on IGNITE-11464:
-
It seems Lucene should be upgraded to version 7+ to fix its issues.
> Support Automatic modules for ignite-indexing: bypass or fix H2, Lucene, fix
> queries and visor package conflicts
>
>
> Key: IGNITE-11464
> URL: https://issues.apache.org/jira/browse/IGNITE-11464
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Priority: Major
>
> {noformat}
> error: the unnamed module reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: the unnamed module reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: the unnamed module reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module ignite.indexing reads package org.apache.lucene.search from
> both lucene.sandbox and lucene.core
> error: module ignite.indexing reads package org.apache.lucene.document from
> both lucene.sandbox and lucene.core
> error: module ignite.indexing reads package
> org.apache.lucene.analysis.standard from both lucene.core and
> lucene.analyzers.common
> error: module ignite.indexing reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module ignite.indexing reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module cache.api reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module cache.api reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module cache.api reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module cache.api reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module cache.api reads package org.apache.ignite.internal.visor.verify
> from both ignite.indexing and ignite.core
> error: module annotations reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module annotations reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module annotations reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module annotations reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module annotations reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module ignite.shmem reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: module ignite.shmem reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: module ignite.shmem reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: module ignite.shmem reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module ignite.shmem reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module org.apache.commons.codec reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> error: module org.apache.commons.codec reads package
> org.apache.lucene.document from both lucene.sandbox and lucene.core
> error: module org.apache.commons.codec reads package
> org.apache.lucene.analysis.standard from both lucene.core and
> lucene.analyzers.common
> error: module org.apache.commons.codec reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: module org.apache.commons.codec reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
> error: module lucene.analyzers.common reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> error: module lucene.analyzers.common reads package
> org.apache.lucene.document from both lucene.sandbox and lucene.core
> error: module lucene.analyzers.common reads package
> org.apache.lucene.analysis.standard from both
[jira] [Created] (IGNITE-11464) Support Automatic modules for ignite-indexing: bypass or fix H2, Lucene, fix queries and visor package conflicts
Dmitriy Pavlov created IGNITE-11464:
---
Summary: Support Automatic modules for ignite-indexing: bypass or
fix H2, Lucene, fix queries and visor package conflicts
Key: IGNITE-11464
URL: https://issues.apache.org/jira/browse/IGNITE-11464
Project: Ignite
Issue Type: Sub-task
Reporter: Dmitriy Pavlov
{noformat}
error: the unnamed module reads package org.apache.lucene.search from both
lucene.sandbox and lucene.core
error: the unnamed module reads package org.apache.lucene.document from both
lucene.sandbox and lucene.core
error: the unnamed module reads package org.apache.lucene.analysis.standard
from both lucene.core and lucene.analyzers.common
error: the unnamed module reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: the unnamed module reads package org.apache.ignite.internal.visor.verify
from both ignite.indexing and ignite.core
error: module ignite.indexing reads package org.apache.lucene.search from both
lucene.sandbox and lucene.core
error: module ignite.indexing reads package org.apache.lucene.document from
both lucene.sandbox and lucene.core
error: module ignite.indexing reads package org.apache.lucene.analysis.standard
from both lucene.core and lucene.analyzers.common
error: module ignite.indexing reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module ignite.indexing reads package
org.apache.ignite.internal.visor.verify from both ignite.indexing and
ignite.core
error: module cache.api reads package org.apache.lucene.search from both
lucene.sandbox and lucene.core
error: module cache.api reads package org.apache.lucene.document from both
lucene.sandbox and lucene.core
error: module cache.api reads package org.apache.lucene.analysis.standard from
both lucene.core and lucene.analyzers.common
error: module cache.api reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module cache.api reads package org.apache.ignite.internal.visor.verify
from both ignite.indexing and ignite.core
error: module annotations reads package org.apache.lucene.search from both
lucene.sandbox and lucene.core
error: module annotations reads package org.apache.lucene.document from both
lucene.sandbox and lucene.core
error: module annotations reads package org.apache.lucene.analysis.standard
from both lucene.core and lucene.analyzers.common
error: module annotations reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module annotations reads package org.apache.ignite.internal.visor.verify
from both ignite.indexing and ignite.core
error: module ignite.shmem reads package org.apache.lucene.search from both
lucene.sandbox and lucene.core
error: module ignite.shmem reads package org.apache.lucene.document from both
lucene.sandbox and lucene.core
error: module ignite.shmem reads package org.apache.lucene.analysis.standard
from both lucene.core and lucene.analyzers.common
error: module ignite.shmem reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module ignite.shmem reads package
org.apache.ignite.internal.visor.verify from both ignite.indexing and
ignite.core
error: module org.apache.commons.codec reads package org.apache.lucene.search
from both lucene.sandbox and lucene.core
error: module org.apache.commons.codec reads package org.apache.lucene.document
from both lucene.sandbox and lucene.core
error: module org.apache.commons.codec reads package
org.apache.lucene.analysis.standard from both lucene.core and
lucene.analyzers.common
error: module org.apache.commons.codec reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module org.apache.commons.codec reads package
org.apache.ignite.internal.visor.verify from both ignite.indexing and
ignite.core
error: module lucene.analyzers.common reads package org.apache.lucene.search
from both lucene.sandbox and lucene.core
error: module lucene.analyzers.common reads package org.apache.lucene.document
from both lucene.sandbox and lucene.core
error: module lucene.analyzers.common reads package
org.apache.lucene.analysis.standard from both lucene.core and
lucene.analyzers.common
error: module lucene.analyzers.common reads package
org.apache.ignite.internal.processors.cache.query from both ignite.indexing and
ignite.core
error: module lucene.analyzers.common reads package
org.apache.ignite.internal.visor.verify from both ignite.indexing and
ignite.core
error: module lucene.queryparser reads package org.apache.lucene.search from
both lucene.sandbox and lucene.core
error: module lucene.queryparser reads package org.apache.lucene.document from
both lucene.sandbox and
[jira] [Updated] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
[ https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11461: Description: Example of failure in a modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io ||Module||Run In Modular Environment|| |ignite-code|(/)| |ignite-indexing|(x)| was: Example of failure in modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io > Automatic modules support for Apache Ignite: find and resolve packages > conflicts > > > Key: IGNITE-11461 > URL: https://issues.apache.org/jira/browse/IGNITE-11461 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Example of failure in a modular environment: > Error:java: the unnamed module reads package > org.apache.ignite.internal.processors.cache.persistence.file from both > ignite.core and ignite.direct.io > ||Module||Run In Modular Environment|| > |ignite-code|(/)| > |ignite-indexing|(x)| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781673#comment-16781673
]
Andrew Mashenkov commented on IGNITE-9470:
--
[~Pavlukhin],
Looks good, but what's wrong with removed test testCleanupWaitsForGet2?
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
> Pay attention that tx could be aborted at different stages, but we should
> fail consistently. Some examples:
> 1. Before next operation in tx started.
> 2. While operation in tx is in progress.
> 3. When {{tx.commit()}} is called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2
[
https://issues.apache.org/jira/browse/IGNITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781666#comment-16781666
]
Ignite TC Bot commented on IGNITE-5250:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3209513buildTypeId=IgniteTests24Java8_RunAll]
> Unhelpful exception when value of wrong type is passed to H2
>
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key,
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL
> query.
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
> ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY
> VARCHAR=(?4,)) [90003-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at org.h2.table.Column.convert(Column.java:167)
> at
[jira] [Commented] (IGNITE-11334) SQL: Deprecate SqlQuery
[
https://issues.apache.org/jira/browse/IGNITE-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781634#comment-16781634
]
Ignite TC Bot commented on IGNITE-11334:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3135328buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Deprecate SqlQuery
> ---
>
> Key: IGNITE-11334
> URL: https://issues.apache.org/jira/browse/IGNITE-11334
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This API is very limited comparing to {{SqlFieldsQuery}}. Let's deprecate it
> with proper links to {{SqlFieldsQuery}}. This should be not only deprecation
> on public API, but removal from examples as well.
> Separate ticket for documentation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11454) Race in ClientImpl may lead to client node segmentation on fast reconnect
[
https://issues.apache.org/jira/browse/IGNITE-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781629#comment-16781629
]
Sergey Chugunov commented on IGNITE-11454:
--
[~agoncharuk],
I didn't come up with scenarios where proposed patch could incorrectly segment
node.
So I think we are safe to merge it to master.
> Race in ClientImpl may lead to client node segmentation on fast reconnect
> -
>
> Key: IGNITE-11454
> URL: https://issues.apache.org/jira/browse/IGNITE-11454
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have the following code in {{ClientImpl#tryJoin}}:
> {code}
> if (spi.joinTimeout > 0) {
> final int joinCnt0 = joinCnt;
> timer.schedule(new TimerTask() {
> @Override public void run() {
> if (joinCnt == joinCnt0 && joining())
> queue.add(JOIN_TIMEOUT);
> }
> }, spi.joinTimeout);
> }
> {code}
> We have a window when the timeout object is still scheduled, but the node is
> already connected to the cluster. The following sequence is possible: a node
> disconnects, clears it's queue, then timeout object is fired, adds a message
> to the queue, then {{tryJoin}} is called. In this case, the node will be
> immediately segmented.
> {{ClientReconnectAfterClusterRestartTest}} demonstrates this if join timeout
> is set to 10s.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11245) Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT parameter.
[ https://issues.apache.org/jira/browse/IGNITE-11245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781512#comment-16781512 ] Andrey Kalinin edited comment on IGNITE-11245 at 3/1/19 12:46 PM: -- [~v.pyatkov], this scenario is fully covered by _*BinaryMetadataConcurrentUpdateWithIndexesTest*_ written by [~ascherbakov] in IGNITE-9830. was (Author: 6uest): [~v.pyatkov], this scenario is fully covered by _*BinaryMetadataConcurrentUpdateWithIndexesTest*_ written by [~ascherbakov] on IGNITE-9830. > Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT parameter. > --- > > Key: IGNITE-11245 > URL: https://issues.apache.org/jira/browse/IGNITE-11245 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Stanilovsky Evgeny >Assignee: Andrey Kalinin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT with > IGNITE_WAIT_SCHEMA_UPDATE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7948) SQL: read only necessary fields into the row when possible
[
https://issues.apache.org/jira/browse/IGNITE-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-7948:
Assignee: (was: Taras Ledkov)
> SQL: read only necessary fields into the row when possible
> --
>
> Key: IGNITE-7948
> URL: https://issues.apache.org/jira/browse/IGNITE-7948
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> When H2 row is read, we always fill it with data eagerly through link
> materialization. Materialization is performed under page "read lock" what
> guarantees row-level consistency. This may lead to excessive memory pressure
> due to memory copying. For example, consider a class with 50 fields and a
> query which reads only 2 of them. 48 other fields will be copied without a
> reason. Lazy initialization is not an option because it will only defer
> memcpy, but not eliminate it.
> Instead we can try using H2. It passes {{TableFilter}} class to some of index
> access methods*. We can analyze this class and create the list of required
> fields. Then we can read these fields under read lock from offheap and put
> them to the row.
> In addition to saved memcpy this could give us more benefits:
> 1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
> 2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}
> But there are a number of drawbacks as well. E.g. it is impossible to read
> strings from offheap efficiently, so queries with VARCHAR will definitely
> suffer from this change.
> \* {{org.h2.index.Index#find(org.h2.table.TableFilter,
> org.h2.result.SearchRow, org.h2.result.SearchRow)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11453) SQL: command to work with permission must thrown clear exception witn UNSUPPORTED error code
[ https://issues.apache.org/jira/browse/IGNITE-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11453: -- Summary: SQL: command to work with permission must thrown clear exception witn UNSUPPORTED error code (was: SQL: command to wotk with permission must thrown clear exception witn UNSUPPORTED error code) > SQL: command to work with permission must thrown clear exception witn > UNSUPPORTED error code > > > Key: IGNITE-11453 > URL: https://issues.apache.org/jira/browse/IGNITE-11453 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > > The command to work with permissions may produce confused error when Ignite > used with specified name is created. > These command must be disabled and throw exception witn UNSUPPORTED error > code: > - GRANT / REVOKE ON TO ; > - GRANT / REVOKE TO ; > - GRANT ALTER ANY SCHEMA ; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11463) ODBC backward compatibility between 2.5 and 2.7 is broken
[ https://issues.apache.org/jira/browse/IGNITE-11463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-11463: - Ignite Flags: (was: Docs Required) > ODBC backward compatibility between 2.5 and 2.7 is broken > - > > Key: IGNITE-11463 > URL: https://issues.apache.org/jira/browse/IGNITE-11463 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.6, 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: odbc > Fix For: 2.8 > > > ODBC driver with version 2.5 can not connect to server 2.6 or 2.7. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
[ https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-11461: Fix Version/s: 2.8 > Automatic modules support for Apache Ignite: find and resolve packages > conflicts > > > Key: IGNITE-11461 > URL: https://issues.apache.org/jira/browse/IGNITE-11461 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Fix For: 2.8 > > > Example of failure in modular environment: > Error:java: the unnamed module reads package > org.apache.ignite.internal.processors.cache.persistence.file from both > ignite.core and ignite.direct.io -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11463) ODBC backward compatibility between 2.5 and 2.7 is broken
Igor Sapego created IGNITE-11463: Summary: ODBC backward compatibility between 2.5 and 2.7 is broken Key: IGNITE-11463 URL: https://issues.apache.org/jira/browse/IGNITE-11463 Project: Ignite Issue Type: Bug Components: odbc Affects Versions: 2.7, 2.6 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.8 ODBC driver with version 2.5 can not connect to server 2.6 or 2.7. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11462) MVCC: Fix GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest.
[ https://issues.apache.org/jira/browse/IGNITE-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-11462: - Assignee: Andrew Mashenkov > MVCC: Fix GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest. > -- > > Key: IGNITE-11462 > URL: https://issues.apache.org/jira/browse/IGNITE-11462 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Next tests failed on TC: > GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest.testPessimisticRepeatableReadCommitMultithreaded > GridCacheReplicatedMvccTxMultiThreadedSelfTest.testPessimisticRepeatableReadCommitMultithreaded > > Seems, retry on write conflict is missed in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11462) MVCC: Fix GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest.
Andrew Mashenkov created IGNITE-11462: - Summary: MVCC: Fix GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest. Key: IGNITE-11462 URL: https://issues.apache.org/jira/browse/IGNITE-11462 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Next tests failed on TC: GridCachePartitionedNearDisabledMvccTxMultiThreadedSelfTest.testPessimisticRepeatableReadCommitMultithreaded GridCacheReplicatedMvccTxMultiThreadedSelfTest.testPessimisticRepeatableReadCommitMultithreaded Seems, retry on write conflict is missed in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7664) SQL: throw sane exception on unsupported SQL statements
[ https://issues.apache.org/jira/browse/IGNITE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781594#comment-16781594 ] Taras Ledkov edited comment on IGNITE-7664 at 3/1/19 11:38 AM: --- A bit about rows output behavior. - TOP == LIMIT == FETCH - but I guess OFFSET semantic is ambiguous (or hard to implement) for Ignite and the most distributes cases. was (Author: tledkov-gridgain): A bit about rows output behavior. - TOP == LIMIT == FETCH - but I guess OFFSET semantic is ambiguous for Ignite and the most distributes cases. > SQL: throw sane exception on unsupported SQL statements > --- > > Key: IGNITE-7664 > URL: https://issues.apache.org/jira/browse/IGNITE-7664 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Assignee: Taras Ledkov >Priority: Major > Labels: sql-stability > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Inspired by this SO issue: > [https://stackoverflow.com/questions/48708238/ignite-database-create-schema-assertionerror] > We should handle unsupported stuff more gracefully both in core code and > drivers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7664) SQL: throw sane exception on unsupported SQL statements
[ https://issues.apache.org/jira/browse/IGNITE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781594#comment-16781594 ] Taras Ledkov commented on IGNITE-7664: -- A bit about rows output behavior. - TOP == LIMIT == FETCH - but I guess OFFSET semantic is ambiguous for Ignite and the most distributes cases. > SQL: throw sane exception on unsupported SQL statements > --- > > Key: IGNITE-7664 > URL: https://issues.apache.org/jira/browse/IGNITE-7664 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Paschenko >Assignee: Taras Ledkov >Priority: Major > Labels: sql-stability > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Inspired by this SO issue: > [https://stackoverflow.com/questions/48708238/ignite-database-create-schema-assertionerror] > We should handle unsupported stuff more gracefully both in core code and > drivers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts
Dmitriy Pavlov created IGNITE-11461: --- Summary: Automatic modules support for Apache Ignite: find and resolve packages conflicts Key: IGNITE-11461 URL: https://issues.apache.org/jira/browse/IGNITE-11461 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Example of failure in modular environment: Error:java: the unnamed module reads package org.apache.ignite.internal.processors.cache.persistence.file from both ignite.core and ignite.direct.io -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11394) Infinite No next node in topology messages during node restart scenario
[
https://issues.apache.org/jira/browse/IGNITE-11394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781570#comment-16781570
]
Sergey Chugunov commented on IGNITE-11394:
--
[~agoncharuk], OK, then lets proceed with merging this change to master.
Thank you!
> Infinite No next node in topology messages during node restart scenario
> ---
>
> Key: IGNITE-11394
> URL: https://issues.apache.org/jira/browse/IGNITE-11394
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observe a situation with the following symptoms during a cycled nodes
> restart:
> - A node being joining to the cluster sends join request, receives
> NodeAddedMessage and awaits NodeAddFinishedMessage
> - The node receives a metrics update message, the message is in the queue
> - The whole cluster is being restarted, a new ring is formed
> - The node re-sends the join request, it is successfully process by the ring
> - The node added message is received by the joining node
> - The node detects that it cannot send messages (failed nodes contains all
> ring remote nodes)
> - Sine there was already a metrics update message in the queue, the node
> attempts to re-add the message to the queue. Since the metrics update message
> is a high priority message, it is added to the head of the queue and the node
> gets stuck in an infinite loop
> I suggest to drop metrics update message in {{sendMessageAcrossRing}} if we
> see the {{No next node in topology}} situation.
> Another question is why don't we pass the collection of failed nodes to the
> {{ring.hasRemoteNodes()}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11394) Infinite No next node in topology messages during node restart scenario
[
https://issues.apache.org/jira/browse/IGNITE-11394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781567#comment-16781567
]
Alexey Goncharuk commented on IGNITE-11394:
---
[~sergey-chugunov], this is the first solution I tried, but dropping the
metrics update message breaks client discovery tests for some reason. I will
create an additional ticket for investigation shortly.
> Infinite No next node in topology messages during node restart scenario
> ---
>
> Key: IGNITE-11394
> URL: https://issues.apache.org/jira/browse/IGNITE-11394
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observe a situation with the following symptoms during a cycled nodes
> restart:
> - A node being joining to the cluster sends join request, receives
> NodeAddedMessage and awaits NodeAddFinishedMessage
> - The node receives a metrics update message, the message is in the queue
> - The whole cluster is being restarted, a new ring is formed
> - The node re-sends the join request, it is successfully process by the ring
> - The node added message is received by the joining node
> - The node detects that it cannot send messages (failed nodes contains all
> ring remote nodes)
> - Sine there was already a metrics update message in the queue, the node
> attempts to re-add the message to the queue. Since the metrics update message
> is a high priority message, it is added to the head of the queue and the node
> gets stuck in an infinite loop
> I suggest to drop metrics update message in {{sendMessageAcrossRing}} if we
> see the {{No next node in topology}} situation.
> Another question is why don't we pass the collection of failed nodes to the
> {{ring.hasRemoteNodes()}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11454) Race in ClientImpl may lead to client node segmentation on fast reconnect
[
https://issues.apache.org/jira/browse/IGNITE-11454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781560#comment-16781560
]
Ignite TC Bot commented on IGNITE-11454:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3203380buildTypeId=IgniteTests24Java8_RunAll]
> Race in ClientImpl may lead to client node segmentation on fast reconnect
> -
>
> Key: IGNITE-11454
> URL: https://issues.apache.org/jira/browse/IGNITE-11454
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have the following code in {{ClientImpl#tryJoin}}:
> {code}
> if (spi.joinTimeout > 0) {
> final int joinCnt0 = joinCnt;
> timer.schedule(new TimerTask() {
> @Override public void run() {
> if (joinCnt == joinCnt0 && joining())
> queue.add(JOIN_TIMEOUT);
> }
> }, spi.joinTimeout);
> }
> {code}
> We have a window when the timeout object is still scheduled, but the node is
> already connected to the cluster. The following sequence is possible: a node
> disconnects, clears it's queue, then timeout object is fired, adds a message
> to the queue, then {{tryJoin}} is called. In this case, the node will be
> immediately segmented.
> {{ClientReconnectAfterClusterRestartTest}} demonstrates this if join timeout
> is set to 10s.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11210) SQL: Introduce common logical execution plan for all query types
[
https://issues.apache.org/jira/browse/IGNITE-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781551#comment-16781551
]
Vladimir Ozerov commented on IGNITE-11210:
--
All is ok. Can be merged.
> SQL: Introduce common logical execution plan for all query types
>
>
> Key: IGNITE-11210
> URL: https://issues.apache.org/jira/browse/IGNITE-11210
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment we have a lot of various cached stuff used for different SQL
> types (prepared statements for local queries, two-step queries for
> distributed queries, update plan for DML).
> What we need instead of having multiple caches is to create common execution
> plan for every query, which will hold both DML and SELECT stuff. Approximate
> content of such a plan:
> # Two-step plan
> # DML plan
> # Partition pruning stuff
> # May be even cached physical node distribution (for reduce queries) for the
> given {{AffinityTopologyVersion}}
> # Probably {{AffinityTopologyVersion}}
> Then we will perform a single plan lookup/build per every query execution. In
> future we will probably display these plans in SQL views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781545#comment-16781545
]
Ignite TC Bot commented on IGNITE-10078:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=3204681]]
* exe: CacheLocalTest.TestTransactionScopeMultiCache(True) - 0,0% fails in last
605 master runs.
* exe: CacheLocalTest.TestTransactionScopeMultiCache(False) - 0,0% fails in
last 605 master runs.
* exe: CacheLocalTest.TestTxAllModes(True) - 0,0% fails in last 605 master runs.
* exe: CacheLocalTest.TestTxAllModes(False) - 0,0% fails in last 605 master
runs.
* exe: CacheLocalTest.TestTxCommit(True) - 0,0% fails in last 605 master runs.
* exe: CacheLocalTest.TestTxCommit(False) - 0,0% fails in last 605 master runs.
{color:#d04437}MVCC PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3204707]]
* IgnitePdsMvccTestSuite2: IgnitePdsCorruptedStoreTest.testCheckpointFailure -
0,0% fails in last 440 master runs.
{color:#d04437}PDS (Indexing){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3208823]]
* IgnitePdsWithIndexingCoreTestSuite:
IgniteLogicalRecoveryTest.testRecoveryOnJoinToInactiveCluster - 0,0% fails in
last 442 master runs.
* IgnitePdsWithIndexingCoreTestSuite:
IgniteLogicalRecoveryTest.testRecoveryOnJoinToActiveCluster - 0,0% fails in
last 442 master runs.
{color:#d04437}Service Grid{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3204695]]
* IgniteServiceGridTestSuite:
ServiceDeploymentOnClientDisconnectTest.testThrowingExceptionOnUndeployUsingInternalApiWhileClientDisconnectedTest
- 0,0% fails in last 652 master runs.
{color:#d04437}Continuous Query 2{color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=3204606]]
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryAsyncFailoverMvccTxSelfTest.testStartStopQuery - 0,0% fails
in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxReplicatedSelfTest.testNoEventLossOnTopologyChange
- 0,0% fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryAsyncFailoverMvccTxSelfTest.testNoEventLossOnTopologyChange
- 0,0% fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxSelfTest.testUpdatePartitionCounter - 0,0%
fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxSelfTest.testStartStopQuery - 0,0% fails in
last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxReplicatedSelfTest.testUpdatePartitionCounter
- 0,0% fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxReplicatedSelfTest.testStartStopQuery - 0,0%
fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryAsyncFailoverMvccTxSelfTest.testUpdatePartitionCounter -
0,0% fails in last 432 master runs.
* IgniteCacheQuerySelfTestSuite4:
CacheContinuousQueryFailoverMvccTxSelfTest.testNoEventLossOnTopologyChange -
0,0% fails in last 432 master runs.
{color:#d04437}MVCC Cache 7{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3204703]]
* IgniteCacheMvccTestSuite7:
IgniteCacheStartWithLoadTest.testNoRebalanceDuringCacheStart - 0,0% fails in
last 441 master runs.
{color:#d04437}Continuous Query 4{color} [[tests
13|https://ci.ignite.apache.org/viewLog.html?buildId=3204670]]
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterMvcc - 0,2%
fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterMvccTxSyncFilter
- 0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterMvccTx -
0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedSyncFilterMvcc
- 0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInListenerReplicatedJCacheApiMvcc
- 0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterReplicatedJCacheApiMvcc
- 0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInListenerMvcc -
0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryAsyncFilterListenerTest.testNonDeadLockInFilterMvccTxJCacheApi
- 0,0% fails in last 436 master runs.
* IgniteCacheQuerySelfTestSuite6:
[jira] [Commented] (IGNITE-11437) Start grid in remote JVM in test framework fails if TDE is enabled
[
https://issues.apache.org/jira/browse/IGNITE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781533#comment-16781533
]
Aleksey Plekhanov commented on IGNITE-11437:
Fields {{aesWithPadding}} and {{aesWithoutPadding}} are static now. It's safe
because all usages of derived from this fields ciphers are stateless inside one
thread.
Reproducer is passed without error (locally). No new tests were added to this
patch, but new tests with multi JVM and TDE will be added by ticket
IGNITE-11336 (currently in progress).
[~NIzhikov] could you please review the patch?
> Start grid in remote JVM in test framework fails if TDE is enabled
> --
>
> Key: IGNITE-11437
> URL: https://issues.apache.org/jira/browse/IGNITE-11437
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we start grid in remote JVM with enabled TDE, it fails with exception:
> {noformat}
> java.lang.NullPointerException
> at
> java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:284)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> org.apache.ignite.spi.encryption.keystore.KeystoreEncryptionSpi.encrypt(KeystoreEncryptionSpi.java:211){noformat}
> Test framework uses {{XStream}} to pass Ignite configuration to remote JVM.
> {{XStream}} cannot serialize lamda expression and replace lambda with
> {{null}}. So, after deserialization {{ThreadLocal}} object has {{supplier ==
> null}}.
> Reproducer:
> {code:java}
> public class TdeTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String gridName)
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> KeystoreEncryptionSpi encSpi = new KeystoreEncryptionSpi();
> encSpi.setKeyStorePath(AbstractEncryptionTest.KEYSTORE_PATH);
>
> encSpi.setKeyStorePassword(AbstractEncryptionTest.KEYSTORE_PASSWORD.toCharArray());
> cfg.setEncryptionSpi(encSpi);
> cfg.setCacheConfiguration(new
> CacheConfiguration().setName("cache").setEncryptionEnabled(true));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> @Test
> public void testTdeMultiJvm() throws Exception {
> startGrids(2);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11437) Start grid in remote JVM in test framework fails if TDE is enabled
[
https://issues.apache.org/jira/browse/IGNITE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781518#comment-16781518
]
Ignite TC Bot commented on IGNITE-11437:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3202625buildTypeId=IgniteTests24Java8_RunAll]
> Start grid in remote JVM in test framework fails if TDE is enabled
> --
>
> Key: IGNITE-11437
> URL: https://issues.apache.org/jira/browse/IGNITE-11437
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we start grid in remote JVM with enabled TDE, it fails with exception:
> {noformat}
> java.lang.NullPointerException
> at
> java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:284)
> at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
> at java.lang.ThreadLocal.get(ThreadLocal.java:170)
> at
> org.apache.ignite.spi.encryption.keystore.KeystoreEncryptionSpi.encrypt(KeystoreEncryptionSpi.java:211){noformat}
> Test framework uses {{XStream}} to pass Ignite configuration to remote JVM.
> {{XStream}} cannot serialize lamda expression and replace lambda with
> {{null}}. So, after deserialization {{ThreadLocal}} object has {{supplier ==
> null}}.
> Reproducer:
> {code:java}
> public class TdeTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String gridName)
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> KeystoreEncryptionSpi encSpi = new KeystoreEncryptionSpi();
> encSpi.setKeyStorePath(AbstractEncryptionTest.KEYSTORE_PATH);
>
> encSpi.setKeyStorePassword(AbstractEncryptionTest.KEYSTORE_PASSWORD.toCharArray());
> cfg.setEncryptionSpi(encSpi);
> cfg.setCacheConfiguration(new
> CacheConfiguration().setName("cache").setEncryptionEnabled(true));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> @Test
> public void testTdeMultiJvm() throws Exception {
> startGrids(2);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11210) SQL: Introduce common logical execution plan for all query types
[
https://issues.apache.org/jira/browse/IGNITE-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781529#comment-16781529
]
Vladimir Ozerov commented on IGNITE-11210:
--
Scala re-run: https://ci.ignite.apache.org/viewQueued.html?itemId=3209769
> SQL: Introduce common logical execution plan for all query types
>
>
> Key: IGNITE-11210
> URL: https://issues.apache.org/jira/browse/IGNITE-11210
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment we have a lot of various cached stuff used for different SQL
> types (prepared statements for local queries, two-step queries for
> distributed queries, update plan for DML).
> What we need instead of having multiple caches is to create common execution
> plan for every query, which will hold both DML and SELECT stuff. Approximate
> content of such a plan:
> # Two-step plan
> # DML plan
> # Partition pruning stuff
> # May be even cached physical node distribution (for reduce queries) for the
> given {{AffinityTopologyVersion}}
> # Probably {{AffinityTopologyVersion}}
> Then we will perform a single plan lookup/build per every query execution. In
> future we will probably display these plans in SQL views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8178) ZookeeperDiscoverySpiTest#testReconnectServersRestart* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781510#comment-16781510
]
Amelchev Nikita commented on IGNITE-8178:
-
I have investigated tests and fix the next bugs:
1. Assertion error in the GridDhtPartitionsExchangeFuture. The future
initialization can be interrupted by client reconnection.
2. NPE in ZookeeperDiscoveryImpl.java#allNodesSupport. rtState can be null.
3. The client reconnect listener in theZookeeperDiscoverySpiTestBase.java
return false that lead to removing it and test's assert fails on topology
checks.
4. Client's session close. Can be reproduced locally rarely. I have increased
session timeout for the test.
5. Assertion error in
MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541). I have
filed ticket IGNITE-11460 for this issue.
I have tested more than 100 times on TC and locally and now it looks good.
[~sergey-chugunov], Could you help with review, please?
> ZookeeperDiscoverySpiTest#testReconnectServersRestart* tests fail on TC
> ---
>
> Key: IGNITE-8178
> URL: https://issues.apache.org/jira/browse/IGNITE-8178
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> The following stack trace appears in logs:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGridsMultiThreaded(GridAbstractTest.java:710)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:507)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:497)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectServersRestart(ZookeeperDiscoverySpiTest.java:3513)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testReconnectServersRestart_1(ZookeeperDiscoverySpiTest.java:3498)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite,
> zkConnectionString=127.0.0.1:46237,127.0.0.1:38364,127.0.0.1:45674,
> joinTimeout=0, sesTimeout=1, clientReconnectDisabled=false,
> internalLsnr=null]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 24 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize Zookeeper nodes
[jira] [Updated] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
[
https://issues.apache.org/jira/browse/IGNITE-11460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-11460:
-
Labels: MakeTeamcityGreenAgain (was: )
> MVCC: Possible race on coordinator changing on client reconnection.
> ---
>
> Key: IGNITE-11460
> URL: https://issues.apache.org/jira/browse/IGNITE-11460
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> I found that the wrong coordinator can be set in case of client reconnect:
> {noformat}
> assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I have attached reproducer in PR.
> The main reason is that coordinator can be changed from discovery event
> thread when the client already disconnect (disconnection processed in
> notifier thread and change coordinator on onDisconnected method).
> Coordinator can be changed in cases:
> 1. notifier disco thread: onDisconnected method
> 2. event disco thread: onDiscovery listener.
> and events can be processed with some delay and override coordinator that set
> in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11245) Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT parameter.
[ https://issues.apache.org/jira/browse/IGNITE-11245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781512#comment-16781512 ] Andrey Kalinin commented on IGNITE-11245: - [~v.pyatkov], this scenario is fully covered by _*BinaryMetadataConcurrentUpdateWithIndexesTest*_ written by [~ascherbakov] on IGNITE-9830. > Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT parameter. > --- > > Key: IGNITE-11245 > URL: https://issues.apache.org/jira/browse/IGNITE-11245 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Stanilovsky Evgeny >Assignee: Andrey Kalinin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Replace unused IGNITE_BINARY_META_UPDATE_TIMEOUT with > IGNITE_WAIT_SCHEMA_UPDATE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11460) MVCC: Possible race on coordinator changing on client reconnection.
Amelchev Nikita created IGNITE-11460:
Summary: MVCC: Possible race on coordinator changing on client
reconnection.
Key: IGNITE-11460
URL: https://issues.apache.org/jira/browse/IGNITE-11460
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
Fix For: 2.8
I found that the wrong coordinator can be set in case of client reconnect:
{noformat}
assert newCrd.topologyVersion().compareTo(curCrd.topologyVersion()) > 0;
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorChanged(MvccProcessorImpl.java:541)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onLocalJoin(MvccProcessorImpl.java:416)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:851)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2681)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2719)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
I have attached reproducer in PR.
The main reason is that coordinator can be changed from discovery event thread
when the client already disconnect (disconnection processed in notifier thread
and change coordinator on onDisconnected method).
Coordinator can be changed in cases:
1. notifier disco thread: onDisconnected method
2. event disco thread: onDiscovery listener.
and events can be processed with some delay and override coordinator that set
in notifier thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11210) SQL: Introduce common logical execution plan for all query types
[
https://issues.apache.org/jira/browse/IGNITE-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781507#comment-16781507
]
Ignite TC Bot commented on IGNITE-11210:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Examples){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3199660]]
* ScalarSelfTestSuite: ScalarProjectionSpec.ScalarProjectionPimp class should
return shown nodes - 0,0% fails in last 440 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3199740buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Introduce common logical execution plan for all query types
>
>
> Key: IGNITE-11210
> URL: https://issues.apache.org/jira/browse/IGNITE-11210
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment we have a lot of various cached stuff used for different SQL
> types (prepared statements for local queries, two-step queries for
> distributed queries, update plan for DML).
> What we need instead of having multiple caches is to create common execution
> plan for every query, which will hold both DML and SELECT stuff. Approximate
> content of such a plan:
> # Two-step plan
> # DML plan
> # Partition pruning stuff
> # May be even cached physical node distribution (for reduce queries) for the
> given {{AffinityTopologyVersion}}
> # Probably {{AffinityTopologyVersion}}
> Then we will perform a single plan lookup/build per every query execution. In
> future we will probably display these plans in SQL views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8178) ZookeeperDiscoverySpiTest#testReconnectServersRestart* tests fail on TC
[
https://issues.apache.org/jira/browse/IGNITE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781505#comment-16781505
]
Ignite TC Bot commented on IGNITE-8178:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3203497buildTypeId=IgniteTests24Java8_RunAll]
> ZookeeperDiscoverySpiTest#testReconnectServersRestart* tests fail on TC
> ---
>
> Key: IGNITE-8178
> URL: https://issues.apache.org/jira/browse/IGNITE-8178
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> The following stack trace appears in logs:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1698)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1007)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1977)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1148)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:646)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:683)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGridsMultiThreaded(GridAbstractTest.java:710)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:507)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.startGridsMultiThreaded(GridCommonAbstractTest.java:497)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.reconnectServersRestart(ZookeeperDiscoverySpiTest.java:3513)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testReconnectServersRestart_1(ZookeeperDiscoverySpiTest.java:3498)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite,
> zkConnectionString=127.0.0.1:46237,127.0.0.1:38364,127.0.0.1:45674,
> joinTimeout=0, sesTimeout=1, clientReconnectDisabled=false,
> internalLsnr=null]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:905)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1693)
> ... 24 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize Zookeeper nodes
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.initZkNodes(ZookeeperDiscoveryImpl.java:827)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoin(ZookeeperDiscoveryImpl.java:957)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:775)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:693)
> at
>
[jira] [Commented] (IGNITE-11258) JDBC Thin: update connection setup logic.
[
https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781502#comment-16781502
]
Ignite TC Bot commented on IGNITE-11258:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3200367buildTypeId=IgniteTests24Java8_RunAll]
> JDBC Thin: update connection setup logic.
> -
>
> Key: IGNITE-11258
> URL: https://issues.apache.org/jira/browse/IGNITE-11258
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-23
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> # On thin client startup it connects to *all* *nodes* provided by user by
> client configuration.
> # Upon handshake server returns its UUID to client.
> # By the end of the startup procedure, client have open connections to all
> available server nodes and the following mapping (*nodeMap*): [UUID =>
> Connection].
> Connection to all nodes helps to identify available nodes, but can lead to
> significant delay, when thin client is used on a large cluster with a long IP
> list provided by user. To lower this delay, asynchronous establishment of
> connections can be used.
> For more information see [IEP-23: Best Effort
> Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11424) Cannot build C++ from tarball of master branch
[
https://issues.apache.org/jira/browse/IGNITE-11424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781497#comment-16781497
]
Taras Ledkov commented on IGNITE-11424:
---
[~isapego], the patch is OK with me.
> Cannot build C++ from tarball of master branch
> --
>
> Key: IGNITE-11424
> URL: https://issues.apache.org/jira/browse/IGNITE-11424
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Ilya Kasnacheev
>Assignee: Igor Sapego
>Priority: Blocker
> Labels: C++
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a tarball made by mvn initialize -Prelease on fresh master branch:
> {code}
> % libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> libtoolize: putting auxiliary files in '.'.
> libtoolize: linking file './ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> libtoolize: linking file 'm4/libtool.m4'
> libtoolize: linking file 'm4/ltoptions.m4'
> libtoolize: linking file 'm4/ltsugar.m4'
> libtoolize: linking file 'm4/ltversion.m4'
> libtoolize: linking file 'm4/lt~obsolete.m4'
> configure.ac:36: installing './ar-lib'
> configure.ac:35: installing './compile'
> configure.ac:24: installing './config.guess'
> configure.ac:24: installing './config.sub'
> configure.ac:28: installing './install-sh'
> configure.ac:28: installing './missing'
> configure.ac:88: error: required file 'network/include/Makefile.in' not found
> configure.ac:88: error: required file 'network/Makefile.in' not found
> Makefile.am:27: error: required directory ./network does not exist
> Makefile.am:22: error: required directory ./network does not exist
> Makefile.am:51: error: required directory ./network does not exist
> binary/Makefile.am: installing './depcomp'
> {code}
> Indeed it seems that network/ does not exist
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10607) Add progress-bar component
[ https://issues.apache.org/jira/browse/IGNITE-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10607: -- Ignite Flags: (was: Docs Required) > Add progress-bar component > -- > > Key: IGNITE-10607 > URL: https://issues.apache.org/jira/browse/IGNITE-10607 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Major > > Currently we have a progress-line primitive which allows to indicate whether > a progress is active or not. > But we also need a progress bar with will indicates a percentage of progress > using progress line and show percentage. > Let's implement one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10607) Add progress-bar component
[ https://issues.apache.org/jira/browse/IGNITE-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10607: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Add progress-bar component > -- > > Key: IGNITE-10607 > URL: https://issues.apache.org/jira/browse/IGNITE-10607 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexey Kuznetsov >Priority: Major > > Currently we have a progress-line primitive which allows to indicate whether > a progress is active or not. > But we also need a progress bar with will indicates a percentage of progress > using progress line and show percentage. > Let's implement one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
