[jira] [Updated] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13216: - Description: (was: If "name" parameter is set it should be used instead of actual field name. Currently if 2 @QuerySqlField fields have same names we will receive error, even if they have different "name" properties.) > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12561) SQL: Fix incorrect check for conflict of field names in key and value.
[
https://issues.apache.org/jira/browse/IGNITE-12561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeniy Rudenko updated IGNITE-12561:
-
Release Note: Added validation of the uniqueness of field's name annotated
with @QuerySqlEntity. Previously cache could be started without errors, but the
key's field would not be queryable:
> SQL: Fix incorrect check for conflict of field names in key and value.
> --
>
> Key: IGNITE-12561
> URL: https://issues.apache.org/jira/browse/IGNITE-12561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeniy Rudenko
>Assignee: Evgeniy Rudenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If key and value types of an SQL-enabled cache have the same fields annotated
> with `@QuerySqlEntity` the cache will start without errors but the key's
> field will not be queryable:
> {noformat}
> // here, you can't query Key.a via SQL
> class Key {
>@QuerySqlField int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
>
> To workaround that, one needs to specify a different name for one of the `a`
> fields:
> {noformat}
> class Key {
>@QuerySqlField(name = "key_a") int a;
>@QuerySqlField int b;
> }
> class Value {
>@QuerySqlField int a;
>@QuerySqlField int c;
> }
> {noformat}
> The first configuration is obviously incorrect - one can't use the `Key.a` in
> SQL but annotates it as queryable. We need to issue an error or at least a
> warning for starting a configuration like this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13223) empty Batch throw an Exception
[ https://issues.apache.org/jira/browse/IGNITE-13223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 底限 reassigned IGNITE-13223: --- Assignee: 底限 > empty Batch throw an Exception > --- > > Key: IGNITE-13223 > URL: https://issues.apache.org/jira/browse/IGNITE-13223 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.7.6 >Reporter: 底限 >Assignee: 底限 >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153103#comment-17153103 ] Sergey Stronchinskiy commented on IGNITE-7369: -- [~ptupitsyn] Thank you! > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13214) .NET different behavior when using TransactionScope and ITransactions.Start
[
https://issues.apache.org/jira/browse/IGNITE-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153101#comment-17153101
]
Ignite TC Bot commented on IGNITE-13214:
{panel:title=Branch: [pull/8004/head] Base: [master] : Possible Blockers
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=5446863]]
{color:#d04437}PDS 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5446855]]
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446842]]
* IgniteCacheWithIndexingTestSuite:
GridCacheSqlDdlClusterReadOnlyModeTest.testAlterTableAllowed - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Streamers{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446805]]
* IgniteKafkaStreamerSelfTestSuite:
IgniteSinkConnectorTest.testSinkPutsWithTransformation - Test has low fail rate
in base branch 1,3% and is not flaky
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446802]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicEnableIndexingBasicSelfTest.testEnableDynamicIndexing[hasNear=false,nodeIdx=2,cacheMode=REPLICATED,atomicityMode=ATOMIC]
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 1{color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=5446838]]
* IgniteBinaryCacheTestSuite: GridCacheStopSelfTest.testStopMultithreaded -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopImplicitTransactions - Test has low fail rate in
base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopExplicitTransactionsReplicated - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopExplicitTransactions - Test has low fail rate in
base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopImplicitTransactionsReplicated - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite: GridCacheStopSelfTest.testStopAtomic - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopImplicitMvccTransactionsReplicated - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
GridCacheStopSelfTest.testStopImplicitMvccTransactions - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite: internal.IgniteInternalCacheRemoveTest - History
for base branch is absent.
* IgniteBinaryCacheTestSuite: cache.GridCacheKeyCheckNearEnabledSelfTest -
History for base branch is absent.
* IgniteBinaryCacheTestSuite: cache.GridCacheKeyCheckSelfTest - History for
base branch is absent.
... and 0 tests blockers
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446845]]
* IgniteCacheTestSuite8:
GridCacheAtomicPartitionedTckMetricsSelfTestImpl.testGetMetricsDisable - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446873]]
* IgniteCacheMvccTestSuite1: CacheFutureExceptionSelfTest.testAsyncCacheFuture
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8004/head] Base: [master] : New Tests
(20)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#8b}PDS (Indexing){color} [tests 4]
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullAndClientJoin -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testMultipleNodesFailHistoricalRebalance - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullDueToFailOnCreatingWalIterator
- PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullWhileIteratingOverWAL
- PASSED{color}
{color:#8b}Platform .NET (Long Running){color} [tests 3]
* {color:#013220}exe:
CacheAbstractTransactionalTest.TestTransactionScopeWithSerializableIsolationLocksKeysOnRead
- PASSED{color}
* {color:#013220}exe:
CacheAbstractTransactionalTest.TestTransactionScopeWithSerializableIsolationLocksKeysOnRead
- PASSED{color}
* {color:#013220}exe:
CacheAbstractTransactionalTest.TestTransactionScopeWithSerializableIsolationLocksKeysOnRead
- PASSED{color}
{color:#8b}Platform .NET{color} [tests 1]
* {color:#013220}exe:
CacheAbstractTransactionalTest.TestTransactionScopeWithSerializableIsola
[jira] [Commented] (IGNITE-13214) .NET different behavior when using TransactionScope and ITransactions.Start
[
https://issues.apache.org/jira/browse/IGNITE-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153080#comment-17153080
]
Sergey Stronchinskiy commented on IGNITE-13214:
---
[~ptupitsyn] Sure, please see my comments on GitHub.
> .NET different behavior when using TransactionScope and ITransactions.Start
>
>
> Key: IGNITE-13214
> URL: https://issues.apache.org/jira/browse/IGNITE-13214
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, transactions
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Next code runs fine:
> {code:c#}
> var barier = new Barrier(2);
> var cache = Cache();
> cache.Put(1, 1);
> var task = Task.Factory.StartNew(() =>
> {
> var otherCache = Cache();
> barier.SignalAndWait();
> otherCache.Put(1, 10);
> barier.SignalAndWait();
> });
> using (var txscp = new
> TransactionScope(TransactionScopeOption.Required, new
> TransactionOptions{IsolationLevel = IsolationLevel.Serializable}))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> txscp.Complete();
> }
> Task.WaitAll(task);
> barier.Dispose();
> {code}
> When I switch to Ignite transactions I get exception:
> {code:c#}
> using (var tx =
> Transactions.TxStart(TransactionConcurrency.Optimistic,
> TransactionIsolation.Serializable))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> tx.Commit();
> }
> {code}
> {noformat}
> Apache.Ignite.Core.Transactions.TransactionOptimisticException : Failed to
> prepare transaction (lock conflict): GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [],
> {noformat}
> _Cache_ is _IIgnite.Cache()_ and _Transactions_ is
> _IIgnite.GetTransactions()_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13226) .NET: Thin Client Compute leaks ClientNotificationHandler instances
[
https://issues.apache.org/jira/browse/IGNITE-13226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153072#comment-17153072
]
Sergey Stronchinskiy commented on IGNITE-13226:
---
[~ptupitsyn] looks fine to me!
> .NET: Thin Client Compute leaks ClientNotificationHandler instances
> ---
>
> Key: IGNITE-13226
> URL: https://issues.apache.org/jira/browse/IGNITE-13226
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In multithreaded thin client compute scenarios there is a possibility for
> ClientNotificationHandler leak: handlers remain in
> ClientSocket._notificationListeners even after corresponding tasks have
> completed.
> To reproduce, add the following code at the end of
> ComputeClientTests.TestExecuteJavaTaskAsyncMultithreaded:
> {code}
> var failoverSocket =
> TestUtils.GetPrivateField(client, "_socket");
> var socket =
> TestUtils.GetPrivateField(failoverSocket, "_socket");
> var listeners = TestUtils.GetPrivateField(socket,
> "_notificationListeners");
> Assert.IsEmpty(listeners);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13227) AssertionError on getting cache size from the mbean on the inactive cluster
Amelchev Nikita created IGNITE-13227:
Summary: AssertionError on getting cache size from the mbean on
the inactive cluster
Key: IGNITE-13227
URL: https://issues.apache.org/jira/browse/IGNITE-13227
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The reproducer for {{CacheMetricsManageTest}}:
{noformat}
/** @throws Exception If failed. */
@Test
public void testCacheSize() throws Exception {
persistence = true;
startGrid(0);
CacheMetricsMXBean mxBean = mxBean(0, CACHE1,
CacheClusterMetricsMXBeanImpl.class);
long size = mxBean.getCacheSize();
assertEquals(0, size);
}
{noformat}
AssertionError:
{noformat}
java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:794)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:771)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:697)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.cacheData(IgniteCacheOffheapManagerImpl.java:431)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.cacheEntriesCount(IgniteCacheOffheapManagerImpl.java:398)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.localSizeLong(GridDistributedCacheAdapter.java:284)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.localSize(GridCacheAdapter.java:4151)
at
org.apache.ignite.internal.processors.cache.CacheMetricsImpl.getEntriesStat(CacheMetricsImpl.java:1272)
at
org.apache.ignite.internal.processors.cache.CacheMetricsSnapshotV2.(CacheMetricsSnapshotV2.java:375)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3546)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.clusterMetrics(GridCacheAdapter.java:3540)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.clusterMetrics(GridCacheAdapter.java:3522)
at
org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl.getCacheSize(CacheClusterMetricsMXBeanImpl.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
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 sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at
com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
at
com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
at com.sun.proxy.$Proxy30.getCacheSize(Unknown Source)
at
org.apache.ignite.internal.processors.cache.CacheMetricsManageTest.testCacheSize(CacheMetricsManageTest.java:833)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosiv
[jira] [Updated] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-6982: -- Fix Version/s: (was: 2.9) 2.10 > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.10 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153043#comment-17153043 ] Aleksey Plekhanov commented on IGNITE-6982: --- [~ashapkin], ok, thank you. Moved to the next release. > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.10 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152983#comment-17152983 ] Alexandr Shapkin commented on IGNITE-6982: -- [~alex_pl], no, it's still in the backlog. I don't think we need it for 2.9 > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.9 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13226) .NET: Thin Client Compute leaks ClientNotificationHandler instances
[
https://issues.apache.org/jira/browse/IGNITE-13226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152980#comment-17152980
]
Ignite TC Bot commented on IGNITE-13226:
{panel:title=Branch: [pull/8003/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446507]]
* IgnitePdsTestSuite4:
ResetLostPartitionTest.testReactivateGridBeforeResetLostPartitions - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446514]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.checkLostPartition[ATOMIC IGNORE 2
true 5 false] - Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5446495]]
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5446473]]
{color:#d04437}Cache (Deadlock Detection){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5446476]]
* TxDeadlockDetectionTestSuite:
TxOptimisticDeadlockDetectionTest.testDeadlocksPartitionedNear - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8003/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [tests 4]
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullAndClientJoin -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testMultipleNodesFailHistoricalRebalance - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullDueToFailOnCreatingWalIterator
- PASSED{color}
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRebalanceTest.testSwitchHistoricalRebalanceToFullWhileIteratingOverWAL
- PASSED{color}
{color:#8b}Queries 1{color} [tests 2]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
QueryEntityValidationSelfTest.testNotUniqueNameInAnnotation - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
QueryEntityValidationSelfTest.testUniqueNameInAnnotation - PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f8236df7-1439-483f-a00f-20c41dec4c72, topVer=0,
nodeId8=1316ee8a, msg=, type=NODE_JOINED, tstamp=1594138329084],
val2=AffinityTopologyVersion [topVer=-3639958942977458018, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=f8236df7-1439-483f-a00f-20c41dec4c72, topVer=0,
nodeId8=1316ee8a, msg=, type=NODE_JOINED, tstamp=1594138329084],
val2=AffinityTopologyVersion [topVer=-3639958942977458018, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e52861a2371-46cf0102-5dd2-43ab-8b44-657a3e304fde, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=548b58b6-53f7-4964-9b54-ab6b80281089, topVer=0, nodeId8=548b58b6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594138329084]],
val2=AffinityTopologyVersion [topVer=-4849584122826975164, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e52861a2371-46cf0102-5dd2-43ab-8b44-657a3e304fde, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=548b58b6-53f7-4964-9b54-ab6b80281089, topVer=0, nodeId8=548b58b6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594138329084]],
val2=AffinityTopologyVersion [topVer=-4849584122826975164, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=07100f3c-2238-4b38-901e-7d3543449ec5, topVer=0,
nodeId8=b879cf82, msg=, type=NODE_JOINED, tstamp=1594138975529],
val2=AffinityTopologyVersion [topVer=1806221681363858205, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=Ser
[jira] [Commented] (IGNITE-11591) Add info about lock candidates that are ahead in queue to transaction timeout error message
[
https://issues.apache.org/jira/browse/IGNITE-11591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152923#comment-17152923
]
Stanilovsky Evgeny commented on IGNITE-11591:
-
[~zzzadruga] check it [1], may be it would be enough ? Or you can proceed with
improvements from mentioned ticket.
[1]https://issues.apache.org/jira/browse/IGNITE-11591
> Add info about lock candidates that are ahead in queue to transaction timeout
> error message
> ---
>
> Key: IGNITE-11591
> URL: https://issues.apache.org/jira/browse/IGNITE-11591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Nikolai Kulagin
>Priority: Major
> Fix For: 2.9
>
>
> If transaction is timed out due to lock acquisition failure, corresponding
> error will show up in server log on DHT (primary) node:
> {code:java}
> [2019-03-20
> 21:13:10,831][ERROR][grid-timeout-worker-#23%transactions.TxRollbackOnTimeoutTest0%][GridDhtColocatedCache]
> Failed to acquire lock for request: GridNearLockRequest
> [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], miniId=1,
> dhtVers=GridCacheVersion[] [null],
> subjId=651a30e1-45ac-4b35-86d2-028d1f81d8dc, taskNameHash=0, createTtl=-1,
> accessTtl=-1, flags=6, txLbl=null, filter=null,
> super=GridDistributedLockRequest
> [nodeId=651a30e1-45ac-4b35-86d2-028d1f81d8dc, nearXidVer=GridCacheVersion
> [topVer=164585585, order=1553105588524, nodeOrder=4], threadId=262,
> futId=5967e4c9961-d32ea2a6-1789-47d7-bdbf-aa66e6d8c35b, timeout=890,
> isInTx=true, isInvalidate=false, isRead=false, isolation=REPEATABLE_READ,
> retVals=[false], txSize=2, flags=0, keysCnt=1,
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=164585585,
> order=1553105588524, nodeOrder=4], committedVers=null, rolledbackVers=null,
> cnt=0, super=GridCacheIdMessage [cacheId=3556498
> class
> org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
> Failed to acquire lock within provided timeout for transaction [timeout=890,
> tx=GridDhtTxLocal[xid=f219e4c9961--09cf-6071--0001,
> xidVersion=GridCacheVersion [topVer=164585585, order=1553105588527,
> nodeOrder=1], concurrency=PESSIMISTIC, isolation=REPEATABLE_READ,
> state=MARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c7dccddb-dee1-4499-94b1-03896350, timeout=890, duration=891]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:1766)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:1714)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$2.applyx(GridEmbeddedFuture.java:86)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:292)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:793)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:89)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1189)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:234)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.j
> {code}
> It would be much more useful if this message also contained information about
> transaction that actually owns corresponding lock (or information about all
> transactions that are ahead in queue if there are several).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152913#comment-17152913 ] Maxim Muzafarov commented on IGNITE-11970: -- Hello [~ibelyakov], I've left some comments in the PR. Please, take a look. > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13214) .NET different behavior when using TransactionScope and ITransactions.Start
[
https://issues.apache.org/jira/browse/IGNITE-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13214:
Fix Version/s: 2.9
> .NET different behavior when using TransactionScope and ITransactions.Start
>
>
> Key: IGNITE-13214
> URL: https://issues.apache.org/jira/browse/IGNITE-13214
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, transactions
> Fix For: 2.9
>
>
> Next code runs fine:
> {code:c#}
> var barier = new Barrier(2);
> var cache = Cache();
> cache.Put(1, 1);
> var task = Task.Factory.StartNew(() =>
> {
> var otherCache = Cache();
> barier.SignalAndWait();
> otherCache.Put(1, 10);
> barier.SignalAndWait();
> });
> using (var txscp = new
> TransactionScope(TransactionScopeOption.Required, new
> TransactionOptions{IsolationLevel = IsolationLevel.Serializable}))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> txscp.Complete();
> }
> Task.WaitAll(task);
> barier.Dispose();
> {code}
> When I switch to Ignite transactions I get exception:
> {code:c#}
> using (var tx =
> Transactions.TxStart(TransactionConcurrency.Optimistic,
> TransactionIsolation.Serializable))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> tx.Commit();
> }
> {code}
> {noformat}
> Apache.Ignite.Core.Transactions.TransactionOptimisticException : Failed to
> prepare transaction (lock conflict): GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [],
> {noformat}
> _Cache_ is _IIgnite.Cache()_ and _Transactions_ is
> _IIgnite.GetTransactions()_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13214) .NET different behavior when using TransactionScope and ITransactions.Start
[
https://issues.apache.org/jira/browse/IGNITE-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-13214:
---
Assignee: Pavel Tupitsyn
> .NET different behavior when using TransactionScope and ITransactions.Start
>
>
> Key: IGNITE-13214
> URL: https://issues.apache.org/jira/browse/IGNITE-13214
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, transactions
>
> Next code runs fine:
> {code:c#}
> var barier = new Barrier(2);
> var cache = Cache();
> cache.Put(1, 1);
> var task = Task.Factory.StartNew(() =>
> {
> var otherCache = Cache();
> barier.SignalAndWait();
> otherCache.Put(1, 10);
> barier.SignalAndWait();
> });
> using (var txscp = new
> TransactionScope(TransactionScopeOption.Required, new
> TransactionOptions{IsolationLevel = IsolationLevel.Serializable}))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> txscp.Complete();
> }
> Task.WaitAll(task);
> barier.Dispose();
> {code}
> When I switch to Ignite transactions I get exception:
> {code:c#}
> using (var tx =
> Transactions.TxStart(TransactionConcurrency.Optimistic,
> TransactionIsolation.Serializable))
> {
> var before = cache.Get(1);
> barier.SignalAndWait();
> barier.SignalAndWait();
> tx.Commit();
> }
> {code}
> {noformat}
> Apache.Ignite.Core.Transactions.TransactionOptimisticException : Failed to
> prepare transaction (lock conflict): GridNearTxLocal
> [mappings=IgniteTxMappingsImpl [],
> {noformat}
> _Cache_ is _IIgnite.Cache()_ and _Transactions_ is
> _IIgnite.GetTransactions()_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152863#comment-17152863 ] Pavel Tupitsyn commented on IGNITE-7369: [~GuruStron] I've done a preliminary review, please see my comments on GitHub > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13226) .NET: Thin Client Compute leaks ClientNotificationHandler instances
[
https://issues.apache.org/jira/browse/IGNITE-13226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152842#comment-17152842
]
Pavel Tupitsyn commented on IGNITE-13226:
-
[~GuruStron] can you please review?
> .NET: Thin Client Compute leaks ClientNotificationHandler instances
> ---
>
> Key: IGNITE-13226
> URL: https://issues.apache.org/jira/browse/IGNITE-13226
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In multithreaded thin client compute scenarios there is a possibility for
> ClientNotificationHandler leak: handlers remain in
> ClientSocket._notificationListeners even after corresponding tasks have
> completed.
> To reproduce, add the following code at the end of
> ComputeClientTests.TestExecuteJavaTaskAsyncMultithreaded:
> {code}
> var failoverSocket =
> TestUtils.GetPrivateField(client, "_socket");
> var socket =
> TestUtils.GetPrivateField(failoverSocket, "_socket");
> var listeners = TestUtils.GetPrivateField(socket,
> "_notificationListeners");
> Assert.IsEmpty(listeners);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12843) TDE Phase-3. Cache key rotation.
[ https://issues.apache.org/jira/browse/IGNITE-12843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-12843: -- Description: Add the ability to rotate (change) the cache group encryption key. The design is described here: [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Description] h3. Additional notes about binary format changes. h4. PageMetaIO and PagePartitionMetaIO format Reencryption status requires an additional 8 bytes on the meta page of each partition. Index partition uses PageMetaIO to read/write meta information. Each other partition uses PagePartitionMetaIO to read/write meta information. Partition meta starts just after the end of the page meta. To store additional 8 bytes partition meta shifted by 8 bytes. WAL delta records have also been modified to store reencryption status. h4. Encrypted page format Each encrypted page has reserved free space to store CRC of encrypted data. The size of this free space depends on the size of the encryption block, but cannot be less than 8 bytes (Ignite default encryption implementation (KeystoreEncryptionSpi) uses AES with 16 bytes block size). Added 1 byte for encryption key ID on each encrypted page (after CRC). (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed accordingly) was: Add the ability to rotate (change) the cache group encryption key. The design is described here: [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Processdescription] h3. Additional notes about binary format changes. h4. PageMetaIO and PagePartitionMetaIO format Reencryption status requires an additional 8 bytes on the meta page of each partition. Index partition uses PageMetaIO to read/write meta information. Each other partition uses PagePartitionMetaIO to read/write meta information. Partition meta starts just after the end of the page meta. To store additional 8 bytes partition meta shifted by 8 bytes. WAL delta records have also been modified to store reencryption status. h4. Encrypted page format Each encrypted page has reserved free space to store CRC of encrypted data. The size of this free space depends on the size of the encryption block, but cannot be less than 8 bytes (Ignite default encryption implementation (KeystoreEncryptionSpi) uses AES with 16 bytes block size). Added 1 byte for encryption key ID on each encrypted page (after CRC). (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed accordingly) > TDE Phase-3. Cache key rotation. > > > Key: IGNITE-12843 > URL: https://issues.apache.org/jira/browse/IGNITE-12843 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: IEP-18 > Time Spent: 10m > Remaining Estimate: 0h > > Add the ability to rotate (change) the cache group encryption key. > The design is described here: > [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase3.Cachekeyrotation.-Description] > h3. Additional notes about binary format changes. > h4. PageMetaIO and PagePartitionMetaIO format > Reencryption status requires an additional 8 bytes on the meta page of each > partition. > Index partition uses PageMetaIO to read/write meta information. > Each other partition uses PagePartitionMetaIO to read/write meta information. > Partition meta starts just after the end of the page meta. > To store additional 8 bytes partition meta shifted by 8 bytes. > WAL delta records have also been modified to store reencryption status. > h4. Encrypted page format > Each encrypted page has reserved free space to store CRC of encrypted data. > The size of this free space depends on the size of the encryption block, but > cannot be less than 8 bytes (Ignite default encryption implementation > (KeystoreEncryptionSpi) uses AES with 16 bytes block size). > Added 1 byte for encryption key ID on each encrypted page (after CRC). > (WAL records ENCRYPTED_RECORD and ENCRYPTED_DATA_RECORD have been changed > accordingly) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11591) Add info about lock candidates that are ahead in queue to transaction timeout error message
[
https://issues.apache.org/jira/browse/IGNITE-11591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152802#comment-17152802
]
Aleksey Plekhanov commented on IGNITE-11591:
[~zzzadruga] any progress here? Do we have a chance to resolve this ticket in
2.9 release?
> Add info about lock candidates that are ahead in queue to transaction timeout
> error message
> ---
>
> Key: IGNITE-11591
> URL: https://issues.apache.org/jira/browse/IGNITE-11591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Nikolai Kulagin
>Priority: Major
> Fix For: 2.9
>
>
> If transaction is timed out due to lock acquisition failure, corresponding
> error will show up in server log on DHT (primary) node:
> {code:java}
> [2019-03-20
> 21:13:10,831][ERROR][grid-timeout-worker-#23%transactions.TxRollbackOnTimeoutTest0%][GridDhtColocatedCache]
> Failed to acquire lock for request: GridNearLockRequest
> [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0], miniId=1,
> dhtVers=GridCacheVersion[] [null],
> subjId=651a30e1-45ac-4b35-86d2-028d1f81d8dc, taskNameHash=0, createTtl=-1,
> accessTtl=-1, flags=6, txLbl=null, filter=null,
> super=GridDistributedLockRequest
> [nodeId=651a30e1-45ac-4b35-86d2-028d1f81d8dc, nearXidVer=GridCacheVersion
> [topVer=164585585, order=1553105588524, nodeOrder=4], threadId=262,
> futId=5967e4c9961-d32ea2a6-1789-47d7-bdbf-aa66e6d8c35b, timeout=890,
> isInTx=true, isInvalidate=false, isRead=false, isolation=REPEATABLE_READ,
> retVals=[false], txSize=2, flags=0, keysCnt=1,
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=164585585,
> order=1553105588524, nodeOrder=4], committedVers=null, rolledbackVers=null,
> cnt=0, super=GridCacheIdMessage [cacheId=3556498
> class
> org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
> Failed to acquire lock within provided timeout for transaction [timeout=890,
> tx=GridDhtTxLocal[xid=f219e4c9961--09cf-6071--0001,
> xidVersion=GridCacheVersion [topVer=164585585, order=1553105588527,
> nodeOrder=1], concurrency=PESSIMISTIC, isolation=REPEATABLE_READ,
> state=MARKED_ROLLBACK, invalidate=false, rollbackOnly=true,
> nodeId=c7dccddb-dee1-4499-94b1-03896350, timeout=890, duration=891]]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:1766)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$PostLockClosure1.apply(IgniteTxLocalAdapter.java:1714)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$2.applyx(GridEmbeddedFuture.java:86)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:292)
> at
> org.apache.ignite.internal.util.future.GridEmbeddedFuture$AsyncListener1.apply(GridEmbeddedFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundIdentityFuture.onDone(GridCacheCompoundIdentityFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:793)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:89)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1189)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:234)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.j
> {code}
> It would be much more useful if this message also contained information about
> transaction that actually owns corresponding lock (or information about all
> transactions that are ahead in queue if there are several).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152794#comment-17152794 ] Aleksey Plekhanov commented on IGNITE-9974: --- [~vveider], [~dmagda] patch looks trivial, I think I can merge it, but let's wait some time for IGNITE-11942 (it has no blockers anymore), perhaps all Hadoop and IGFS code will be removed together with maven assemblies by IGNITE-11942 ticket. > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152787#comment-17152787 ] Denis A. Magda commented on IGNITE-9974: Peter, ask for the review on the dev list. In case nobody checks the changes, Alex Plekhanov or any other committer can merge the patch. > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13226) .NET: Thin Client Compute leaks ClientNotificationHandler instances
Pavel Tupitsyn created IGNITE-13226:
---
Summary: .NET: Thin Client Compute leaks ClientNotificationHandler
instances
Key: IGNITE-13226
URL: https://issues.apache.org/jira/browse/IGNITE-13226
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.9
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.9
In multithreaded thin client compute scenarios there is a possibility for
ClientNotificationHandler leak: handlers remain in
ClientSocket._notificationListeners even after corresponding tasks have
completed.
To reproduce, add the following code at the end of
ComputeClientTests.TestExecuteJavaTaskAsyncMultithreaded:
{code}
var failoverSocket =
TestUtils.GetPrivateField(client, "_socket");
var socket =
TestUtils.GetPrivateField(failoverSocket, "_socket");
var listeners = TestUtils.GetPrivateField(socket,
"_notificationListeners");
Assert.IsEmpty(listeners);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13216: - Release Note: (was: "Name" parameter of QuerySqlField annotation was ignored during uniqueness validation of field's name.) > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > If "name" parameter is set it should be used instead of actual field name. > Currently if 2 @QuerySqlField fields have same names we will receive error, > even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13212) Peer class loading does not work for Scan Query
[
https://issues.apache.org/jira/browse/IGNITE-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13212:
-
Ignite Flags: (was: Release Notes Required)
> Peer class loading does not work for Scan Query
> ---
>
> Key: IGNITE-13212
> URL: https://issues.apache.org/jira/browse/IGNITE-13212
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When a scan query with transformer is executed via API {{IgniteCache::query}}
> and class passed as a transformer is not available on remote nodes, p2p
> mechanism is not triggered and exception is thrown on server nodes executing
> query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13212) Peer class loading does not work for Scan Query
[
https://issues.apache.org/jira/browse/IGNITE-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13212:
-
Component/s: cache
> Peer class loading does not work for Scan Query
> ---
>
> Key: IGNITE-13212
> URL: https://issues.apache.org/jira/browse/IGNITE-13212
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When a scan query with transformer is executed via API {{IgniteCache::query}}
> and class passed as a transformer is not available on remote nodes, p2p
> mechanism is not triggered and exception is thrown on server nodes executing
> query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12622) Forbid mixed cache groups with both atomic and transactional caches
[ https://issues.apache.org/jira/browse/IGNITE-12622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152733#comment-17152733 ] Aleksey Plekhanov commented on IGNITE-12622: [~ivan.glukos], are you working on this ticket? Any estimates? Do we have a chance to include it to 2.9 release? > Forbid mixed cache groups with both atomic and transactional caches > --- > > Key: IGNITE-12622 > URL: https://issues.apache.org/jira/browse/IGNITE-12622 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.9 > > > Apparently it's possible in Ignite to configure a cache group with both > ATOMIC and TRANSACTIONAL caches. > IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* tests. > As per discussed on dev list > (http://apache-ignite-developers.2346864.n4.nabble.com/Forbid-mixed-cache-groups-with-both-atomic-and-transactional-caches-td45586.html), > the community has concluded that such configurations should be prohibited. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152730#comment-17152730 ] Peter Ivanov commented on IGNITE-9974: -- No, I have not. [~dmagda] should have been interested in this issue, but seems no more. > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation
[ https://issues.apache.org/jira/browse/IGNITE-11942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152722#comment-17152722 ] Anton Kalashnikov commented on IGNITE-11942: [~alex_pl] I think I missed the moment when the blocker was resolved. This task is my right now and I will up to date the code at the nearest time. > IGFS and Hadoop Accelerator Discontinuation > --- > > Key: IGNITE-11942 > URL: https://issues.apache.org/jira/browse/IGNITE-11942 > Project: Ignite > Issue Type: Task >Reporter: Denis A. Magda >Assignee: Anton Kalashnikov >Priority: Blocker > Fix For: 2.9 > > > The community has voted for the following decision: > * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and > no longer supported by the community > * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be > removed from Ignite master. Before that, a special branch like > "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to > preserve the sources in Git history for those who might need it. > The voting thread: > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html > Once the changes are made for Ignite 2.8, please contact Denis Magda to > update a public documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152703#comment-17152703 ] Denis Mekhanikov commented on IGNITE-10417: --- [~alex_pl] it doesn't seem that Pavel is working on this issue anymore. The patch is not ready to be merged. [~voropava] can we mark it as open and unassigned, or do you have plans on resuming your work? > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.9 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13199) Apache Ignite Binary Serialization between .NET Core and Java is not working
[ https://issues.apache.org/jira/browse/IGNITE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Paraskeva resolved IGNITE-13199. -- Fix Version/s: (was: 2.9) Resolution: Not A Problem > Apache Ignite Binary Serialization between .NET Core and Java is not working > > > Key: IGNITE-13199 > URL: https://issues.apache.org/jira/browse/IGNITE-13199 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.8.1 > Environment: * OS: Windows 10 10.0 amd64 > * VM information: Java(TM) SE Runtime Environment 11.0.5+10-LTS Oracle > Corporation Java HotSpot(TM) 64-Bit Server VM 11.0.5+10-LTS > * Apache Ignite 2.8.1 version >Reporter: Chris Paraskeva >Priority: Critical > > I have run into issue where I use a group of Apache Ignite (2.8.1) server > nodes in .NET core to create a data grid and run queries to the grid via an > Apache ignite java client. I have not problem at all writing data in binary > mode to the grid and ask queries via the think layer provided. I use DBeaver > to run queries and everything is fine as expected. The issue rise while I am > trying to query data from a java client which complains about a conflict in > cache ": Conflicts during configuration merge for cache MY_CAHE". Find the > error message below: > > Caused by: class org.apache.ignite.spi.IgniteSpiException: Conflicts during > configuration merge for cache 'DOTNET_BINARY_CACHE' : > TRADE conflict: > keyType is different: local=Apache.Ignite.Core.Cache.Affinity.AffinityKey, > received=org.apache.ignite.cache.affinity.AffinityKey > valType is different: > local=Servicing.Agent4.Service.Implementation.Misc.Ignite.Trade, > received=Servicing.Agent4.Core.Java.Models.Trade > > More info can be found on stackoverflow > [https://stackoverflow.com/questions/62675059/apache-ignite-binary-serialization-between-net-core-and-java-is-not-working] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13199) Apache Ignite Binary Serialization between .NET Core and Java is not working
[ https://issues.apache.org/jira/browse/IGNITE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152695#comment-17152695 ] Chris Paraskeva commented on IGNITE-13199: -- It seems the issue was a misconfiguration between .NET and Java, closing issue. > Apache Ignite Binary Serialization between .NET Core and Java is not working > > > Key: IGNITE-13199 > URL: https://issues.apache.org/jira/browse/IGNITE-13199 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.8.1 > Environment: * OS: Windows 10 10.0 amd64 > * VM information: Java(TM) SE Runtime Environment 11.0.5+10-LTS Oracle > Corporation Java HotSpot(TM) 64-Bit Server VM 11.0.5+10-LTS > * Apache Ignite 2.8.1 version >Reporter: Chris Paraskeva >Priority: Critical > Fix For: 2.9 > > > I have run into issue where I use a group of Apache Ignite (2.8.1) server > nodes in .NET core to create a data grid and run queries to the grid via an > Apache ignite java client. I have not problem at all writing data in binary > mode to the grid and ask queries via the think layer provided. I use DBeaver > to run queries and everything is fine as expected. The issue rise while I am > trying to query data from a java client which complains about a conflict in > cache ": Conflicts during configuration merge for cache MY_CAHE". Find the > error message below: > > Caused by: class org.apache.ignite.spi.IgniteSpiException: Conflicts during > configuration merge for cache 'DOTNET_BINARY_CACHE' : > TRADE conflict: > keyType is different: local=Apache.Ignite.Core.Cache.Affinity.AffinityKey, > received=org.apache.ignite.cache.affinity.AffinityKey > valType is different: > local=Servicing.Agent4.Service.Implementation.Misc.Ignite.Trade, > received=Servicing.Agent4.Core.Java.Models.Trade > > More info can be found on stackoverflow > [https://stackoverflow.com/questions/62675059/apache-ignite-binary-serialization-between-net-core-and-java-is-not-working] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13107) ODBC: Memory leak in the tests
[ https://issues.apache.org/jira/browse/IGNITE-13107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152692#comment-17152692 ] Aleksey Plekhanov commented on IGNITE-13107: [~isapego], do we have a chance to resolve this ticket in 2.9 release? > ODBC: Memory leak in the tests > -- > > Key: IGNITE-13107 > URL: https://issues.apache.org/jira/browse/IGNITE-13107 > Project: Ignite > Issue Type: Improvement > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > The memory leak, which is reproducible on TC Windows debug configuration, > have place in case of odce-test unit tests executing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13116) CPP: Can not compile using msvc 14.1
[ https://issues.apache.org/jira/browse/IGNITE-13116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152691#comment-17152691 ] Aleksey Plekhanov commented on IGNITE-13116: [~isapego], do we have a chance to resolve this ticket in 2.9 release? > CPP: Can not compile using msvc 14.1 > > > Key: IGNITE-13116 > URL: https://issues.apache.org/jira/browse/IGNITE-13116 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > There are linking errors when trying to build Ignite C++ with msvc 15. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13174) C++: Add Windows support to CMake build system
[ https://issues.apache.org/jira/browse/IGNITE-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152688#comment-17152688 ] Aleksey Plekhanov commented on IGNITE-13174: [~isapego], do we have a chance to resolve this ticket in 2.9 release? > C++: Add Windows support to CMake build system > -- > > Key: IGNITE-13174 > URL: https://issues.apache.org/jira/browse/IGNITE-13174 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9 > > > Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need > make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13199) Apache Ignite Binary Serialization between .NET Core and Java is not working
[ https://issues.apache.org/jira/browse/IGNITE-13199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152686#comment-17152686 ] Aleksey Plekhanov commented on IGNITE-13199: [~cparaskeva] I see your ticket was answered and the answer was accepted on StackOwerflow, looks like it's not an Ignite bug. Can we close it? > Apache Ignite Binary Serialization between .NET Core and Java is not working > > > Key: IGNITE-13199 > URL: https://issues.apache.org/jira/browse/IGNITE-13199 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.8.1 > Environment: * OS: Windows 10 10.0 amd64 > * VM information: Java(TM) SE Runtime Environment 11.0.5+10-LTS Oracle > Corporation Java HotSpot(TM) 64-Bit Server VM 11.0.5+10-LTS > * Apache Ignite 2.8.1 version >Reporter: Chris Paraskeva >Priority: Critical > Fix For: 2.9 > > > I have run into issue where I use a group of Apache Ignite (2.8.1) server > nodes in .NET core to create a data grid and run queries to the grid via an > Apache ignite java client. I have not problem at all writing data in binary > mode to the grid and ask queries via the think layer provided. I use DBeaver > to run queries and everything is fine as expected. The issue rise while I am > trying to query data from a java client which complains about a conflict in > cache ": Conflicts during configuration merge for cache MY_CAHE". Find the > error message below: > > Caused by: class org.apache.ignite.spi.IgniteSpiException: Conflicts during > configuration merge for cache 'DOTNET_BINARY_CACHE' : > TRADE conflict: > keyType is different: local=Apache.Ignite.Core.Cache.Affinity.AffinityKey, > received=org.apache.ignite.cache.affinity.AffinityKey > valType is different: > local=Servicing.Agent4.Service.Implementation.Misc.Ignite.Trade, > received=Servicing.Agent4.Core.Java.Models.Trade > > More info can be found on stackoverflow > [https://stackoverflow.com/questions/62675059/apache-ignite-binary-serialization-between-net-core-and-java-is-not-working] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13219) Slf4jLogger does not implement the LoggerNodeIdAware interface.
[
https://issues.apache.org/jira/browse/IGNITE-13219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152676#comment-17152676
]
Aleksey Plekhanov commented on IGNITE-13219:
[~liyuj], as far as I understand - the only goal you want to achieve by this
patch is to set some system property. This looks like some user-specific case
and I'm not sure that we should change Ignite for this scenario. It can be
easily implemented in user code. Another reason why we shouldn't do it in
Ignite - in general, there can be several Ignite nodes inside one JVM and the
system property will be overwritten in this case with unpredictable to logger
results.
> Slf4jLogger does not implement the LoggerNodeIdAware interface.
> ---
>
> Key: IGNITE-13219
> URL: https://issues.apache.org/jira/browse/IGNITE-13219
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.8.1
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Minor
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the scenario of ignite + slf4j + log4j2, the generated log file is named
> ignite-${sys:nodeId}.log, The reason for this problem is that Slf4jLogger
> does not implement the
> LoggerNodeIdAware interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13217) Partition loss detection is not working if a dynamic cache is not started on a client.
[
https://issues.apache.org/jira/browse/IGNITE-13217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152658#comment-17152658
]
Sergey Uttsel edited comment on IGNITE-13217 at 7/7/20, 11:08 AM:
--
Test IgniteCacheTestSuite2:
IgniteNearClientCacheCloseTest.testNearCacheCloseTx2
([https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7884386686156266266&tab=testDetails&branch_IgniteTests24Java8=pull%2F7994%2Fhead])
failed because this ticket depends on
https://issues.apache.org/jira/browse/IGNITE-13171
was (Author: sergey uttsel):
Test IgniteCacheTestSuite2:
IgniteNearClientCacheCloseTest.testNearCacheCloseTx2
([https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7884386686156266266&tab=testDetails&branch_IgniteTests24Java8=pull%2F7994%2Fhead])
failed because this ticket depends on
https://issues.apache.org/jira/browse/IGNITE-132171
> Partition loss detection is not working if a dynamic cache is not started on
> a client.
> --
>
> Key: IGNITE-13217
> URL: https://issues.apache.org/jira/browse/IGNITE-13217
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Partition loss detection is not working if dynamic cache is not initialized
> on client.
> WA: get cache proxy on client before data node has left.
> Reproducer:
> {code:java}
> public void test() throws Exception {
> IgniteEx ig = startGrids(2);
> awaitPartitionMapExchange();
> IgniteCache cache = ig.getOrCreateCache(new
> CacheConfiguration<>("testtest").setPartitionLossPolicy(PartitionLossPolicy.READ_WRITE_SAFE));
> for (int i = 0; i < 1000; i++)
> cache.put(i, i);
> IgniteEx client = startClientGrid(2);
> stopGrid(1);
> assertFalse(client.cache("testtest").lostPartitions().isEmpty());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13217) Partition loss detection is not working if a dynamic cache is not started on a client.
[
https://issues.apache.org/jira/browse/IGNITE-13217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152658#comment-17152658
]
Sergey Uttsel commented on IGNITE-13217:
Test IgniteCacheTestSuite2:
IgniteNearClientCacheCloseTest.testNearCacheCloseTx2
([https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7884386686156266266&tab=testDetails&branch_IgniteTests24Java8=pull%2F7994%2Fhead])
failed because this ticket depends on
https://issues.apache.org/jira/browse/IGNITE-132171
> Partition loss detection is not working if a dynamic cache is not started on
> a client.
> --
>
> Key: IGNITE-13217
> URL: https://issues.apache.org/jira/browse/IGNITE-13217
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Partition loss detection is not working if dynamic cache is not initialized
> on client.
> WA: get cache proxy on client before data node has left.
> Reproducer:
> {code:java}
> public void test() throws Exception {
> IgniteEx ig = startGrids(2);
> awaitPartitionMapExchange();
> IgniteCache cache = ig.getOrCreateCache(new
> CacheConfiguration<>("testtest").setPartitionLossPolicy(PartitionLossPolicy.READ_WRITE_SAFE));
> for (int i = 0; i < 1000; i++)
> cache.put(i, i);
> IgniteEx client = startClientGrid(2);
> stopGrid(1);
> assertFalse(client.cache("testtest").lostPartitions().isEmpty());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13217) Partition loss detection is not working if a dynamic cache is not started on a client.
[
https://issues.apache.org/jira/browse/IGNITE-13217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152657#comment-17152657
]
Ignite TC Bot commented on IGNITE-13217:
{panel:title=Branch: [pull/7994/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5445633]]
* IgniteCacheTestSuite2: IgniteNearClientCacheCloseTest.testNearCacheCloseTx2 -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/7994/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 2{color} [tests 1]
* {color:#013220}IgniteCacheTestSuite2:
CacheDetectLostPartitionsTest.testDetectLostPartitionedOnClient - PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b090ea90-f8f7-47dd-aa35-b637eb4389bc, topVer=0,
nodeId8=a223691d, msg=, type=NODE_JOINED, tstamp=1594023218159],
val2=AffinityTopologyVersion [topVer=376369962026792949, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3fb00332371-4a94e570-f805-45dd-97e9-28a0dadb91c1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d1721244-5a58-4c08-8d4a-a394484ef74f, topVer=0, nodeId8=d1721244,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594023218159]],
val2=AffinityTopologyVersion [topVer=7781287513250848190, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3fb00332371-4a94e570-f805-45dd-97e9-28a0dadb91c1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d1721244-5a58-4c08-8d4a-a394484ef74f, topVer=0, nodeId8=d1721244,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594023218159]],
val2=AffinityTopologyVersion [topVer=7781287513250848190, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b090ea90-f8f7-47dd-aa35-b637eb4389bc, topVer=0,
nodeId8=a223691d, msg=, type=NODE_JOINED, tstamp=1594023218159],
val2=AffinityTopologyVersion [topVer=376369962026792949, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=207355ab-703e-4ea3-b0b1-9477a2f4dca8, topVer=0,
nodeId8=6ccb1ee5, msg=, type=NODE_JOINED, tstamp=1594023231798],
val2=AffinityTopologyVersion [topVer=-3985959484465497518, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=207355ab-703e-4ea3-b0b1-9477a2f4dca8, topVer=0,
nodeId8=6ccb1ee5, msg=, type=NODE_JOINED, tstamp=1594023231798],
val2=AffinityTopologyVersion [topVer=-3985959484465497518, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a3140332371-b285bb17-cb5a-4626-96f6-1e8f5a4b6f83, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=0bcd8c82-ca3e-4114-8f40-9004d740c312, topVer=0, nodeId8=0bcd8c82,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594023231798]],
val2=AffinityTopologyVersion [topVer=3336771685095127005, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a3140332371-b285bb17-cb5a-4626-96f6-1e8f5a4b6f83, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=0bcd8c82-ca3e-4114-8f40-9004d740c312, topVer=0, nodeId8=0bcd8c82,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594023231798]],
val2=AffinityTopologyVersion [topVer=3336771685095127005, minorTopVer=0]]] -
PASSED{color}
{color:#8b}MVCC Cache 2{color} [tests 1]
* {color:#013220}IgniteCacheMvccTestSuite2:
CacheDetectLostPartitionsTest.testDetectLostPartitionedOnClient - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5442709&buildType
[jira] [Updated] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-6785:
--
Fix Version/s: (was: 2.9)
2.10
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.10
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152653#comment-17152653
]
Aleksey Plekhanov commented on IGNITE-6785:
---
[~PetrovMikhail], ok, thank you, moved to the next release.
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.9
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152652#comment-17152652 ] Aleksey Plekhanov commented on IGNITE-10417: [~voropava], [~dmekhanikov] any updates here? > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.9 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10136) NPE in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-10136.
Fix Version/s: (was: 2.9)
Resolution: Duplicate
> NPE in PartitionUpdateCountersMessage
> -
>
> Key: IGNITE-10136
> URL: https://issues.apache.org/jira/browse/IGNITE-10136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
>
> {noformat}
> [14:00:55,950][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=9d5398bc-896a-469c-8686-38e2afd517c1,
> startPtr=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=11ms,
> walCpRecordFsyncDuration=12ms, pages=636, reason='timeout']
> [14:00:56,029][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=9d5398bc-896a-469c-8686-38e2afd517c1, pages=636,
> markPos=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=26ms,
> pagesWrite=21ms, fsync=58ms, total=105ms]
> [14:00:56,940][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=5f46c89e-ead8-4c87-adad-72a50c26bd7c,
> startPtr=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=8ms,
> walCpRecordFsyncDuration=5ms, pages=474, reason='timeout']
> [14:00:57,003][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=5f46c89e-ead8-4c87-adad-72a50c26bd7c, pages=474,
> markPos=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=15ms,
> pagesWrite=10ms, fsync=53ms, total=78ms]
> [14:00:57,065][SEVERE][grid-nio-worker-tcp-comm-2-#42][GridDirectParser]
> Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
> ordered=false, timeout=0, skipOnTimeout=false, msg=null],
> buf=java.nio.DirectByteBuffer[pos=792 lim=885 cap=32768],
> reader=RollingUpgradeMessageReader [state=StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=GridCacheIdMessage [cacheId=0]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=152301622, order=1540821647376, nodeOrder=4],
> committedVers=null, rolledbackVers=null, cnt=0,
> super=]GridDistributedTxPrepareRequest [threadId=236,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=152301622, order=1540821647377, nodeOrder=4], timeout=0, reads=null,
> writes=ArrayList [], dhtVers=null, txSize=-1, plc=2, txState=null,
> flags=last, super=]GridDhtTxPrepareRequest
> [nearNodeId=3800f476-beb1-46b0-8a39-faa51c91831d,
> futId=f794020c661-cc8749ef-caa5-4f1e-9d89-4a9beff59798, miniId=1,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=8],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=152301622, order=1540821647374,
> nodeOrder=5], subjId=3800f476-beb1-46b0-8a39-faa51c91831d, taskNameHash=0,
> preloadKeys=null, mvccSnapshot=MvccSnapshotResponse [futId=1,
> crdVer=1540821617885, cntr=16, opCntr=1, txs=null, cleanupVer=15,
> tracking=0], skipCompletedVers=false, super=], mapIt=null, it=null,
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0,
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
> state=0, fieldCnt=7, readFieldCnt=0, curName=msg, typeRead=true,
> itemTypeRead=false, keyTypeRead=false, valTypeRead=false, curType=21,
> curItemType=null, curKeyType=null, curValType=null, readMsgCls=class
> o.a.i.i.managers.communication.GridIoMessage]StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=PartitionUpdateCountersMessage{cacheId=-553317389, size=0, cntrs=},
> mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=1, readItems=0,
> prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
> lastFinished=true], state=0, fieldCnt=-1, readFieldCnt=0, curName=null,
> typeRead=false, itemTypeRead=false, keyTypeRead=false, valTypeRead=false,
> curType=0, curItemType=null, curKeyType=null, curValType=null,
> readMsgCls=null]StateItem [stream=DirectByteBufferStreamImplV2
> [baseOff=140703933959040, arrOff=-1, tmpArrOff=0, valReadBytes=0,
> tmpArrBytes=0, msgTypeDone=false, msg=null, mapIt=null, it=null, arrPos=-1,
> keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0, uuidState=0,
> uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true], state=0,
> fieldCnt=-
[jira] [Commented] (IGNITE-10136) NPE in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152647#comment-17152647
]
Aleksey Plekhanov commented on IGNITE-10136:
Looks like it's not possible anymore (after IGNITE-10055 is resolved).
Original code block throwing NPE in 2.7 release was :
{code:java}
data = reader.readByteArray("data");
...
size = data.length / ITEM_SIZE; // NPE here{code}
But {{data}} can't be read as {{null}} on the receiver side, since it can't be
written as {{null}} on the sender side, since it initialized in the
constructor.
Closing the ticket. Fill free to reopen it if you think it's still actual.
> NPE in PartitionUpdateCountersMessage
> -
>
> Key: IGNITE-10136
> URL: https://issues.apache.org/jira/browse/IGNITE-10136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.9
>
>
> {noformat}
> [14:00:55,950][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=9d5398bc-896a-469c-8686-38e2afd517c1,
> startPtr=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=11ms,
> walCpRecordFsyncDuration=12ms, pages=636, reason='timeout']
> [14:00:56,029][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=9d5398bc-896a-469c-8686-38e2afd517c1, pages=636,
> markPos=FileWALPointer [idx=0, fileOff=17828636, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=26ms,
> pagesWrite=21ms, fsync=58ms, total=105ms]
> [14:00:56,940][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=5f46c89e-ead8-4c87-adad-72a50c26bd7c,
> startPtr=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> checkpointLockWait=0ms, checkpointLockHoldTime=8ms,
> walCpRecordFsyncDuration=5ms, pages=474, reason='timeout']
> [14:00:57,003][INFO][db-checkpoint-thread-#73][GridCacheDatabaseSharedManager]
> Checkpoint finished [cpId=5f46c89e-ead8-4c87-adad-72a50c26bd7c, pages=474,
> markPos=FileWALPointer [idx=0, fileOff=20005440, len=210609],
> walSegmentsCleared=0, walSegmentsCovered=[], markDuration=15ms,
> pagesWrite=10ms, fsync=53ms, total=78ms]
> [14:00:57,065][SEVERE][grid-nio-worker-tcp-comm-2-#42][GridDirectParser]
> Failed to read message [msg=GridIoMessage [plc=0, topic=null, topicOrd=-1,
> ordered=false, timeout=0, skipOnTimeout=false, msg=null],
> buf=java.nio.DirectByteBuffer[pos=792 lim=885 cap=32768],
> reader=RollingUpgradeMessageReader [state=StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=GridCacheIdMessage [cacheId=0]GridDistributedBaseMessage
> [ver=GridCacheVersion [topVer=152301622, order=1540821647376, nodeOrder=4],
> committedVers=null, rolledbackVers=null, cnt=0,
> super=]GridDistributedTxPrepareRequest [threadId=236,
> concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, writeVer=GridCacheVersion
> [topVer=152301622, order=1540821647377, nodeOrder=4], timeout=0, reads=null,
> writes=ArrayList [], dhtVers=null, txSize=-1, plc=2, txState=null,
> flags=last, super=]GridDhtTxPrepareRequest
> [nearNodeId=3800f476-beb1-46b0-8a39-faa51c91831d,
> futId=f794020c661-cc8749ef-caa5-4f1e-9d89-4a9beff59798, miniId=1,
> topVer=AffinityTopologyVersion [topVer=5, minorTopVer=8],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=152301622, order=1540821647374,
> nodeOrder=5], subjId=3800f476-beb1-46b0-8a39-faa51c91831d, taskNameHash=0,
> preloadKeys=null, mvccSnapshot=MvccSnapshotResponse [futId=1,
> crdVer=1540821617885, cntr=16, opCntr=1, txs=null, cleanupVer=15,
> tracking=0], skipCompletedVers=false, super=], mapIt=null, it=null,
> arrPos=-1, keyDone=false, readSize=-1, readItems=0, prim=0, primShift=0,
> uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0, lastFinished=true],
> state=0, fieldCnt=7, readFieldCnt=0, curName=msg, typeRead=true,
> itemTypeRead=false, keyTypeRead=false, valTypeRead=false, curType=21,
> curItemType=null, curKeyType=null, curValType=null, readMsgCls=class
> o.a.i.i.managers.communication.GridIoMessage]StateItem
> [stream=DirectByteBufferStreamImplV2 [baseOff=140703933959040, arrOff=-1,
> tmpArrOff=0, valReadBytes=0, tmpArrBytes=0, msgTypeDone=true,
> msg=PartitionUpdateCountersMessage{cacheId=-553317389, size=0, cntrs=},
> mapIt=null, it=null, arrPos=-1, keyDone=false, readSize=1, readItems=0,
> prim=0, primShift=0, uuidState=0, uuidMost=0, uuidLeast=0, uuidLocId=0,
> lastFinished=true], state=0, fieldCnt=-1, readFieldCnt=0, curName=null,
> typeRead=false, itemT
[jira] [Commented] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152640#comment-17152640
]
Mikhail Petrov commented on IGNITE-6785:
[~alex_pl] I just added more succinct test to show the problem. For now i'm not
working on this issue. So no estimates. I unassigned ticket from myself.
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.9
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152637#comment-17152637 ] Aleksey Plekhanov commented on IGNITE-9974: --- [~vveider] do you have a reviewer for your patch? Do we have a chance to merge it in 2.9 release? > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-11075) Index rebuild procedure over cache partition file
[
https://issues.apache.org/jira/browse/IGNITE-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152634#comment-17152634
]
Aleksey Plekhanov edited comment on IGNITE-11075 at 7/7/20, 10:25 AM:
--
Moved to the next release (together with the umbrella ticket). Please, feel
free to move it back if you will be able to complete the ticket by 2.9 code
freeze date (17 july 2020).
was (Author: alex_pl):
Moved to the next release (together with the umbrella ticket)
> Index rebuild procedure over cache partition file
> -
>
> Key: IGNITE-11075
> URL: https://issues.apache.org/jira/browse/IGNITE-11075
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Sergey Kalashnikov
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The node can own partition when partition data is rebalanced and cache
> indexes are ready. For the message-based cluster rebalancing, approach
> indexes are rebuilding simultaneously with cache data loading. For the
> file-based rebalancing approach, the index rebuild procedure must be finished
> before the partition state is set to the OWNING state.
> We need to rebuild local SQL indexes (the {{index.bin}} file) when partition
> file has been received. Crash-recovery guarantees must be supported by a node
> since index-rebuild performs on the node in the topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11075) Index rebuild procedure over cache partition file
[
https://issues.apache.org/jira/browse/IGNITE-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11075:
---
Fix Version/s: (was: 2.9)
2.10
> Index rebuild procedure over cache partition file
> -
>
> Key: IGNITE-11075
> URL: https://issues.apache.org/jira/browse/IGNITE-11075
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Sergey Kalashnikov
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The node can own partition when partition data is rebalanced and cache
> indexes are ready. For the message-based cluster rebalancing, approach
> indexes are rebuilding simultaneously with cache data loading. For the
> file-based rebalancing approach, the index rebuild procedure must be finished
> before the partition state is set to the OWNING state.
> We need to rebuild local SQL indexes (the {{index.bin}} file) when partition
> file has been received. Crash-recovery guarantees must be supported by a node
> since index-rebuild performs on the node in the topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11075) Index rebuild procedure over cache partition file
[
https://issues.apache.org/jira/browse/IGNITE-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152634#comment-17152634
]
Aleksey Plekhanov commented on IGNITE-11075:
Moved to the next release (together with the umbrella ticket)
> Index rebuild procedure over cache partition file
> -
>
> Key: IGNITE-11075
> URL: https://issues.apache.org/jira/browse/IGNITE-11075
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Sergey Kalashnikov
>Priority: Major
> Labels: iep-28
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The node can own partition when partition data is rebalanced and cache
> indexes are ready. For the message-based cluster rebalancing, approach
> indexes are rebuilding simultaneously with cache data loading. For the
> file-based rebalancing approach, the index rebuild procedure must be finished
> before the partition state is set to the OWNING state.
> We need to rebuild local SQL indexes (the {{index.bin}} file) when partition
> file has been received. Crash-recovery guarantees must be supported by a node
> since index-rebuild performs on the node in the topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12069) Implement file rebalancing management
[
https://issues.apache.org/jira/browse/IGNITE-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12069:
---
Fix Version/s: (was: 2.9)
2.10
> Implement file rebalancing management
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-28
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Preloader}} should be able to do the following:
> # build the map of partitions and corresponding supplier nodes from which
> partitions will be loaded;
> # switch cache data storage to {{no-op}} and back to original (HWM must be
> fixed here for the needs of historical rebalance) under the checkpoint and
> keep the partition update counter for each partition;
> # run async the eviction indexes for the list of collected partitions;
> # send a request message to each node one by one with the list of partitions
> to load;
> # wait for files received (listening for the transmission handler);
> # run rebuild indexes async over the receiving partitions;
> # run historical rebalance from LWM to HWM collected above (LWM can be read
> from the received file meta page);
> h5. Stage 1. implement "read-only" mode for cache data store. Implement data
> store reinitialization on the updated persistence file.
> h6. Tests:
> - Switching under load.
> - Check re-initialization of partition on new file.
> - Check that in read-only mode
> ** H2 indexes are not updated
> ** update counter is updated
> ** cache entries eviction works fine
> ** tx/atomic updates on this partition works fine in cluster
> h5. Stage 2. Build Map for request partitions by node, add message that will
> be sent to the supplier. Send a demand request, handle the response, switch
> datastore when file received.
> h6. Tests:
> - Check partition consistency after receiving a file.
> - File transmission under load.
> - Failover - some of the partitions have been switched, the node has been
> restarted, rebalancing is expected to continue only for fully loaded large
> partitions through the historical rebalance, for the rest of partitions it
> should restart from the beginning.
> h5. Stage 3. Add WAL history reservation on supplier. Add historical
> rebalance triggering (LWM (partition) - HWM (read-only)).
> h6. Tests:
> - File rebalancing under load and without on atomic/tx caches. (check
> existing PDS-enabled rebalancing tests).
> - Ensure that MVCC groups use regular rebalancing.
> - The rebalancing on the unstable topology and failures of the
> supplier/demander nodes at different stages.
> - (compatibility) The old nodes should use regular rebalancing.
> h5. Stage 4 Eviction and rebuild of indexes.
> h6. Tests:
> - File rebalancing of caches with H2 indexes.
> - Check consistency of H2 indexes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12069) Implement file rebalancing management
[
https://issues.apache.org/jira/browse/IGNITE-12069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152633#comment-17152633
]
Aleksey Plekhanov commented on IGNITE-12069:
Looks like this ticket can't be completed in 2.9 release. Moved to the next
release. Please, feel free to move it back if you will be able to complete the
ticket by 2.9 code freeze date (17 july 2020).
> Implement file rebalancing management
> -
>
> Key: IGNITE-12069
> URL: https://issues.apache.org/jira/browse/IGNITE-12069
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maxim Muzafarov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-28
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Preloader}} should be able to do the following:
> # build the map of partitions and corresponding supplier nodes from which
> partitions will be loaded;
> # switch cache data storage to {{no-op}} and back to original (HWM must be
> fixed here for the needs of historical rebalance) under the checkpoint and
> keep the partition update counter for each partition;
> # run async the eviction indexes for the list of collected partitions;
> # send a request message to each node one by one with the list of partitions
> to load;
> # wait for files received (listening for the transmission handler);
> # run rebuild indexes async over the receiving partitions;
> # run historical rebalance from LWM to HWM collected above (LWM can be read
> from the received file meta page);
> h5. Stage 1. implement "read-only" mode for cache data store. Implement data
> store reinitialization on the updated persistence file.
> h6. Tests:
> - Switching under load.
> - Check re-initialization of partition on new file.
> - Check that in read-only mode
> ** H2 indexes are not updated
> ** update counter is updated
> ** cache entries eviction works fine
> ** tx/atomic updates on this partition works fine in cluster
> h5. Stage 2. Build Map for request partitions by node, add message that will
> be sent to the supplier. Send a demand request, handle the response, switch
> datastore when file received.
> h6. Tests:
> - Check partition consistency after receiving a file.
> - File transmission under load.
> - Failover - some of the partitions have been switched, the node has been
> restarted, rebalancing is expected to continue only for fully loaded large
> partitions through the historical rebalance, for the rest of partitions it
> should restart from the beginning.
> h5. Stage 3. Add WAL history reservation on supplier. Add historical
> rebalance triggering (LWM (partition) - HWM (read-only)).
> h6. Tests:
> - File rebalancing under load and without on atomic/tx caches. (check
> existing PDS-enabled rebalancing tests).
> - Ensure that MVCC groups use regular rebalancing.
> - The rebalancing on the unstable topology and failures of the
> supplier/demander nodes at different stages.
> - (compatibility) The old nodes should use regular rebalancing.
> h5. Stage 4 Eviction and rebuild of indexes.
> h6. Tests:
> - File rebalancing of caches with H2 indexes.
> - Check consistency of H2 indexes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8020) Rebalancing for persistent caches should transfer file store over network instead of using existing supply/demand protocol
[ https://issues.apache.org/jira/browse/IGNITE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-8020: -- Fix Version/s: (was: 2.9) 2.10 > Rebalancing for persistent caches should transfer file store over network > instead of using existing supply/demand protocol > -- > > Key: IGNITE-8020 > URL: https://issues.apache.org/jira/browse/IGNITE-8020 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ilya Lantukh >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-16, iep-28 > Fix For: 2.10 > > > Existing rebalancing protocol is suitable for in-memory data storage, but for > data persisted in files it is sub-optimal and requires a lot of unnecessary > steps. Efforts to optimize it led to necessity to completely rework the > protocol - instead of sending batches (SupplyMessages) with cache entries it > is possible to send data files directly. > The algorithm should look like this: > 1. Demander node sends requests with required partition IDs (like now) > 2. Supplier node receives request and performs a checkpoint. > 3. After checkpoint is done, supplier sends files with demanded partitions > using low-level NIO API. > 4. During steps 2-3, demander node should work in special mode - it should > temporary store all incoming updates in such way that they can be quickly > applied later. > 5. After files are transferred, demander applies updates stored at step 4. > The tricky part here is to switch work modes of demander node avoiding all > possible race conditions. Also, the aforementioned algorithm should be > extended to transfer or rebuild query indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8020) Rebalancing for persistent caches should transfer file store over network instead of using existing supply/demand protocol
[ https://issues.apache.org/jira/browse/IGNITE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152632#comment-17152632 ] Aleksey Plekhanov commented on IGNITE-8020: --- Looks like this ticket can't be completed in 2.9 release. Moved to the next release. Please, feel free to move it back if you will be able to complete the ticket by 2.9 code freeze date (17 july 2020). > Rebalancing for persistent caches should transfer file store over network > instead of using existing supply/demand protocol > -- > > Key: IGNITE-8020 > URL: https://issues.apache.org/jira/browse/IGNITE-8020 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ilya Lantukh >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-16, iep-28 > Fix For: 2.9 > > > Existing rebalancing protocol is suitable for in-memory data storage, but for > data persisted in files it is sub-optimal and requires a lot of unnecessary > steps. Efforts to optimize it led to necessity to completely rework the > protocol - instead of sending batches (SupplyMessages) with cache entries it > is possible to send data files directly. > The algorithm should look like this: > 1. Demander node sends requests with required partition IDs (like now) > 2. Supplier node receives request and performs a checkpoint. > 3. After checkpoint is done, supplier sends files with demanded partitions > using low-level NIO API. > 4. During steps 2-3, demander node should work in special mode - it should > temporary store all incoming updates in such way that they can be quickly > applied later. > 5. After files are transferred, demander applies updates stored at step 4. > The tricky part here is to switch work modes of demander node avoiding all > possible race conditions. Also, the aforementioned algorithm should be > extended to transfer or rebuild query indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-6785:
--
Assignee: (was: Mikhail Petrov)
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.9
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6982) .NET: Migrate to latest NUnit
[ https://issues.apache.org/jira/browse/IGNITE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152622#comment-17152622 ] Aleksey Plekhanov commented on IGNITE-6982: --- [~ashapkin], are you still working on this ticket? Any estimates? Do we need it in 2.9 release? > .NET: Migrate to latest NUnit > - > > Key: IGNITE-6982 > URL: https://issues.apache.org/jira/browse/IGNITE-6982 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Fix For: 2.9 > > > We use very old NUnit 2.6. In order to reuse tests under .NET Core > (IGNITE-2662) we need latest NUnit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152619#comment-17152619
]
Aleksey Plekhanov commented on IGNITE-6785:
---
[~PetrovMikhail] are you working on this ticket? Any estimates? Do we need it
in 2.9 release?
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1, 2.8
>Reporter: Denis A. Magda
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.9
>
> Attachments: SqlAffinityKeyTest.java, sql_bug.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13212) Peer class loading does not work for Scan Query
[
https://issues.apache.org/jira/browse/IGNITE-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152612#comment-17152612
]
Ignite TC Bot commented on IGNITE-13212:
{panel:title=Branch: [pull/7998/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7998/head] Base: [master] : New Tests
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=16d8c601-c7e4-493f-8ced-2ac44727d921, topVer=0,
nodeId8=4bd2ee28, msg=, type=NODE_JOINED, tstamp=1594050614297],
val2=AffinityTopologyVersion [topVer=-5041622691805015226, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=16d8c601-c7e4-493f-8ced-2ac44727d921, topVer=0,
nodeId8=4bd2ee28, msg=, type=NODE_JOINED, tstamp=1594050614297],
val2=AffinityTopologyVersion [topVer=-5041622691805015226, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=d1412d42371-72feed7a-7c42-4fb6-aa83-160d4a840318, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=9437b16c-531a-4c41-9a90-8d3b22b3d143, topVer=0, nodeId8=9437b16c,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594050614297]],
val2=AffinityTopologyVersion [topVer=7086972182296082517, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=d1412d42371-72feed7a-7c42-4fb6-aa83-160d4a840318, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=9437b16c-531a-4c41-9a90-8d3b22b3d143, topVer=0, nodeId8=9437b16c,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594050614297]],
val2=AffinityTopologyVersion [topVer=7086972182296082517, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Basic 1{color} [tests 7]
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryGetAllFromClientNodeWithExplicitClass
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryCursorFromClientNodeWithAnonymousClass
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryFromServerFailsIfP2PClassLoadingIsDisabled
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryCursorFromServerNodeWithExplicitClass
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryFromClientFailsIfP2PClassLoadingIsDisabled
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testSharedTransformerWorksWhenP2PIsDisabled
- PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
GridP2PScanQueryWithTransformerTest.testScanQueryCursorFromClientNodeWithExplicitClass
- PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e513ed42371-362d948b-618a-42d0-9092-f1be67442d64, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=7caed509-e57e-406a-9a53-9716d7ca0a17, topVer=0, nodeId8=7caed509,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594050766333]],
val2=AffinityTopologyVersion [topVer=-4117946985441453508, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8dff4636-96cf-49a5-a4ee-36c1f89eec82, topVer=0,
nodeId8=c203ff09, msg=, type=NODE_JOINED, tstamp=1594050766333],
val2=AffinityTopologyVersion [topVer=-5337685383914367663, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8dff4636-96cf-49a5-a4ee-36c1f89eec82, topVer=0,
nodeId8=c203ff09, msg=, type=NODE_JOINED, tstamp=1594050766333],
val2=AffinityTopologyVersion [topVer=-5337685383914367663, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e513ed
[jira] [Commented] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152613#comment-17152613
]
Ignite TC Bot commented on IGNITE-13146:
{panel:title=Branch: [pull/7999/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7999/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5445785&buildTypeId=IgniteTests24Java8_RunBasicTests]
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs to
> be updated in accordance with examples/pom.xml changes. This is currently a
> blocker for 2.9.
--
This message was sent by Atlassian Jira
(v8.3.4
[jira] [Commented] (IGNITE-13109) Skip metastorage entries that can not be unmarshalled
[
https://issues.apache.org/jira/browse/IGNITE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152609#comment-17152609
]
Ignite TC Bot commented on IGNITE-13109:
{panel:title=Branch: [pull/7987/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7987/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [tests 1]
* {color:#013220}IgnitePdsTestSuite:
StartClusterSkipKeysTest.testStartWithUnknownKey - PASSED{color}
{color:#8b}MVCC PDS 1{color} [tests 1]
* {color:#013220}IgnitePdsMvccTestSuite:
StartClusterSkipKeysTest.testStartWithUnknownKey - PASSED{color}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=34641a35-c66a-4232-8a27-5cab24fc13a0, topVer=0,
nodeId8=398aee09, msg=, type=NODE_JOINED, tstamp=1594021361434],
val2=AffinityTopologyVersion [topVer=-8979454264243299289, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=34641a35-c66a-4232-8a27-5cab24fc13a0, topVer=0,
nodeId8=398aee09, msg=, type=NODE_JOINED, tstamp=1594021361434],
val2=AffinityTopologyVersion [topVer=-8979454264243299289, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a920e132371-8e2e1e2e-c392-48f3-88dc-4084f4cd5f0c, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=13c81acf-e534-4ec5-a4eb-53e9a9f0b567, topVer=0, nodeId8=13c81acf,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594021361434]],
val2=AffinityTopologyVersion [topVer=-3804855400100515563, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=a920e132371-8e2e1e2e-c392-48f3-88dc-4084f4cd5f0c, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=13c81acf-e534-4ec5-a4eb-53e9a9f0b567, topVer=0, nodeId8=13c81acf,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594021361434]],
val2=AffinityTopologyVersion [topVer=-3804855400100515563, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a0f5a512-9979-4245-976a-061ad19eec1d, topVer=0,
nodeId8=2e8a3541, msg=, type=NODE_JOINED, tstamp=1594021403241],
val2=AffinityTopologyVersion [topVer=3932713875054035986, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a0f5a512-9979-4245-976a-061ad19eec1d, topVer=0,
nodeId8=2e8a3541, msg=, type=NODE_JOINED, tstamp=1594021403241],
val2=AffinityTopologyVersion [topVer=3932713875054035986, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=d6a54132371-03e0ddeb-8d7d-4b68-bd93-ae92b670db8a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4c60884d-d7ec-442a-8ec7-79e7d3e095b4, topVer=0, nodeId8=4c60884d,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594021403241]],
val2=AffinityTopologyVersion [topVer=-3929488358696672136, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=d6a54132371-03e0ddeb-8d7d-4b68-bd93-ae92b670db8a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=4c60884d-d7ec-442a-8ec7-79e7d3e095b4, topVer=0, nodeId8=4c60884d,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594021403241]],
val2=AffinityTopologyVersion [topVer=-3929488358696672136, minorTopVer=0]]] -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5442592&buildTypeId=IgniteTests24Java8_RunAll]
> Skip metastorage entries that can not be unmarshalled
> -
>
> Key: IGNITE-13109
> URL: https://issues.apache.org/jira/browse/IGNITE-13109
> Project: Ign
[jira] [Commented] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152606#comment-17152606 ] Ilya Kasnacheev commented on IGNITE-13216: -- [~erudenko] thank you for this fix, I have merged it to master. > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > If "name" parameter is set it should be used instead of actual field name. > Currently if 2 @QuerySqlField fields have same names we will receive error, > even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13216: - Component/s: sql > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > If "name" parameter is set it should be used instead of actual field name. > Currently if 2 @QuerySqlField fields have same names we will receive error, > even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13216) QuerySqlField annotation's "name" property is not used during validation of known fields names
[ https://issues.apache.org/jira/browse/IGNITE-13216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-13216: - Ignite Flags: (was: Docs Required,Release Notes Required) > QuerySqlField annotation's "name" property is not used during validation of > known fields names > -- > > Key: IGNITE-13216 > URL: https://issues.apache.org/jira/browse/IGNITE-13216 > Project: Ignite > Issue Type: Bug >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Blocker > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > If "name" parameter is set it should be used instead of actual field name. > Currently if 2 @QuerySqlField fields have same names we will receive error, > even if they have different "name" properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13173) Add offHeapEntries and similar values to CACHE_VIEW
[ https://issues.apache.org/jira/browse/IGNITE-13173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Frolov updated IGNITE-13173: --- Summary: Add offHeapEntries and similar values to CACHE_VIEW (was: Add additional attributes to system views) > Add offHeapEntries and similar values to CACHE_VIEW > --- > > Key: IGNITE-13173 > URL: https://issues.apache.org/jira/browse/IGNITE-13173 > Project: Ignite > Issue Type: Wish >Affects Versions: 2.8, 2.8.1 >Reporter: Dmitry Frolov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > Time Spent: 10m > Remaining Estimate: 0h > > This is a proposal to enrich system views with additional attributes of the > cache entries: > offHeapEntriesCount > offHeapBackupEntriesCount > offHeapPrimaryEntriesCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13225) Add the possibility to export data in OpenCensus only for defined metrics
[ https://issues.apache.org/jira/browse/IGNITE-13225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Frolov updated IGNITE-13225: --- Summary: Add the possibility to export data in OpenCensus only for defined metrics (was: Add the possibility to export data in OpenCensus only from defined metrics) > Add the possibility to export data in OpenCensus only for defined metrics > - > > Key: IGNITE-13225 > URL: https://issues.apache.org/jira/browse/IGNITE-13225 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8, 2.8.1 >Reporter: Dmitry Frolov >Priority: Major > > By default, OpenCensus exporter returns data from all OpenCensus metrics. As > a result, there could be a performance drop. We should add the possibility to > export data only from defined metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13225) Add the possibility to export data in OpenCensus only from defined metrics
Dmitry Frolov created IGNITE-13225: -- Summary: Add the possibility to export data in OpenCensus only from defined metrics Key: IGNITE-13225 URL: https://issues.apache.org/jira/browse/IGNITE-13225 Project: Ignite Issue Type: Improvement Affects Versions: 2.8.1, 2.8 Reporter: Dmitry Frolov By default, OpenCensus exporter returns data from all OpenCensus metrics. As a result, there could be a performance drop. We should add the possibility to export data only from defined metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13224) Add metrics to OpenCensus exporter
[ https://issues.apache.org/jira/browse/IGNITE-13224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Frolov updated IGNITE-13224: --- Labels: IEP-35 (was: ) > Add metrics to OpenCensus exporter > -- > > Key: IGNITE-13224 > URL: https://issues.apache.org/jira/browse/IGNITE-13224 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8, 2.8.1 >Reporter: Dmitry Frolov >Priority: Major > Labels: IEP-35 > > The metrics below are available only via JMX now. The ticket is a suggestion > to add these metrics to Opencencus as well: > *ClusterMetricsMXBeanImpl:* > ActiveBaselineNodes > TopologyVersion > TotalBaselineNodes > TotalClientNodes > TotalNodes > TotalServerNodes > > *Ignite clients count:* > Connections > > *TcpDiscoverySpi:* > MessageWorkerQueueSize > > *ClusterLocalNodeMetricsMXBeanImpl:* > HeapMemoryTotal > > *Data Region Metrics:* > MaxSize > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13224) Add metrics to OpenCensus exporter
[ https://issues.apache.org/jira/browse/IGNITE-13224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Frolov updated IGNITE-13224: --- Affects Version/s: 2.8 2.8.1 > Add metrics to OpenCensus exporter > -- > > Key: IGNITE-13224 > URL: https://issues.apache.org/jira/browse/IGNITE-13224 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8, 2.8.1 >Reporter: Dmitry Frolov >Priority: Major > > The metrics below are available only via JMX now. The ticket is a suggestion > to add these metrics to Opencencus as well: > *ClusterMetricsMXBeanImpl:* > ActiveBaselineNodes > TopologyVersion > TotalBaselineNodes > TotalClientNodes > TotalNodes > TotalServerNodes > > *Ignite clients count:* > Connections > > *TcpDiscoverySpi:* > MessageWorkerQueueSize > > *ClusterLocalNodeMetricsMXBeanImpl:* > HeapMemoryTotal > > *Data Region Metrics:* > MaxSize > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13213) Improve Queue performance
[
https://issues.apache.org/jira/browse/IGNITE-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Núñez updated IGNITE-13213:
--
Description:
Queue performance can be improved by making some changes, related to Queue Item
Key(1) , offer method (2) and collection configuration (3), and related issues
IGNITE-13203 and IGNITE-13221.
With those changes queue structure is 10%-30% faster than first Ignite's
competitor:
!image-2020-07-04-15-35-43-879.png!
Queue performance benchmark (lower value is better) with different queue
message types, multiple clients (M) and 2 server nodes (IMDG):
* string messages: 1KB, 10KB, 100KB
* byte[] messages: 1KB, 10KB, 100KB
* complex objects with cycle references (cpx) messages
Legend:
* {color:#4c9aff}Blue{color}: first Ignite's competitor - on heap only, open
source version does not support off-heap neither OOTB persistence, we can see
GC pauses
* {color:#ffab00}Orange{color}: Ignite off-heap with native persistence enabled
* {color:#de350b}Red{color}: Ignite off-heap only
1. Queue Item Key -> currently, queue hash code is computed for every single
item key using full queue name (> 20 chars) on Queue Item Key constructor.
Proposal compute hash on GridCacheQueueAdapter constructor and pass it to
itemKey method
{code:java}
private static QueueItemKey itemKey(IgniteUuid id,
int queueNameHash,
boolean collocated,
long idx) {
return collocated ?
new CollocatedQueueItemKey(id, queueNameHash, idx) : new
GridCacheQueueItemKey(id, queueNameHash, idx);
}
{code}
1.1. CollocatedQueueItemKey (fully compatible)
{code:java}
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.ignite.internal.processors.datastructures;
import org.apache.ignite.cache.affinity.AffinityKeyMapped;
import org.apache.ignite.internal.util.typedef.internal.S;
import org.apache.ignite.lang.IgniteUuid;
public class CollocatedQueueItemKey implements QueueItemKey {
/** */
private IgniteUuid queueId;
/** */
@AffinityKeyMapped
private int queueNameHash;
/** */
private long idx;
/**
* @param queueId Queue unique ID.
* @param queueName Queue name.
* @param idx Item index.
*/
public CollocatedQueueItemKey(IgniteUuid queueId, int queueNameHash, long
idx) {
this.queueId = queueId;
this.queueNameHash = queueNameHash;
this.idx = idx;
}
/** {@inheritDoc} */
@Override public boolean equals(Object o) {
if (this == o)
return true;
if (o == null || getClass() != o.getClass())
return false;
CollocatedQueueItemKey itemKey = (CollocatedQueueItemKey)o;
return idx == itemKey.idx && queueId.equals(itemKey.queueId);
}
/** {@inheritDoc} */
@Override public int hashCode() {
int res = queueId.hashCode();
res = 31 * res + (int)(idx ^ (idx >>> 32));
return res;
}
/** {@inheritDoc} */
@Override public String toString() {
return S.toString(CollocatedQueueItemKey.class, this);
}
}
{code}
1.2. GridCacheQueueItemKey (not compatible with existing queues, need to be
analysed), remove queueName field as is not required at all (use queueId
instead), this will reduce network traffic and improve serialisation
performance.
{code:java}
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package or
[jira] [Updated] (IGNITE-13221) Repeated calls to Class#getCanonicalName and Class#getSimpleName is a bottleneck
[ https://issues.apache.org/jira/browse/IGNITE-13221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manuel Núñez updated IGNITE-13221: -- Description: OpenJDK version < 11 does not cache class name neither simple class name and this is a bottleneck, this affects mainly to org.apache.ignite.internal.binary.BinaryObjectExImpl. Solution could be to cache all calls to Class#getSimpleName within IgniteUtils for example. Since OpenJDK 11 and later, name and simple name are cached. For details, see ticket https://bugs.openjdk.java.net/browse/JDK-8187123 was: OpenJDK version < 11 does not cache class name neither simple class name and this is a bottleneck, this affects mainly to org.apache.ignite.internal.binary.BinaryObjectExImpl. Solution could be to cache all calls to Class#getSimpleName within IgniteUtils for example. Since OpenJDK 11 and later, name and simple name is cached. For details, see ticket https://bugs.openjdk.java.net/browse/JDK-8187123 > Repeated calls to Class#getCanonicalName and Class#getSimpleName is a > bottleneck > > > Key: IGNITE-13221 > URL: https://issues.apache.org/jira/browse/IGNITE-13221 > Project: Ignite > Issue Type: Improvement > Components: binary, networking >Reporter: Manuel Núñez >Priority: Major > > OpenJDK version < 11 does not cache class name neither simple class name and > this is a bottleneck, this affects mainly to > org.apache.ignite.internal.binary.BinaryObjectExImpl. > Solution could be to cache all calls to Class#getSimpleName within > IgniteUtils for example. > > Since OpenJDK 11 and later, name and simple name are cached. > For details, see ticket https://bugs.openjdk.java.net/browse/JDK-8187123 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[
https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152579#comment-17152579
]
Ignite TC Bot commented on IGNITE-10959:
{panel:title=Branch: [pull/7881/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7881/head] Base: [master] : New Tests
(20)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=44bf7bae-2206-4ed1-82a1-7a7db33b43f7, topVer=0,
nodeId8=5a2eebcf, msg=, type=NODE_JOINED, tstamp=1594066169735],
val2=AffinityTopologyVersion [topVer=6482430669873845675, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=44bf7bae-2206-4ed1-82a1-7a7db33b43f7, topVer=0,
nodeId8=5a2eebcf, msg=, type=NODE_JOINED, tstamp=1594066169735],
val2=AffinityTopologyVersion [topVer=6482430669873845675, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=dc8a9c52371-a2b5ad3a-a360-4a0d-a45e-eabd4760e8a1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=674b2a47-fbf0-43bf-873e-8aea010c6927, topVer=0, nodeId8=674b2a47,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594066169735]],
val2=AffinityTopologyVersion [topVer=7429373169187075070, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=dc8a9c52371-a2b5ad3a-a360-4a0d-a45e-eabd4760e8a1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=674b2a47-fbf0-43bf-873e-8aea010c6927, topVer=0, nodeId8=674b2a47,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594066169735]],
val2=AffinityTopologyVersion [topVer=7429373169187075070, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [tests 4]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b7f0b615-1cc4-4550-af55-c95af8d47ac7, topVer=0,
nodeId8=4aff7685, msg=, type=NODE_JOINED, tstamp=1594066260935],
val2=AffinityTopologyVersion [topVer=-8678113640998879127, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=b7f0b615-1cc4-4550-af55-c95af8d47ac7, topVer=0,
nodeId8=4aff7685, msg=, type=NODE_JOINED, tstamp=1594066260935],
val2=AffinityTopologyVersion [topVer=-8678113640998879127, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=bc3d0c52371-12c4d2a2-2bff-47c6-9df2-45f29305345f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e1cb0a6-cb58-4e86-99df-280864fd66fd, topVer=0, nodeId8=6e1cb0a6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594066260935]],
val2=AffinityTopologyVersion [topVer=4148470245918002258, minorTopVer=0]]] -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=bc3d0c52371-12c4d2a2-2bff-47c6-9df2-45f29305345f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=6e1cb0a6-cb58-4e86-99df-280864fd66fd, topVer=0, nodeId8=6e1cb0a6,
msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1594066260935]],
val2=AffinityTopologyVersion [topVer=4148470245918002258, minorTopVer=0]]] -
PASSED{color}
{color:#8b}Continuous Query 1{color} [tests 12]
* {color:#013220}IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryBufferLimitTest.testContinuousQueryBatchSwitchOnAck[cacheMode=PARTITIONED,
atomicityMode=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryBufferLimitTest.testContinuousQueryPendingBufferLimit[cacheMode=PARTITIONED,
atomicityMode=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryBufferLimitTest.testContinuousQueryBatchSwitchOnAck[cacheMode=PARTITIONED,
atomicityMode=ATOMIC] - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite3:
CacheContinuousQuer
[jira] [Commented] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152572#comment-17152572
]
Aleksey Plekhanov commented on IGNITE-13146:
The patch is ready. Steps to check:
For standard release:
{noformat}
mvn initialize -Prelease
cd target/release-package-apache-ignite/examples
mvn clean package{noformat}
For lgpl release:
{noformat}
mvn initialize -Prelease,lgpl -Dignite.edition=apache-ignite-lgpl
cd target/release-package-apache-ignite-lgpl/examples
mvn clean package{noformat}
For slim release:
{noformat}
mvn initialize -Prelease -Dignite.edition=apache-ignite-slim
cd target/release-package-apache-ignite-slim/examples
mvn clean package{noformat}
[~ilyak] or [~nizhikov] can you please have a look?
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs t
[jira] [Commented] (IGNITE-12620) Calcite integration. Index Nested Loop Join/Hash Join
[
https://issues.apache.org/jira/browse/IGNITE-12620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152566#comment-17152566
]
Alexey Goncharuk commented on IGNITE-12620:
---
[~gvvinblade] Since trait propagation logic was reworked, can you provide a
high-level logic that is executed in each {{derive}} method (the high-level
invariants that are not dependent on the implementation details) in javadoc?
Currently it's a bit hard to follow the target behavior.
> Calcite integration. Index Nested Loop Join/Hash Join
> -
>
> Key: IGNITE-12620
> URL: https://issues.apache.org/jira/browse/IGNITE-12620
> Project: Ignite
> Issue Type: New Feature
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We may implement the feature the next way:
> # For each row from left node consume whole dataset from right node
> # Pass join condition as an argument of request() method of the right node
> # In case a data source at right is an index scan
> ## If there is no cursor opened - create a new cursor using bounds from
> request
> ## If there is an existing cursor - just check the cursor was opened using
> the same condition as passed one.
> ## After the right node signals EOD consume a next row from left and repeat
> from p 2.
> # In case a data source at right is a table scan with huge amount of rows
> ## If there is no cursor opened - create a new cursor ignoring passed
> condition
> ## If there is an existing cursor - just check the cursor was opened using
> the same condition as passed one.
> ## After the right node signals EOD consume a next row from left and repeat
> from p 2.
> # In case a data source at right is remote / is a table scan with small
> number of rows/ is a filter node with good enough selectivity
> ## Create a hash index for a data source
> ## If there is no cursor opened - create a new cursor using bounds from
> request
> ## If there is an existing cursor - just check the cursor was opened using
> the same condition as passed one.
> ## After the right node signals EOD consume a next row from left and repeat
> from p 2.
> Consider implementation specifics at optimization time, choose the cheapest
> variant
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-13146:
--
Assignee: Aleksey Plekhanov
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs to
> be updated in accordance with examples/pom.xml changes. This is currently a
> blocker for 2.9.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152550#comment-17152550
]
Nikolay Izhikov commented on IGNITE-13146:
--
[~alex_pl] please, go ahead.
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs to
> be updated in accordance with examples/pom.xml changes. This is currently a
> blocker for 2.9.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-13146:
Assignee: (was: Nikolay Izhikov)
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs to
> be updated in accordance with examples/pom.xml changes. This is currently a
> blocker for 2.9.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13146) OpenCensus example does not work from release build
[
https://issues.apache.org/jira/browse/IGNITE-13146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152547#comment-17152547
]
Aleksey Plekhanov commented on IGNITE-13146:
[~nizhikov], are you working on this ticket? If not, can I take it?
> OpenCensus example does not work from release build
> ---
>
> Key: IGNITE-13146
> URL: https://issues.apache.org/jira/browse/IGNITE-13146
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.9
>
>
> This happens in a binary distribution of 2.9:
> {code}
> /Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.9.0-SNAPSHOT
> [INFO] [ jar
> ]-
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 255 source files to
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/target/classes
> ...
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[20,47]
> package io.opencensus.exporter.stats.prometheus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[21,37]
> package io.prometheus.client.exporter does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[34,47]
> package org.apache.ignite.spi.metric.opencensus does not exist
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[54,9]
> cannot find symbol
> symbol: variable PrometheusStatsCollector
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,9]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[57,30]
> cannot find symbol
> symbol: class HTTPServer
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,9]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [ERROR]
> /home/gridgain/Downloads/apache-ignite-slim-2.9.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/opencensus/OpenCensusMetricsExporterExample.java:[62,71]
> cannot find symbol
> symbol: class OpenCensusMetricExporterSpi
> location: class
> org.apache.ignite.examples.opencensus.OpenCensusMetricsExporterExample
> [INFO] 8 errors
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> {code}
> This is because pom-standalone.xml and pom-standalone-lgpl.xml files needs to
> be updated in accordance with examples/pom.xml changes. This is currently a
> blocker for 2.9.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13224) Add metrics to OpenCensus exporter
Dmitry Frolov created IGNITE-13224: -- Summary: Add metrics to OpenCensus exporter Key: IGNITE-13224 URL: https://issues.apache.org/jira/browse/IGNITE-13224 Project: Ignite Issue Type: Improvement Reporter: Dmitry Frolov The metrics below are available only via JMX now. The ticket is a suggestion to add these metrics to Opencencus as well: *ClusterMetricsMXBeanImpl:* ActiveBaselineNodes TopologyVersion TotalBaselineNodes TotalClientNodes TotalNodes TotalServerNodes *Ignite clients count:* Connections *TcpDiscoverySpi:* MessageWorkerQueueSize *ClusterLocalNodeMetricsMXBeanImpl:* HeapMemoryTotal *Data Region Metrics:* MaxSize -- This message was sent by Atlassian Jira (v8.3.4#803005)
