[jira] [Created] (IGNITE-14594) Calcite integration. UnionPlannerTest is not included to any test suite
Aleksey Plekhanov created IGNITE-14594: -- Summary: Calcite integration. UnionPlannerTest is not included to any test suite Key: IGNITE-14594 URL: https://issues.apache.org/jira/browse/IGNITE-14594 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov UnionPlannerTest should be included to PlannerTestSuite. Also, some plan checks should be added to the test, currently it only prints plan to the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14588) Calcite integration: Wrong processing of nested aggregates
Aleksey Plekhanov created IGNITE-14588:
--
Summary: Calcite integration: Wrong processing of nested aggregates
Key: IGNITE-14588
URL: https://issues.apache.org/jira/browse/IGNITE-14588
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
The wrong plan is created when nested aggregates are used.
For example, this query:
{{SELECT avg(salary) FROM (SELECT avg(salary) as salary FROM employer UNION ALL
SELECT salary FROM employer)}}
Generates such a plan:
{noformat}
IgniteReduceHashAggregate(group=[{}], AVG(SALARY)=[AVG($0)])
IgniteExchange(distribution=[single])
IgniteMapHashAggregate(group=[{}], AVG(SALARY)=[AVG($0)])
IgniteUnionAll(all=[true])
IgniteSingleHashAggregate(group=[{}], SALARY=[AVG($0)])
IgniteIndexScan(table=[[PUBLIC, EMPLOYER]], index=[_key_PK],
requiredColumns=[{3}])
IgniteIndexScan(table=[[PUBLIC, EMPLOYER]], index=[_key_PK],
requiredColumns=[{3}])
{noformat}
With this plan, in subquery data is aggregated locally on nodes and can produce
the wrong results.
For example:
{code:java}
@Test
public void aggregateNested() throws Exception {
String cacheName = "employer";
IgniteCache employer = client.getOrCreateCache(new
CacheConfiguration()
.setName(cacheName)
.setSqlSchema("PUBLIC")
.setIndexedTypes(Integer.class, Employer.class)
.setBackups(2)
);
awaitPartitionMapExchange(true, true, null);
List keysNode0 = primaryKeys(grid(0).cache(cacheName), 2);
List keysNode1 = primaryKeys(grid(1).cache(cacheName), 1);
employer.putAll(ImmutableMap.of(
keysNode0.get(0), new Employer("Igor", 1d),
keysNode0.get(1), new Employer("Roman", 2d) ,
keysNode1.get(0), new Employer("Nikolay", 3d)
));
QueryEngine engine = Commons.lookupComponent(grid(1).context(),
QueryEngine.class);
List>> qry = engine.query(null, "PUBLIC",
"SELECT avg(salary) FROM " +
"(SELECT avg(salary) as salary FROM employer UNION ALL SELECT
salary FROM employer)");
assertEquals(1, qry.size());
List> rows = qry.get(0).getAll();
assertEquals(1, rows.size());
assertEquals(2d, F.first(F.first(rows)));
}
{code}
With this reproducer we should get 2 as a result (avg(1, 2, 3) = 2, avg(2, 1,
2, 3) = 2), but actual result is 2.1 (avg(1, 2) = 1.5, avg (3) = 3, avg(1.5, 3,
1, 2, 3) = 2.1).
Root cause: default {{passThroughDistribution}} is not suitable for "reduce
aggregate" and "single aggregate" nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14510) Document java thin client continuous queries
Aleksey Plekhanov created IGNITE-14510: -- Summary: Document java thin client continuous queries Key: IGNITE-14510 URL: https://issues.apache.org/jira/browse/IGNITE-14510 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.11 Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.11 The new feature was added by IGNITE-14402, documentation needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14492) Java thin client: Refactor notification listener
Aleksey Plekhanov created IGNITE-14492: -- Summary: Java thin client: Refactor notification listener Key: IGNITE-14492 URL: https://issues.apache.org/jira/browse/IGNITE-14492 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.11 To avoid iteration over all registered listeners, listeners should be registered for given notification type and resource ID. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14341) Significant performance drop when entries expiring concurrently
Aleksey Plekhanov created IGNITE-14341:
--
Summary: Significant performance drop when entries expiring
concurrently
Key: IGNITE-14341
URL: https://issues.apache.org/jira/browse/IGNITE-14341
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Currently, there is a significant performance drop when expired entries
concurrently evicted by threads that perform some actions with cache (see
attached reproducer):
{noformat}
Benchmark Mode Cnt Score Error Units
JmhCacheExpireBenchmark.putWithExpire thrpt3 100,132 ± 21,025 ops/ms
JmhCacheExpireBenchmark.putWithoutExpire thrpt3 2133,122 ± 559,694
ops/ms{noformat}
Root cause: pending entries tree (offheap BPlusTree) is used to track expired
entries, after each cache operation (and by timeout thread) there is an attempt
to evict some amount of expired entries. these entries looked up from the start
of the pending entries tree and there is a contention on the first leaf page of
that tree.
All threads waiting for the same page lock:
{noformat}
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
org.apache.ignite.internal.util.OffheapReadWriteLock.waitAcquireWriteLock(OffheapReadWriteLock.java:503)
at
org.apache.ignite.internal.util.OffheapReadWriteLock.writeLock(OffheapReadWriteLock.java:244)
at
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.writeLock(PageMemoryNoStoreImpl.java:528)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock(PageHandler.java:422)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:350)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:325)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$13200(BPlusTree.java:100)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:4588)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:4567)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.tryRemoveFromLeaf(BPlusTree.java:5196)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Remove.access$6800(BPlusTree.java:4209)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2189)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2165)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2165)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:2076)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1905)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1426)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1375)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:246)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:882){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14171) Flaky IgniteSpringBeanSpringResourceInjectionTest.testSpringResourceInjectedInService
Aleksey Plekhanov created IGNITE-14171:
--
Summary: Flaky
IgniteSpringBeanSpringResourceInjectionTest.testSpringResourceInjectedInService
Key: IGNITE-14171
URL: https://issues.apache.org/jira/browse/IGNITE-14171
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test failing with exception:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.spring.injection.IgniteSpringBeanSpringResourceInjectionTest$2.getInjectedBean(IgniteSpringBeanSpringResourceInjectionTest.java:216)
at
org.apache.ignite.spring.injection.IgniteSpringBeanSpringResourceInjectionTest$TestSpringResourceInjectedRunnable.run(IgniteSpringBeanSpringResourceInjectionTest.java:159){noformat}
Reason: after IGNITE-14112 Ignite node start faster and async service
initialization sometimes can't be finished before user code start to use Ignite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14136) ServicesTest.testServiceTimeout is flaky
Aleksey Plekhanov created IGNITE-14136: -- Summary: ServicesTest.testServiceTimeout is flaky Key: IGNITE-14136 URL: https://issues.apache.org/jira/browse/IGNITE-14136 Project: Ignite Issue Type: Bug Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov The test is flaky because the timeout worker sometimes started after the task with the given sleep time is completed. In this case response with success returned by this task instead of timeout response. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13896) Javadoc build failed due to new not grouped packages
Aleksey Plekhanov created IGNITE-13896:
--
Summary: Javadoc build failed due to new not grouped packages
Key: IGNITE-13896
URL: https://issues.apache.org/jira/browse/IGNITE-13896
Project: Ignite
Issue Type: Bug
Affects Versions: 2.10
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.10
Fail on:
{noformat}
mvn initialize -Pjavadoc
{noformat}
Error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run
(javadoc-postprocessing-new) on project apache-ignite: An Ant BuildException
has occured: Execution failed due to: 'Other Packages' section should not be
present, all packages should have corresponding documentation groups:
/Users/sbt-plekhanov-as/IdeaProjects/ignite/target/javadoc/core/overview-summary.html;Please
add packages description to parent/pom.xml into (maven-javadoc-plugin)
/ /
{noformat}
Packages in the "Other packages" section:
{noformat}
org.apache.ignite.kubernetes.configuration
org.apache.ignite.maintenance
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13880) Flaky PageMemoryTracker related tests
Aleksey Plekhanov created IGNITE-13880: -- Summary: Flaky PageMemoryTracker related tests Key: IGNITE-13880 URL: https://issues.apache.org/jira/browse/IGNITE-13880 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov PageMemoryTracker related tests (CpTriggeredWalDeltaConsistencyTest, ExplicitWalDeltaConsistencyTest, SysPropWalDeltaConsistencyTest) are flaky on TC, probably because off-heap memory is not filled with zeros after allocation by PageMemoryTracker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13761) Implement LRU-based page replacement algorithm
Aleksey Plekhanov created IGNITE-13761: -- Summary: Implement LRU-based page replacement algorithm Key: IGNITE-13761 URL: https://issues.apache.org/jira/browse/IGNITE-13761 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov See IEP-62 for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13747) Coordinator failure after node left: Unexpected rebalance on rebalanced cluster
Aleksey Plekhanov created IGNITE-13747:
--
Summary: Coordinator failure after node left: Unexpected rebalance
on rebalanced cluster
Key: IGNITE-13747
URL: https://issues.apache.org/jira/browse/IGNITE-13747
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Exchange worker terminated on a coordinator after node left in some cases with
stack trace:
{noformat}
java.lang.AssertionError: Unexpected rebalance on rebalanced cluster:
assignments=GridDhtPreloaderAssignments [exchangeId=GridDhtPartitionExchangeId
[topVer=AffinityTopologyVersion [topVer=67, minorTopVer=0],
discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=0f61f2f6-6ffb-4772-a6a6-d2f41162, consistentId=127.0.0.1:47502,
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47502],
discPort=47502, order=66, intOrder=35, lastExchangeTime=1606212165542,
loc=false, ver=2.10.0#20201124-sha1:, isClient=false], topVer=67,
msgTemplate=null,
span=org.apache.ignite.internal.processors.tracing.NoopSpan@73893b7d,
nodeId8=30b8d2de, msg=Node left, type=NODE_LEFT, tstamp=1606212166204],
nodeId=0f61f2f6, evt=NODE_LEFT], topVer=AffinityTopologyVersion [topVer=67,
minorTopVer=0], cancelled=false, affinityReassign=false,
super={TcpDiscoveryNode [id=cfa40f59-ed19-4d5e-9d62-55f44a11,
consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
lastExchangeTime=1606212120855, loc=false, ver=2.10.0#20201124-sha1:,
isClient=false]=GridDhtPartitionDemandMessage [rebalanceId=506,
parts=IgniteDhtDemandedPartitionsMap [historical=null, full=HashSet [8]],
timeout=0, workerId=-1, topVer=AffinityTopologyVersion [topVer=67,
minorTopVer=0], partCnt=1, super=GridCacheGroupIdMessage [grpId=94416770]]}],
locPart=[topVer=AffinityTopologyVersion [topVer=67, minorTopVer=0],
lastChangeTopVer=AffinityTopologyVersion [topVer=67, minorTopVer=0],
waitRebalance=false, nodes=[cfa40f59-ed19-4d5e-9d62-55f44a11,
30b8d2de-d610-4dd4-aff2-fe4098b0], locPart=GridDhtLocalPartition
[rmvQueueMaxSize=1024, rmvdEntryTtl=1, id=8, delayedRenting=true,
finishFutRef=null, clearVer=1606261964138, grp=cache, state=MOVING,
reservations=0, empty=false, createTime=11/24/2020 13:02:45, fullSize=68,
cntr=Counter [init=0, val=2003]], ver4=AffinityTopologyVersion [topVer=67,
minorTopVer=0], affOwners4=[cfa40f59-ed19-4d5e-9d62-55f44a11,
30b8d2de-d610-4dd4-aff2-fe4098b0], ver3=AffinityTopologyVersion [topVer=66,
minorTopVer=0], affOwners3=[cfa40f59-ed19-4d5e-9d62-55f44a11,
0f61f2f6-6ffb-4772-a6a6-d2f41162], ver2=AffinityTopologyVersion [topVer=65,
minorTopVer=0], affOwners2=[cfa40f59-ed19-4d5e-9d62-55f44a11,
30b8d2de-d610-4dd4-aff2-fe4098b0], ver1=AffinityTopologyVersion [topVer=64,
minorTopVer=0], affOwners1=[cfa40f59-ed19-4d5e-9d62-55f44a11,
259eb107-e17a-4a8f-9ad8-4653f852], ver0=AffinityTopologyVersion [topVer=63,
minorTopVer=0], affOwners0=[cfa40f59-ed19-4d5e-9d62-55f44a11,
30b8d2de-d610-4dd4-aff2-fe4098b0]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.generateAssignments(GridDhtPreloader.java:302)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3483)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3184)
{noformat}
Reproducer:
{code:java}
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setCacheConfiguration(new CacheConfiguration<>("cache")
.setBackups(1)
.setEvictionPolicyFactory(() -> new
LruEvictionPolicy<>().setMaxSize(100))
.setOnheapCacheEnabled(true)
.setNearConfiguration(new NearCacheConfiguration<>())
.setAffinity(new RendezvousAffinityFunction(false, 10))
);
}
@Test
public void test() throws Exception {
startGrids(4);
try {
AtomicInteger gridIdx = new AtomicInteger();
long ts = U.currentTimeMillis();
GridTestUtils.runMultiThreadedAsync(() -> {
IgniteCache cache =
grid(gridIdx.getAndIncrement()).cache("cache");
while (U.currentTimeMillis() - ts < 150_000L)
cache.put(ThreadLocalRandom.current().nextInt(100_000), 0);
}, 2, "put-worker");
while (U.currentTimeMillis() - ts < 150_000L) {
stopGrid(2);
startGrid(2);
}
}
finally {
stopAllGrids();
}
}
{code}
Also test
[jira] [Created] (IGNITE-13726) Add an ability to view count of hot and cold pages in page memory
Aleksey Plekhanov created IGNITE-13726: -- Summary: Add an ability to view count of hot and cold pages in page memory Key: IGNITE-13726 URL: https://issues.apache.org/jira/browse/IGNITE-13726 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, we can't determine how many hot (touched recently) and cold pages we have in the page-memory. This information can be helpful for data region size tuning and can show the effectiveness of the page replacement algorithm. Such information can be represented as a histogram showing the count of pages last touched in each time interval. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13685) Flaky failure of FunctionalTest.testOptimitsticRepeatableReadUpdatesValue
Aleksey Plekhanov created IGNITE-13685:
--
Summary: Flaky failure of
FunctionalTest.testOptimitsticRepeatableReadUpdatesValue
Key: IGNITE-13685
URL: https://issues.apache.org/jira/browse/IGNITE-13685
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test FunctionalTest.testOptimitsticRepeatableReadUpdatesValue is flaky
Root cause: {{get()}} method on {{ForkJoinTask}} sometimes can help with the
execution of the task in common {{ForkJoinPool}}, so task is executed in the
current thread, that already holds a transaction, end {{cache.get()}} method
returns a value relative to this transaction.
See sack trace:
{noformat}
java.util.concurrent.ExecutionException: org.junit.ComparisonFailure:
expected: but was:
at java.base/java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1006)
at
org.apache.ignite.client.FunctionalTest.testOptimitsticRepeatableReadUpdatesValue(FunctionalTest.java:719)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.junit.ComparisonFailure: expected: but was:
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.ignite.client.FunctionalTest.lambda$testOptimitsticRepeatableReadUpdatesValue$10(FunctionalTest.java:712)
at
java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinTask.tryExternalHelp(ForkJoinTask.java:381)
at
java.base/java.util.concurrent.ForkJoinTask.externalInterruptibleAwaitDone(ForkJoinTask.java:351)
at java.base/java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1004)
... 13 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13676) Java thin client: Message not fully read by client after SECURITY_VIOLATION error
Aleksey Plekhanov created IGNITE-13676: -- Summary: Java thin client: Message not fully read by client after SECURITY_VIOLATION error Key: IGNITE-13676 URL: https://issues.apache.org/jira/browse/IGNITE-13676 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov In case of SECURITY_VIOLATION error client does not fully read message, these leads to phantom messages and connection drop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13657) Flaky test TxOptimisticDeadlockDetectionCrossCacheTest
Aleksey Plekhanov created IGNITE-13657: -- Summary: Flaky test TxOptimisticDeadlockDetectionCrossCacheTest Key: IGNITE-13657 URL: https://issues.apache.org/jira/browse/IGNITE-13657 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Test TxOptimisticDeadlockDetectionCrossCacheTest is flaky with about 13% failure rate. Reason: EVT_CACHE_OBJECT_LOCKED is not listened by default. This event should be added as interested explicitly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13653) Don't print warning if unordered map used for bulk update operation on atomic cache
Aleksey Plekhanov created IGNITE-13653: -- Summary: Don't print warning if unordered map used for bulk update operation on atomic cache Key: IGNITE-13653 URL: https://issues.apache.org/jira/browse/IGNITE-13653 Project: Ignite Issue Type: Improvement Environment: Since IGNITE-12451 is resolved there no more deadlock possible for atomic caches and it's safe to use HashMap and other unordered maps as argument of putAll/removeAll/invokeAll operations on atomic caches. Warning, introduced by IGNITE-6804, is not required anymore. Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13623) Scaladoc not created during release process
Aleksey Plekhanov created IGNITE-13623: -- Summary: Scaladoc not created during release process Key: IGNITE-13623 URL: https://issues.apache.org/jira/browse/IGNITE-13623 Project: Ignite Issue Type: Bug Components: build Affects Versions: 2.8.1, 2.9, 2.8 Reporter: Aleksey Plekhanov Fix For: 2.10 Scaladoc creation is broken (probably by IGNITE-11933). We have 3 release assemblies without scaladoc now (2.8, 2.8.1, 2.9). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13516) Folder binary_meta/$consistentId created for in-memory cluster and failed to start the node sometimes
Aleksey Plekhanov created IGNITE-13516: -- Summary: Folder binary_meta/$consistentId created for in-memory cluster and failed to start the node sometimes Key: IGNITE-13516 URL: https://issues.apache.org/jira/browse/IGNITE-13516 Project: Ignite Issue Type: Bug Affects Versions: 2.9 Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.9 For in-memory cluster consistentId is generated in the old style, using all local addresses. This consistent id can sometimes have a length of more than 255 chars and can't be used as a directory name. After IGNITE-11073 Ignite always creates folder binary_meta/$consistentId, but this folder should be created only if persistence is enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
Aleksey Plekhanov created IGNITE-13514:
--
Summary: Apache Ignite Slim edition builds without
config/default-config.xml
Key: IGNITE-13514
URL: https://issues.apache.org/jira/browse/IGNITE-13514
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
{{config/default-config.xml}} is absent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13465) Ignite cluster falls apart if two nodes segmented sequentially
Aleksey Plekhanov created IGNITE-13465: -- Summary: Ignite cluster falls apart if two nodes segmented sequentially Key: IGNITE-13465 URL: https://issues.apache.org/jira/browse/IGNITE-13465 Project: Ignite Issue Type: Bug Affects Versions: 2.9 Reporter: Aleksey Plekhanov Fix For: 2.9 After ticket IGNITE-13134 sequential nodes segmentation leads to segmentation of other nodes in the cluster. Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13440) JDBC thin: extend compatibility tests
Aleksey Plekhanov created IGNITE-13440: -- Summary: JDBC thin: extend compatibility tests Key: IGNITE-13440 URL: https://issues.apache.org/jira/browse/IGNITE-13440 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Additionally to basic compatibility test (JdbcThinCompatibilityTest) we should check for appropriate pairs of versions: * authentication; * user attributes; * manual disable features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13414) JDBC thin: compatibility is broken for versions 2.8-2.9
Aleksey Plekhanov created IGNITE-13414:
--
Summary: JDBC thin: compatibility is broken for versions 2.8-2.9
Key: IGNITE-13414
URL: https://issues.apache.org/jira/browse/IGNITE-13414
Project: Ignite
Issue Type: Bug
Components: jdbc
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Fix For: 2.9
"User attributes" feature was added by IGNITE-12049, it was added in 2.9
version, but for VER_2_8_0 condition:
{code:java}
if (ver.compareTo(VER_2_8_0) >= 0) {
dataPageScanEnabled = nullableBooleanFromByte(reader.readByte());
updateBatchSize = JdbcUtils.readNullableInteger(reader);
userAttrs = reader.readMap();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13411) Optimize tracing when NoopTracingSpi is used
Aleksey Plekhanov created IGNITE-13411:
--
Summary: Optimize tracing when NoopTracingSpi is used
Key: IGNITE-13411
URL: https://issues.apache.org/jira/browse/IGNITE-13411
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Current tracing implementation has some redundant actions for no-op tracing SPI
which have a negative impact on performance:
# {{GridNioTracerFilter}} added to communication SPI filters chain even if
tracing is disabled.
# {{MTC.support}}/{{MTC.supportContinual}} methods in case of no-op span or
null span return {{TracingSurrounding}} which equivalently does nothing
({{span.set(oldSpan)}} is redundant, since {{span.set(startSpan)}} was skipped
for no-op or null span, and {{endRequired}} is always {{false}}. So, instead of
creating new {{TracingSurrounding}} we can return {{null}} (correctly processed
by try-with resource block) with the same effect and get rid of some code on
the hot path.
# Sometimes we already have {{Span}} on hands and call to {{MTC.span()}} is
redundant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13335) Document changes to thin client binary protocol
Aleksey Plekhanov created IGNITE-13335: -- Summary: Document changes to thin client binary protocol Key: IGNITE-13335 URL: https://issues.apache.org/jira/browse/IGNITE-13335 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Currently, only the initial version of binary protocol is documented. There were a lot of changes and a lot of features implemented after initial implementation. These protocol changes should be documented to help to implement features by existing clients and to simplify new clients implementations. Some of protocol changes already described on corresponding IEP pages: * https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients * https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support * https://cwiki.apache.org/confluence/display/IGNITE/IEP-42+Thin+client%3A+compute+support * https://cwiki.apache.org/confluence/display/IGNITE/IEP-46%3A+Thin+Client+Service+Invocation * https://cwiki.apache.org/confluence/display/IGNITE/IEP-50%3A+Thin+Client+Continuous+Queries * https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery Some features were implemented without an IEP: * Expiration policies * Cluster API * Cluster group API * User attributes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13334) Document initial tracing implementation
Aleksey Plekhanov created IGNITE-13334: -- Summary: Document initial tracing implementation Key: IGNITE-13334 URL: https://issues.apache.org/jira/browse/IGNITE-13334 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Fix For: 2.9 Document initial tracing implementation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13333) Document TDE master key rotation
Aleksey Plekhanov created IGNITE-1: -- Summary: Document TDE master key rotation Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Fix For: 2.9 Document TDE master key rotation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13332) Document .NET Native Near Cache
Aleksey Plekhanov created IGNITE-13332: -- Summary: Document .NET Native Near Cache Key: IGNITE-13332 URL: https://issues.apache.org/jira/browse/IGNITE-13332 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Fix For: 2.9 Document .NET Native Near Cache -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13331) Document .NET thin client features implemented in 2.9 release
Aleksey Plekhanov created IGNITE-13331: -- Summary: Document .NET thin client features implemented in 2.9 release Key: IGNITE-13331 URL: https://issues.apache.org/jira/browse/IGNITE-13331 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Fix For: 2.9 Document .NET thin client features: * Cluster API * Cluster group API * Compute API * Server discovery * Continues queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13330) Document java thin client 2.8 and 2.9 release features
Aleksey Plekhanov created IGNITE-13330: -- Summary: Document java thin client 2.8 and 2.9 release features Key: IGNITE-13330 URL: https://issues.apache.org/jira/browse/IGNITE-13330 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Fix For: 2.9 Document implemented in 2.8 and 2.9 release features for java thin client: * Partition awareness * Cluster API * Cluster group API * Compute * Services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13300) Ignite sandbox vulnerability allows to execute user code in privileged proxy
Aleksey Plekhanov created IGNITE-13300:
--
Summary: Ignite sandbox vulnerability allows to execute user code
in privileged proxy
Key: IGNITE-13300
URL: https://issues.apache.org/jira/browse/IGNITE-13300
Project: Ignite
Issue Type: Bug
Components: security
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Ignite sandbox returns a privileged proxy for Ignite and some other system
interfaces. If the user implements one of these interfaces and gets via
privileged proxy an instance of implemented class, privileged proxy for user
class will be returned.
Reproducer:
{code:java}
public void testPrivelegedUserObject() throws Exception {
grid(CLNT_FORBIDDEN_WRITE_PROP).getOrCreateCache(DEFAULT_CACHE_NAME).put(0, new
TestIterator<>());
runForbiddenOperation(() ->
grid(CLNT_FORBIDDEN_WRITE_PROP).compute().run(() -> {
GridIterator it =
(GridIterator)Ignition.localIgnite().cache(DEFAULT_CACHE_NAME).get(0);
it.iterator();
}), AccessControlException.class);
}
public static class TestIterator extends GridIterableAdapter {
public TestIterator() {
super(Collections.emptyIterator());
}
@Override public GridIterator iterator() {
controlAction();
return super.iterator();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13294) Page write throttling can park threads for too long
Aleksey Plekhanov created IGNITE-13294:
--
Summary: Page write throttling can park threads for too long
Key: IGNITE-13294
URL: https://issues.apache.org/jira/browse/IGNITE-13294
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Page write throttling incorrectly calculate average checkpoint write speed in
some circumstances (gets wrong interval for calculation), this leads to parking
threads for too long.
Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open new
interval for {{speedCpWrite}} after
{{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
begin.
Reproducer: {{PagesWriteThrottleSmokeTest#testThrottle}}, currently always
failed in master
(https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13249) Update Ignite version to 2.10.0-SNAPSHOT
Aleksey Plekhanov created IGNITE-13249: -- Summary: Update Ignite version to 2.10.0-SNAPSHOT Key: IGNITE-13249 URL: https://issues.apache.org/jira/browse/IGNITE-13249 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Master branch should have 2.10.0-SNAPSHOT version after release 2.9 branch has created. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13202) Javadoc HTML can't be generated correctly with maven-javadoc-plugin on JDK 11+
Aleksey Plekhanov created IGNITE-13202:
--
Summary: Javadoc HTML can't be generated correctly with
maven-javadoc-plugin on JDK 11+
Key: IGNITE-13202
URL: https://issues.apache.org/jira/browse/IGNITE-13202
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Javadoc utility has some bugs which don't allow to build Ignite Javadocs
correctly.
Building javadoc under JDK 11+ throws an error "The code being documented uses
modules but the packages defined in
https://docs.oracle.com/javase/8/docs/api are in the unnamed module". To
workaround this error argument "source=1.8" can be specified, but there is
another bug related to "source" and "subpackages" argument usages:
[https://bugs.openjdk.java.net/browse/JDK-8193030.] We still can build javadoc
with disabled {{detectJavaApiLink}} maven-javadoc-plugin option, but in this
case there will be no references to Java API from Ignite Javadoc.
Also, there is a bug with "-exclude" argument in JDK 11+, it doesn't exclude
subpackages of specified to exclude packages, so in generated output there is a
lot of javadocs for internal packages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13172) Module ignite-scalar compilation error on JDK 11+
Aleksey Plekhanov created IGNITE-13172:
--
Summary: Module ignite-scalar compilation error on JDK 11+
Key: IGNITE-13172
URL: https://issues.apache.org/jira/browse/IGNITE-13172
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Module ignite-scalar can't be compiled by maven on JDK 11+.
There is an error on scala-maven-plugin:3.3.2:compile phase:
{noformat}
[ERROR] error: java.lang.NoClassDefFoundError: javax/tools/ToolProvider
[INFO] at
scala.reflect.io.JavaToolsPlatformArchive.iterator(ZipArchive.scala:301)
[INFO] at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
[INFO] at scala.reflect.io.AbstractFile.foreach(AbstractFile.scala:92)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13170) Java thin client: Transactions functionality withLabel is broken
Aleksey Plekhanov created IGNITE-13170:
--
Summary: Java thin client: Transactions functionality withLabel is
broken
Key: IGNITE-13170
URL: https://issues.apache.org/jira/browse/IGNITE-13170
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer
{code:java}
@Test
public void testTransactions1() throws Exception {
try (Ignite ignite = Ignition.start(Config.getServerConfiguration());
IgniteClient client = Ignition.startClient(getClientConfiguration()))
{
ClientCache cache = client.createCache(new
ClientCacheConfiguration()
.setName("cache")
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
cache.put(1, "value1");
try (ClientTransaction tx =
client.transactions().withLabel("asdasda").txStart()) {
cache.put(1, "value2");
}
assertEquals("value1", cache.get(1));
}
}
{code}
Root cause: a new instance of transactions facade is created when {{withLabel}}
modificator is used. Transactions are registered in {{threadLocTxUid}} map of
this instance, but when any cache operation is performed transaction is looked
only at root {{threadLocTxUid}} map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13164) Thin client: Fix nodeIds format for execute compute tasks request
Aleksey Plekhanov created IGNITE-13164: -- Summary: Thin client: Fix nodeIds format for execute compute tasks request Key: IGNITE-13164 URL: https://issues.apache.org/jira/browse/IGNITE-13164 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, each node id in thin client execute compute task request is written using 17 bytes (1 byte for type id and 16 bytes for UUID raw data). Since we don't need information about type id and node id can't be null we can write only UUID raw data as now implemented for service invoke request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13145) NPE on node stop can cause JVM halt with default failure handler
Aleksey Plekhanov created IGNITE-13145:
--
Summary: NPE on node stop can cause JVM halt with default failure
handler
Key: IGNITE-13145
URL: https://issues.apache.org/jira/browse/IGNITE-13145
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
{{TcpCommunicationSpi}} have injected {{@IgniteLogger}} resource.
{{TcpCommunicationSpi.sendMessage0}} tries to access this resource without null
check, but when the node is stopping injected resources are cleaned up. If some
threads are trying to send something via communication SPI on stopping node,
NPE is thrown with subsequent failure handler call and JVM halt with default
failure handler. This is undesirable when Ignite is running in embedded mode
since all other JVM applications will be stopped.
Error stack:
{noformat}
[11:34:39,194][SEVERE][sys-stripe-11-#8570%280332bb-89f3-4227-9d14-c319bbf3ca0c%][]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2898)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2882)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3643)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3889)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
[11:34:39,214][SEVERE][sys-stripe-11-#8570%280332bb-89f3-4227-9d14-c319bbf3ca0c%][]
JVM will be halted immediately due to the failure: [failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]{noformat}
This problem occurs often on team-city in "Java thin client" suite
(ReliabilityTest#testFailover).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13135) CacheRegisterMetadataLocallyTest.testClientFindsValueByAffinityKeyStaticCacheWithoutExtraRequest failed
Aleksey Plekhanov created IGNITE-13135:
--
Summary:
CacheRegisterMetadataLocallyTest.testClientFindsValueByAffinityKeyStaticCacheWithoutExtraRequest
failed
Key: IGNITE-13135
URL: https://issues.apache.org/jira/browse/IGNITE-13135
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test failed with error:
{noformat}
java.lang.AssertionError: []
Expected :2
Actual :0
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertEquals(JUnitAssertAware.java:119)
at
org.apache.ignite.internal.processors.cache.CacheRegisterMetadataLocallyTest.assertCustomMessages(CacheRegisterMetadataLocallyTest.java:230)
at
org.apache.ignite.internal.processors.cache.CacheRegisterMetadataLocallyTest.testClientFindsValueByAffinityKeyStaticCacheWithoutExtraRequest(CacheRegisterMetadataLocallyTest.java:153){noformat}
After fix IGNITE-13096
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13106) Java thin client: Race between response and notification for compute tasks
Aleksey Plekhanov created IGNITE-13106:
--
Summary: Java thin client: Race between response and notification
for compute tasks
Key: IGNITE-13106
URL: https://issues.apache.org/jira/browse/IGNITE-13106
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Java thin client {{ClientCompute.execute()}} method can hang due to race
between processing of COMPUTE_TASK_EXECUTE response and COMPUTE_TASK_FINISHED
notification.
These messages are strongly ordered on the server-side. But on the client-side
response and notification are processed by different threads. If notification
will be processed before response, task future will never be completed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13096) Java thin client: Binary type schema is not registered for nested objects when CompactFooter is enabled
Aleksey Plekhanov created IGNITE-13096:
--
Summary: Java thin client: Binary type schema is not registered
for nested objects when CompactFooter is enabled
Key: IGNITE-13096
URL: https://issues.apache.org/jira/browse/IGNITE-13096
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
When we first time marshal object, a binary type registration request is sent
to the server. This request contains schemas for deserialization
(deserialization without schema is not possible when CompactFooter is enabled).
If the object contains references to objects of other types these types also
sent to the server, but without schemas.
Reproducer:
{code:java}
try (Ignite ignite = Ignition.start(Config.getServerConfiguration())) {
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses(Config.SERVER)
.setBinaryConfiguration(new
BinaryConfiguration().setCompactFooter(true)))
) {
IgniteCache igniteCache =
ignite.getOrCreateCache(Config.DEFAULT_CACHE_NAME);
ClientCache clientCache =
client.getOrCreateCache(Config.DEFAULT_CACHE_NAME);
Person[] val = new Person[] {new Person(1, "Joe")};
clientCache.put(1, val);
assertArrayEquals(val, igniteCache.get(1));
}
}
{code}
Fails with exception:
{noformat}
Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find
schema for object with compact footer
[typeName=org.apache.ignite.client.Person, typeId=1468224522,
missingSchemaId=970781171, existingSchemaIds=[]]
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2028)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:287)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:186)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:793){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13074) Thin client: Default compute cluster group should be "server nodes", but currently "all nodes"
Aleksey Plekhanov created IGNITE-13074: -- Summary: Thin client: Default compute cluster group should be "server nodes", but currently "all nodes" Key: IGNITE-13074 URL: https://issues.apache.org/jira/browse/IGNITE-13074 Project: Ignite Issue Type: Bug Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov When executing compute tasks from thin client without specifying cluster group, tasks should be executed only on server nodes. But currently client nodes are also included. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13033) Java thin client: Service invocation
Aleksey Plekhanov created IGNITE-13033: -- Summary: Java thin client: Service invocation Key: IGNITE-13033 URL: https://issues.apache.org/jira/browse/IGNITE-13033 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Provide an API to invoke Ignite Services from java thin client. Protocol changes and all implementation details described in IEP-46. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12964) Java thin client: implement cluster group API
Aleksey Plekhanov created IGNITE-12964:
--
Summary: Java thin client: implement cluster group API
Key: IGNITE-12964
URL: https://issues.apache.org/jira/browse/IGNITE-12964
Project: Ignite
Issue Type: New Feature
Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Implement API for node filtering on java thin client side. Thin-client API
should match thick-client API ({{ClusterGroup}}, {{ClusterNode}} classes) as
much as possible.
Already implemented server-side thin-client operations
OP_CLUSTER_GROUP_GET_NODE_IDS, OP_CLUSTER_GROUP_GET_NODE_INFO should be used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12962) Blacklist and whitelist of classes allowed to deserialize via HTTP-REST should be supported
Aleksey Plekhanov created IGNITE-12962:
--
Summary: Blacklist and whitelist of classes allowed to deserialize
via HTTP-REST should be supported
Key: IGNITE-12962
URL: https://issues.apache.org/jira/browse/IGNITE-12962
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Aleksey Plekhanov
Since we have the ability to deserialize custom objects (implemented by
IGNITE-12857) we should have the ability to limit the scope of classes allowed
to safe deserialization.
There are already two system properties used for such purpose in Ignite:
{code:java}
/** Defines path to the file that contains list of classes allowed to safe
deserialization.*/
public static final String IGNITE_MARSHALLER_WHITELIST =
"IGNITE_MARSHALLER_WHITELIST";
/** Defines path to the file that contains list of classes disallowed to safe
deserialization.*/
public static final String IGNITE_MARSHALLER_BLACKLIST =
"IGNITE_MARSHALLER_BLACKLIST";{code}
HTTP-REST should support these properties too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
Aleksey Plekhanov created IGNITE-12933:
--
Summary: Node failed after put incorrect key class for indexed
type to transactional cache
Key: IGNITE-12933
URL: https://issues.apache.org/jira/browse/IGNITE-12933
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Reproducer:
{code:java}
public class IndexedTypesTest extends GridCommonAbstractTest {
private boolean failed;
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setFailureHandler((ignite, ctx) -> failed = true)
.setCacheConfiguration(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setAtomicityMode(TRANSACTIONAL)
.setIndexedTypes(String.class, String.class));
}
@Test
public void testPutIndexedType() throws Exception {
Ignite ignite = startGrids(2);
for (int i = 0; i < 10; i++) {
try {
ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
}
catch (Exception ignore) {
}
}
assertFalse(failed);
}
}
{code}
Node failed with exception:
{noformat}
[2020-04-22
17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler
[hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a
transaction has produced runtime exception]]
class
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
Committing a transaction has produced runtime exception
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
index, incorrect key class [expCls=java.lang.String,
actualCls=java.lang.Integer]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2092)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:410)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2627)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1713)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1688)
at
[jira] [Created] (IGNITE-12857) Add ability to put non-primitive data types via HTTP-REST
Aleksey Plekhanov created IGNITE-12857:
--
Summary: Add ability to put non-primitive data types via HTTP-REST
Key: IGNITE-12857
URL: https://issues.apache.org/jira/browse/IGNITE-12857
Project: Ignite
Issue Type: Improvement
Components: rest
Reporter: Aleksey Plekhanov
Currently, we can get values with non-primitive data types via HTTP REST, they
are represented in JSON form, but we can't put such values into the cache. Put
can be used only with a limited set of data types (see
{{GridJettyRestHandler#convert}}).
The ability to put non-primitive data types should be added (binary object
should be created from JSON).
We should also check that the get operation for such data types after put
returns data in the same form. And inserted values correctly matched to query
entities for the cache (we should be able to select inserted data via SQL).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12855) Node failed after get operation when entries from the cache expired concurrently
Aleksey Plekhanov created IGNITE-12855:
--
Summary: Node failed after get operation when entries from the
cache expired concurrently
Key: IGNITE-12855
URL: https://issues.apache.org/jira/browse/IGNITE-12855
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Failed with the error:
{noformat}
[12:10:50] (err) Failed to notify listener:
o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter$6...@7c956694java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2456)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4401)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4095)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:767)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGetVersioned(GridCacheMapEntry.java:694)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2175)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:709)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:413)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:279)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:261)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:821)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:836)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:152)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:150)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
{noformat}
Reproducer:
{code:java}
@Test
public void shouldNotBeProblemToPutToExpiredCacheConcurrently() throws
Exception {
final AtomicBoolean end = new AtomicBoolean();
final IgniteEx srv = startGrid(3);
srv.cluster().active(true);
IgniteInternalFuture loadFut = runMultiThreadedAsync(() -> {
while (!end.get() && !fail) {
IgniteCache cache = srv.cache(CACHE_NAME);
for (int i = 0; i < ENTRIES; i++)
cache.put(i, new byte[1024]);
for (int i = 0; i < ENTRIES; i++)
cache.get(i); // touch entries
}
}, WORKLOAD_THREADS_CNT, "high-workload");
try {
loadFut.get(10, TimeUnit.SECONDS);
}
catch (Exception e) {
assertFalse("Failure handler was called. See log above.", fail);
assertTrue(X.hasCause(e, IgniteFutureTimeoutCheckedException.class));
}
finally {
end.set(true);
}
assertFalse("Failure handler was called. See log above.", fail);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12854) Node failed under load when ATOMIC and TRANSACTIONAL caches created in the same cache group
Aleksey Plekhanov created IGNITE-12854:
--
Summary: Node failed under load when ATOMIC and TRANSACTIONAL
caches created in the same cache group
Key: IGNITE-12854
URL: https://issues.apache.org/jira/browse/IGNITE-12854
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8, 2.9, 2.8.1
Reporter: Aleksey Plekhanov
Node failed with assertion error under concurrent puts to ATOMIC and
TRANSACTIONAL caches belonging to the same cache group:
{noformat}
java.lang.AssertionError: LWM after HWM: lwm=262, hwm=261
at
org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:262)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1601)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2162)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:1087)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:520)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1343)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:709)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1104)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:411)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:577)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:374)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:183)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:161)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:205)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:203)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120){noformat}
Reproducer:
{code:java}
public void testPartCounters() throws Exception {
final AtomicBoolean end = new AtomicBoolean();
final IgniteEx srv = startGrids(3);
srv.cluster().active(true);
IgniteInternalFuture loadFut = runMultiThreadedAsync(() -> {
while (!end.get() && !fail) {
List> caches = F.asList(
srv.getOrCreateCache(new CacheConfiguration<>(CACHE_NAME_ATOMIC)
.setAtomicityMode(CacheAtomicityMode.ATOMIC)
.setGroupName(GROUP_NAME)
),
srv.getOrCreateCache(new CacheConfiguration<>(CACHE_NAME_TX)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setGroupName(GROUP_NAME)
)
);
for (IgniteCache cache : caches) {
for (int i = 0; i < ENTRIES; i++)
cache.put(i, new byte[1024]);
}
}
}, WORKLOAD_THREADS_CNT, "async_runner");
try {
// Let's wait some time.
loadFut.get(10, TimeUnit.SECONDS);
}
catch (Exception e) {
assertFalse("Failure handler was called. See log above.", fail);
[jira] [Created] (IGNITE-12845) GridNioServer can infinitely lose some events
Aleksey Plekhanov created IGNITE-12845:
--
Summary: GridNioServer can infinitely lose some events
Key: IGNITE-12845
URL: https://issues.apache.org/jira/browse/IGNITE-12845
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
{{GridNioServer}} can lose some events for a channel (depending on JDK version
and OS). It can lead to connected applications hang. Reproducer:
{code:java}
public void testConcurrentLoad() throws Exception {
startGrid(0);
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
GridTestUtils.runMultiThreaded(
() -> {
for (int i = 0; i < 1000; i++)
cache.put(i, i);
}, 5, "run-async");
}
}
{code}
This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13, 14),
hangs on some Linux environments (for example passed more than 100 times on
desktop Linux system with JDK 8, but hangs on team-city agents with JDK 8, 11)
and never hanged (passed more than 100 times) on windows system, but passes on
all systems and JDK versions when system property {{IGNITE_NO_SELECTOR_OPTS =
true}} is set.
The root cause: optimized {{SelectedSelectionKeySet}} always returns {{false}}
for {{contains()}} method. The {{contains()}} method used by
{{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
{code:java}
if (selectedKeys.contains(ski)) {
if (ski.translateAndUpdateReadyOps(rOps)) {
return 1;
}
} else {
ski.translateAndSetReadyOps(rOps);
if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
selectedKeys.add(ski);
return 1;
}
}
{code}
So, for fair implementation, if a selection key is contained in the selected
keys set, then ready operations flags are updated, but for
{{SelectedSelectionKeySet}} ready operations flags will be always overridden
and new selector key will be added even if it's already contained in the set.
Some {{SelectorImpl}} implementations can pass several events for one selector
key to {{processReadyEvents }}method (for example, MacOs implementation
{{KQueueSelectorImpl}} works in such a way). In this case duplicated selector
keys will be added to {{selectedKeys}} and all events except last will be lost.
Two bad things happen in {{GridNioServer}} due to described above reasons:
# Some event flags are lost and the worker doesn't process corresponding
action (for attached reproducer "channel is ready for reading" event is lost
and the workers never read the channel after some point in time).
# Duplicated selector keys with the same event flags (for attached reproducer
it's "channel is ready for writing" event, this duplication leads to wrong
processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which will be
{{false}} in some cases, but at the same time selector key's {{interestedOps}}
will contain {{OP_WRITE}} operation and this operation never be excluded)
Possible solutions:
* Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
will solve all problems but can be resource consuming)
* Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when adding
{{OP_WRITE}} to {{interestedOps}} (for example in
{{AbstractNioClientWorker.registerWrite()}} method). In this case, some
"channel is ready for reading" events (but not data) still can be lost, but not
infinitely, and eventually data will be read.
* Exclude {{OP_WRITE}} from {{interestedOps}} even if
{{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
This solution has the same shortcomings as the previous one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12835) Thin client: compute support
Aleksey Plekhanov created IGNITE-12835: -- Summary: Thin client: compute support Key: IGNITE-12835 URL: https://issues.apache.org/jira/browse/IGNITE-12835 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Add compute grid functionality to thin clients. As a first step execution of task by task name should be added. Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12734) Scan query shutting down the node in some cases
Aleksey Plekhanov created IGNITE-12734:
--
Summary: Scan query shutting down the node in some cases
Key: IGNITE-12734
URL: https://issues.apache.org/jira/browse/IGNITE-12734
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer:
{code:java}
public class CachePartitionEvictionQueryTest extends GridCommonAbstractTest {
@Override protected IgniteConfiguration getConfiguration(String name)
throws Exception {
return super.getConfiguration(name).setDataStorageConfiguration(new
DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new
DataRegionConfiguration().setPersistenceEnabled(true)));
}
@Override protected FailureHandler getFailureHandler(String
igniteInstanceName) {
return new StopNodeFailureHandler();
}
@Test
public void testQuery() throws Exception {
startGrid(getConfiguration(getTestIgniteInstanceName(0)).setConsistentId("1"));
grid(0).cluster().active(true);
grid(0).cluster().baselineAutoAdjustEnabled(true);
grid(0).cluster().baselineAutoAdjustTimeout(0);
IgniteCache cache = grid(0).getOrCreateCache(
new CacheConfiguration(DEFAULT_CACHE_NAME).setBackups(0)
.setAffinity(new
RendezvousAffinityFunction().setPartitions(2)));
cache.put(0, 0);
cache.put(1, 1);
Iterator iter = grid(0).cache(DEFAULT_CACHE_NAME).query(new
ScanQuery<>().setPageSize(1)).iterator();
iter.next();
startGrid(getConfiguration(getTestIgniteInstanceName(1)).setConsistentId("0"));
awaitPartitionMapExchange();
forceCheckpoint(grid(0));
iter.next();
}
}
{code}
Node fails with the reason:
{noformat}
[2020-03-02
15:17:46,663][ERROR][test-runner-#1%cache.CachePartitionEvictionQueryTest%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [pages(groupId, pageId)=[], msg=Runtime failure on bounds:
[lower=null, upper=null
class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [pages(groupId, pageId)=[], msg=Runtime failure on bounds:
[lower=null, upper=null]]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5927)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1054)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:164)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.find(CacheDataTree.java:63)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.find(BPlusTree.java:1021)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2914)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2884)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2878)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:2866)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.cursor(GridCacheOffheapManager.java:2560)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.onHasNext(IgniteCacheOffheapManagerImpl.java:937)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3031)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:38)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at
[jira] [Created] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
Aleksey Plekhanov created IGNITE-12625:
--
Summary: Thin client: Marshaling/unmarshaling of objects performed
twice
Key: IGNITE-12625
URL: https://issues.apache.org/jira/browse/IGNITE-12625
Project: Ignite
Issue Type: Bug
Components: binary, thin client
Reporter: Aleksey Plekhanov
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects. Also, with binary object full byte array of this object is marshaled,
but object takes only some part of this array, it causes size overhead for
storing these objects.
To avoid double marshalling we could pass byte array from request content to
cache directly (for example using {{CacheObject}}), but we don't have object
size in thin client protocol, so in any case, we need to traverse the objects.
Also, we don't have the ability to get {{CacheObject}} from the cache now, so
such an approach will only work in one way, for "put" operations, but not for
"get" operations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12624) Java thin client: Wrong typeId generation for system types
Aleksey Plekhanov created IGNITE-12624:
--
Summary: Java thin client: Wrong typeId generation for system types
Key: IGNITE-12624
URL: https://issues.apache.org/jira/browse/IGNITE-12624
Project: Ignite
Issue Type: Bug
Components: binary, thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Thin client generates wrong {{typeId}} for system types. This is caused by
{{ClientMarshallerContext}} implementation, which always returns {{false}} for
{{isSystemType}} method. These leads to {{typeId}} duplication for the same
class and assertions when trying to get object by thick client. Reproducer:
{code:java}
thinClient.cache(DEFAULT_CACHE_NAME).put(1, CacheAtomicityMode.ATOMIC);
thickClient.cache(DEFAULT_CACHE_NAME).get(1);
{code}
Assertion:
{noformat}
java.lang.AssertionError: Duplicate typeId [typeId=1984564222, cls=class
org.apache.ignite.cache.CacheAtomicityMode, desc=BinaryClassDescriptor
[cls=class org.apache.ignite.cache.CacheAtomicityMode, serializer=null,
initialSerializer=null, mapper=BinaryInternalMapper
[nameMapper=BinaryBaseNameMapper [isSimpleName=true],
idMapper=BinaryBaseIdMapper [isLowerCase=true], checkOnZeroId=false],
mode=OPTIMIZED, userType=false, typeId=329149470,
typeName=org.apache.ignite.cache.CacheAtomicityMode, affKeyFieldName=null,
ctor=null, writeReplacer=null, readResolveMtd=null, stableSchema=null,
schemaReg=org.apache.ignite.internal.binary.BinarySchemaRegistry@167f45f8,
registered=true, useOptMarshaller=true, excluded=false,
stableSchemaPublished=false]]
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:775)
at
org.apache.ignite.internal.binary.BinaryUtils.resolveClass(BinaryUtils.java:1669)
at
org.apache.ignite.internal.binary.BinaryEnumObjectImpl.deserialize(BinaryEnumObjectImpl.java:178)
at
org.apache.ignite.internal.binary.BinaryEnumObjectImpl.value(BinaryEnumObjectImpl.java:284)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:136)
at
org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1814)
{noformat}
If we perform "put" operation with value of the same type from thick client
before "get" operation, there is no assertion anymore, but {{typeId}} is still
duplicated. And there is another issue: different marshallers can be used to
marshal the same class for thin and thick clients, wrong class descriptor is
returned for class name and there is assertion again. Reproducer:
{code:java}
thickClient.cache(DEFAULT_CACHE_NAME).put(3, Collections.emptyList());
thinClient.cache(DEFAULT_CACHE_NAME).put(2, Collections.emptyList());
thickClient.cache(DEFAULT_CACHE_NAME).get(2);
{code}
Assertion:
{noformat}
java.lang.AssertionError: OptimizedMarshaller should not be used here:
java.util.Collections$EmptyList
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:865)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:792)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:142)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:176)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12578) CAS cache operations (replace(K, V, V), remove(K, V)) don't work with array data type
Aleksey Plekhanov created IGNITE-12578:
--
Summary: CAS cache operations (replace(K, V, V), remove(K, V))
don't work with array data type
Key: IGNITE-12578
URL: https://issues.apache.org/jira/browse/IGNITE-12578
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Aleksey Plekhanov
Values are compared using {{CacheEntryPredicateContainsValue}} predicate, this
predicate call {{F.eq(thisVal, cacheVal)}} to compare, which gives false for
two instances of arrays with the same content.
Reproducer:
{code:java}
IgniteCache cache =
startGrid().getOrCreateCache(DEFAULT_CACHE_NAME);
Object val = new byte[] {1};
cache.put(1, val);
assertTrue(cache.replace(1, val, val));
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12562) FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions suite
Aleksey Plekhanov created IGNITE-12562: -- Summary: FreeListCachingTest.testPageListCacheLimit failing in Disk Page Compressions suite Key: IGNITE-12562 URL: https://issues.apache.org/jira/browse/IGNITE-12562 Project: Ignite Issue Type: Bug Components: persistence Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Test failing with IgniteOutOfMemory exception because Disk Page Compressions changes default page size to 8192, we need at least 2*1024 pages to store freelist metadata and there is no such amount of not dirty pages after checkpoint is triggered by "too many dirty page" reason. Explicitly defined data region max size should take into account page size to avoid such errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12557) Destroy of big cache which is not only cache in cache group couses IgniteOOME
Aleksey Plekhanov created IGNITE-12557:
--
Summary: Destroy of big cache which is not only cache in cache
group couses IgniteOOME
Key: IGNITE-12557
URL: https://issues.apache.org/jira/browse/IGNITE-12557
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
When {{destroyCache()}} is invoked {{checkpointReadLock}} is held by exchange
thread during all time cache entries is cleaning. Meanwhile,
{{db-checkpoint-thread}} can't acquire checkpoint write lock and can't start
checkpoint. After some time all page-memory has filled with dirty pages and
attempt to acquire a new page causes IgniteOOM exception:
{noformat}
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Failed to find
a page for eviction [segmentCapacity=40485, loaded=15881, maxDirtyPages=11910,
dirtyPages=15881, cpPages=0, pinnedInSegment=0, failedToPrepare=15881]
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.tryToFindSequentially(PageMemoryImpl.java:2420)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$Segment.removePageForReplacement(PageMemoryImpl.java:2314)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:743)
at
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:679)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:5872)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compareKeys(CacheDataTree.java:435)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:384)
at
org.apache.ignite.internal.processors.cache.tree.CacheDataTree.compare(CacheDataTree.java:63)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:5214)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:5134)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:298)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5723)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:278)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5709)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:169)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:364)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.read(BPlusTree.java:5910)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removeDown(BPlusTree.java:2077)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doRemove(BPlusTree.java:2007)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.removex(BPlusTree.java:1838)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.clear(IgniteCacheOffheapManagerImpl.java:2963)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.clear(GridCacheOffheapManager.java:2611)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.removeCacheData(IgniteCacheOffheapManagerImpl.java:296)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.stopCache(IgniteCacheOffheapManagerImpl.java:258)
at
org.apache.ignite.internal.processors.cache.CacheGroupContext.stopCache(CacheGroupContext.java:825)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1070)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2617)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2596)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$processCacheStopRequestOnExchangeDone$629e8679$1(GridCacheProcessor.java:2796)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11173)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11075)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2761)
at
[jira] [Created] (IGNITE-12530) Pages list caching can cause IgniteOOME when checkpoint is triggered by "too many dirty pages" reason
Aleksey Plekhanov created IGNITE-12530:
--
Summary: Pages list caching can cause IgniteOOME when checkpoint
is triggered by "too many dirty pages" reason
Key: IGNITE-12530
URL: https://issues.apache.org/jira/browse/IGNITE-12530
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
When a checkpoint is triggered, we need some amount of page memory to store
pages list on-heap cache.
If data region is too small, a checkpoint is triggered by "too many dirty
pages" reason and pages list cache is rather big, we can get
IgniteOutOfMemoryException.
Reproducer:
{code:java}
@Override protected IgniteConfiguration getConfiguration(String name) throws
Exception {
IgniteConfiguration cfg = super.getConfiguration(name);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)
.setMaxSize(50 * 1024 * 1024)
));
return cfg;
}
@Test
public void testUpdatesNotFittingIntoMemoryRegion() throws Exception {
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
ignite.getOrCreateCache(DEFAULT_CACHE_NAME);
try (IgniteDataStreamer streamer =
ignite.dataStreamer(DEFAULT_CACHE_NAME)) {
for (int i = 0; i < 100_000; i++)
streamer.addData(i, new byte[i % 2048]);
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12441) Refactor SystemViewRowAttributeWalker registration for system views
Aleksey Plekhanov created IGNITE-12441: -- Summary: Refactor SystemViewRowAttributeWalker registration for system views Key: IGNITE-12441 URL: https://issues.apache.org/jira/browse/IGNITE-12441 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, to register system view we need at least to actions: # Register walker for a system view class # Register system view itself for a given class There is a map maintained to bind the attribute walker and system view class. Sometimes walker registration code and system view registration code are located in different parts of Ignite. But in most cases, there is 1:1 relation between attribute walkers and system views. We don't need to maintain additional structures and do additional actions to find a walker by system view class, we can bind walker to system view itself. Moreover, in the current implementation, there is impossible to use different walkers for one system view class (for example when we want to create two views with the same system view class, but with different columns set) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12407) Java thin client: implement API for activation/deactivation and WAL enabling/disabling
Aleksey Plekhanov created IGNITE-12407: -- Summary: Java thin client: implement API for activation/deactivation and WAL enabling/disabling Key: IGNITE-12407 URL: https://issues.apache.org/jira/browse/IGNITE-12407 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement ClusterAPI methods already supported by protocol: isActive() setActive(active flag) isWalEnabled(cacheName) enableWal(cacheName) disableWal(cacheName) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12399) Java thin client: add cache expiry polocies
Aleksey Plekhanov created IGNITE-12399: -- Summary: Java thin client: add cache expiry polocies Key: IGNITE-12399 URL: https://issues.apache.org/jira/browse/IGNITE-12399 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.8 Implement: * Dynamic cache creation with expire policy. * Put data into the cache with expire policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12301) Free-lists system view
Aleksey Plekhanov created IGNITE-12301: -- Summary: Free-lists system view Key: IGNITE-12301 URL: https://issues.apache.org/jira/browse/IGNITE-12301 Project: Ignite Issue Type: Sub-task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement a system view for free-lists monitoring. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12292) Java thin client: In some cases txId intersection (tx started on different nodes) leads to errors
Aleksey Plekhanov created IGNITE-12292:
--
Summary: Java thin client: In some cases txId intersection (tx
started on different nodes) leads to errors
Key: IGNITE-12292
URL: https://issues.apache.org/jira/browse/IGNITE-12292
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.8
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
Reproducer:
{code:java}
public void testTxWithIdIntersection() throws Exception {
int CLUSTER_SIZE = 2;
try (LocalIgniteCluster cluster = LocalIgniteCluster.start(CLUSTER_SIZE);
IgniteClient client = Ignition.startClient(new ClientConfiguration()
.setAddresses(cluster.clientAddresses().toArray(new
String[CLUSTER_SIZE])))
) {
ClientCache cache = client.createCache(new
ClientCacheConfiguration().setName("cache")
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
CyclicBarrier barrier = new CyclicBarrier(2);
GridTestUtils.runAsync(() -> {
try {
// Another thread starts transaction here.
barrier.await(1, TimeUnit.SECONDS);
for (int i = 0; i < CLUSTER_SIZE; i++)
dropAllThinClientConnections(Ignition.allGrids().get(i));
ClientTransaction tx = client.transactions().txStart();
barrier.await(1, TimeUnit.SECONDS);
// Another thread puts to cache here.
barrier.await(1, TimeUnit.SECONDS);
tx.commit();
barrier.await(1, TimeUnit.SECONDS);
}
catch (Exception e) {
log.error("Unexpected error", e);
}
});
ClientTransaction tx = client.transactions().txStart();
barrier.await(1, TimeUnit.SECONDS);
// Another thread drops connections and create new transaction here,
which started on another node with the
// same transaction id as we started in this thread.
barrier.await(1, TimeUnit.SECONDS);
try {
cache.put(0, 0);
fail("Exception expected");
}
catch (ClientException expected) {
// No-op.
}
tx.close();
barrier.await(1, TimeUnit.SECONDS);
// Another thread commit transaction here.
barrier.await(1, TimeUnit.SECONDS);
assertFalse(cache.containsKey(0));
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12254) IO errors during write header of WAL files in FSYNC mode should be handled by failure handler
Aleksey Plekhanov created IGNITE-12254:
--
Summary: IO errors during write header of WAL files in FSYNC mode
should be handled by failure handler
Key: IGNITE-12254
URL: https://issues.apache.org/jira/browse/IGNITE-12254
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Currently, such errors can hang the cluster.
Reproducer:
{code:java}
@Test
public void testWalFsyncIOError() throws Exception {
cleanPersistenceDir();
IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setCacheConfiguration(new
CacheConfiguration(DEFAULT_CACHE_NAME).setAtomicityMode(ATOMIC));
cfg.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setMaxSize(100L * 1024 * 1024)
.setPersistenceEnabled(true))
.setWalMode(WALMode.FSYNC)
.setWalSegmentSize(512 * 1024)
.setWalBufferSize(512 * 1024));
IgniteEx ignite0 = startGrid(new
IgniteConfiguration(cfg).setIgniteInstanceName("ignite0"));
IgniteEx ignite1 = startGrid(new
IgniteConfiguration(cfg).setIgniteInstanceName("ignite1"));
ignite0.cluster().active(true);
IgniteCache cache = ignite0.cache(DEFAULT_CACHE_NAME);
for (int i = 0; i < 1_000; i++)
cache.put(i, "Test value " + i);
((FileWriteAheadLogManager)ignite1.context().cache().context().wal()).setFileIOFactory(new
FileIOFactory() {
FileIOFactory delegateFactory = new RandomAccessFileIOFactory();
@Override public FileIO create(File file, OpenOption... modes)
throws IOException {
final FileIO delegate = delegateFactory.create(file, modes);
return new FileIODecorator(delegate) {
@Override public int write(ByteBuffer srcBuf) throws
IOException {
throw new IOException("No space left on device");
}
};
}
});
for (int i = 0; i < 2_000; i++)
try {
cache.put(i, "Test value " + i);
}
catch (Exception ignore) {
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12252) Runtime exceptions during rebalancing should be handled
Aleksey Plekhanov created IGNITE-12252: -- Summary: Runtime exceptions during rebalancing should be handled Key: IGNITE-12252 URL: https://issues.apache.org/jira/browse/IGNITE-12252 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Rebalancing should handle runtime exceptions by failure handler. In current implementation runtime exceptions just ignored. They were handled by IO worker before IGNITE-3195. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12188) Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft doesn't work correctly if there is more then one cache in cache group
Aleksey Plekhanov created IGNITE-12188:
--
Summary: Metric CacheGroupMetrics.IndexBuildCountPartitionsLeft
doesn't work correctly if there is more then one cache in cache group
Key: IGNITE-12188
URL: https://issues.apache.org/jira/browse/IGNITE-12188
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Aleksey Plekhanov
Initial partitions counter is set to a total number of partitions for cache
group but decremented each time partition processed for each cache.
Reproducer:
{code:java}
@Test
public void testIndexRebuildMetrics() throws Exception {
IgniteConfiguration cfg = new IgniteConfiguration()
.setConsistentId("ignite")
.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new
DataRegionConfiguration().setPersistenceEnabled(true)))
.setCacheConfiguration(
new CacheConfiguration("c1").setGroupName("grp")
.setAffinity(new
RendezvousAffinityFunction().setPartitions(10))
.setIndexedTypes(Integer.class, Integer.class),
new CacheConfiguration("c2").setGroupName("grp")
.setAffinity(new
RendezvousAffinityFunction().setPartitions(10))
.setIndexedTypes(Integer.class, Integer.class)
);
IgniteEx ignite = startGrid(cfg);
ignite.cluster().active(true);
for (int i = 0; i < 10_000; i++) {
ignite.cache("c1").put(i, i);
ignite.cache("c2").put(i, i);
}
ignite.cluster().active(false);
File dir = U.resolveWorkDirectory(U.defaultWorkDirectory(),
DFLT_STORE_DIR, false);
U.delete(new File(dir, "ignite/cacheGroup-grp/index.bin"));
ignite.cluster().active(true);
doSleep(1_000L);
assertTrue(ignite.context().cache().cache("c1").context().group().metrics().getIndexBuildCountPartitionsLeft()
>= 0);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12147) Thin client: Partitions response doesn't contain caches for which affinity awareness is not applicable
Aleksey Plekhanov created IGNITE-12147: -- Summary: Thin client: Partitions response doesn't contain caches for which affinity awareness is not applicable Key: IGNITE-12147 URL: https://issues.apache.org/jira/browse/IGNITE-12147 Project: Ignite Issue Type: Bug Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov If information was requested for caches, for which affinity awareness is not applicable, then the response does not include information about these caches. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-11949) Yardstick benchmarks for WAL page snapshot compression
Aleksey Plekhanov created IGNITE-11949: -- Summary: Yardstick benchmarks for WAL page snapshot compression Key: IGNITE-11949 URL: https://issues.apache.org/jira/browse/IGNITE-11949 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov WAL page snapshots compression (implemented by IGNITE-11336) can be enabled by modifying config.xml file. It will be better to configure benchmarks by command line options. Also, some new probes (WAL size for example) can be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11911) GridToStringBuilder allocates redundant memory
Aleksey Plekhanov created IGNITE-11911:
--
Summary: GridToStringBuilder allocates redundant memory
Key: IGNITE-11911
URL: https://issues.apache.org/jira/browse/IGNITE-11911
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Aleksey Plekhanov
A lot of classes in Ignite uses {{GridToStringBuilder}} to implement their
{{toString()}} method. {{GridToStringBuilder}} uses thread local buffer to
generate string representation. This buffer extended on demand but never
shrank. On the final step {{GridToStringBuilder}} uses java {{StringBuilder}}
class to produce output string and uses own buffer size as {{StringBuilder}}
initial capacity. This leads to unnecessary memory allocation since we only
need to allocate memory for meaningful data, but not for all buffer.
Reproducer:
{code:java}
public void testSB() {
GridToStringBuilder.toString(C1.class, new C1(1_000_000));
GridToStringBuilder.toString(C1.class, new C1(100));
}
public class C1 {
private String f;
C1(int len) {
f = new String(new char[len]);
}
}
{code}
Here on the second line about 1 million chars StringBuilder will be allocated,
but only about 100 chars needed.
Problem code (SBLimitedLength.java:293):
{code:java}
StringBuilder res = new StringBuilder(impl().capacity() + tailLen + 100);
{code}
Here {{length()}} method can be used instead of {{capacity()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11898) Java Thin: Implement Best Effort Affinity
Aleksey Plekhanov created IGNITE-11898: -- Summary: Java Thin: Implement Best Effort Affinity Key: IGNITE-11898 URL: https://issues.apache.org/jira/browse/IGNITE-11898 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov See linked IEP-23. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11697) Suspended optimistic transaction automatically resumes to last thread after a timeout.
Aleksey Plekhanov created IGNITE-11697:
--
Summary: Suspended optimistic transaction automatically resumes to
last thread after a timeout.
Key: IGNITE-11697
URL: https://issues.apache.org/jira/browse/IGNITE-11697
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Aleksey Plekhanov
This leads to unpredictable results from a user's point of view.
Reproducer:
{code:java}
public class IgniteTxSuspendAndTimeoutTest extends GridCommonAbstractTest {
@Test
public void testSuspendAndTimeout() throws Exception {
Ignite ignite = startGrid(0);
IgniteCache cache = ignite.createCache(new
CacheConfiguration<>().setName("c").setAtomicityMode(TRANSACTIONAL));
Transaction tx1 = ignite.transactions().txStart(OPTIMISTIC,
TransactionIsolation.REPEATABLE_READ, 100, 0);
cache.put(1, 1);
tx1.suspend();
assertNull(cache.get(1)); // Pass here.
doSleep(200);
assertNull(cache.get(1)); // Fail here. But we don't expect any
explicitly running transaction at this point.
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11685) Java thin client: Handle multiple async requests in parallel
Aleksey Plekhanov created IGNITE-11685:
--
Summary: Java thin client: Handle multiple async requests in
parallel
Key: IGNITE-11685
URL: https://issues.apache.org/jira/browse/IGNITE-11685
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Aleksey Plekhanov
In the current implementation {{ReliableChannel}} uses an exclusive lock to
send a request and waits for response synchronously. In this implementation,
there are no benefits of using multiple threads. To improve throughput and
latency we can implement async request/response processing on the client side,
since the server side is already async.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11671) Thin client: Client may hang when connected to a starting server
Aleksey Plekhanov created IGNITE-11671:
--
Summary: Thin client: Client may hang when connected to a starting
server
Key: IGNITE-11671
URL: https://issues.apache.org/jira/browse/IGNITE-11671
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Aleksey Plekhanov
If the server start process has not completed yet, but NIO listeners already
started, the client may never get a response for the handshake request.
Exception on the server-side:
{noformat}
[client-connector-#6416%f3b837aa-d726-46b0-a58b-8cc6267c9f96%][ClientListenerProcessor]
Runtime error caught during grid runnable execution: GridWorker
[name=message-received-notify,
igniteInstanceName=f3b837aa-d726-46b0-a58b-8cc6267c9f96, finished=false,
heartbeatTs=1554209548706, hashCode=519781823, interrupted=false,
runner=client-connector-#6416%f3b837aa-d726-46b0-a58b-8cc6267c9f96%]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.nextConnectionId(ClientListenerNioListener.java:334)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.prepareContext(ClientListenerNioListener.java:313)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onHandshake(ClientListenerNioListener.java:251)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:132)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70){noformat}
This happens because NIO listeners start before {{GridDiscoveryManager}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11670) Java thin client: Queries are inconsistent in case of failover
Aleksey Plekhanov created IGNITE-11670:
--
Summary: Java thin client: Queries are inconsistent in case of
failover
Key: IGNITE-11670
URL: https://issues.apache.org/jira/browse/IGNITE-11670
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Aleksey Plekhanov
When a thin client does failover and switches to a new server, open cursors
become inconsistent and silently returns the wrong result.
Reproducer:
{code:java}
public void testQueryFailover() throws Exception {
try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
IgniteClient client = Ignition.startClient(new
ClientConfiguration()
.setAddresses(cluster.clientAddresses().iterator().next()))
) {
ObjectName mbeanName =
U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
ClientListenerProcessor.class.getSimpleName());
ClientProcessorMXBean mxBean =
MBeanServerInvocationHandler.newProxyInstance(
ManagementFactory.getPlatformMBeanServer(), mbeanName,
ClientProcessorMXBean.class, true);
ClientCache cache = client.createCache("cache");
cache.put(0, 0);
cache.put(1, 1);
Query> qry = new ScanQuery().setPageSize(1);
try (QueryCursor> cur =
cache.query(qry)) {
int cnt = 0;
for (Iterator> it =
cur.iterator(); it.hasNext(); it.next()) {
cnt++;
if (cnt == 1)
mxBean.dropAllConnections();
}
assertEquals(2, cnt);
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11649) Java thin client: ReliableChannel is not so reliable
Aleksey Plekhanov created IGNITE-11649:
--
Summary: Java thin client: ReliableChannel is not so reliable
Key: IGNITE-11649
URL: https://issues.apache.org/jira/browse/IGNITE-11649
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
When only one server address is used ReliableChannel don't recover after
failure.
Reproducer:
{code:java}
public void testSingleNodeFailover() throws Exception {
try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
IgniteClient client = Ignition.startClient(new ClientConfiguration()
.setAddresses(cluster.clientAddresses().iterator().next()))
) {
ObjectName mbeanName =
U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
"ClientListenerProcessor");
ClientProcessorMXBean mxBean =
MBeanServerInvocationHandler.newProxyInstance(
ManagementFactory.getPlatformMBeanServer(), mbeanName,
ClientProcessorMXBean.class,true);
ClientCache cache = client.createCache("cache");
// Before fail.
cache.put(0, 0);
// Fail.
mxBean.dropAllConnections();
try {
cache.put(0, 0);
}
catch (Exception expected) {
// No-op.
}
// Recover after fail.
cache.put(0, 0);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11437) Start grid in remote JVM in test framework fails if TDE is enabled
Aleksey Plekhanov created IGNITE-11437:
--
Summary: Start grid in remote JVM in test framework fails if TDE
is enabled
Key: IGNITE-11437
URL: https://issues.apache.org/jira/browse/IGNITE-11437
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
When we start grid in remote JVM with enabled TDE, it fails with exception:
{noformat}
java.lang.NullPointerException
at java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:284)
at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
at java.lang.ThreadLocal.get(ThreadLocal.java:170)
at
org.apache.ignite.spi.encryption.keystore.KeystoreEncryptionSpi.encrypt(KeystoreEncryptionSpi.java:211){noformat}
Test framework uses {{XStream}} to pass Ignite configuration to remote JVM.
{{XStream}} cannot serialize lamda expression and replace lambda with {{null}}.
So, after deserialization {{ThreadLocal}} object has {{supplier == null}}.
Reproducer:
{code:java}
public class TdeTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new
DataRegionConfiguration().setPersistenceEnabled(true)));
KeystoreEncryptionSpi encSpi = new KeystoreEncryptionSpi();
encSpi.setKeyStorePath(AbstractEncryptionTest.KEYSTORE_PATH);
encSpi.setKeyStorePassword(AbstractEncryptionTest.KEYSTORE_PASSWORD.toCharArray());
cfg.setEncryptionSpi(encSpi);
cfg.setCacheConfiguration(new
CacheConfiguration().setName("cache").setEncryptionEnabled(true));
return cfg;
}
/** {@inheritDoc} */
@Override protected boolean isMultiJvm() {
return true;
}
@Test
public void testTdeMultiJvm() throws Exception {
startGrids(2);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11336) Implement WAL page snapshot records compression
Aleksey Plekhanov created IGNITE-11336: -- Summary: Implement WAL page snapshot records compression Key: IGNITE-11336 URL: https://issues.apache.org/jira/browse/IGNITE-11336 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We already have page compression implementation, so we can extend this approach to compress WAL page snapshot records (leaving other record types uncompressed) at relatively low cost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10708) SQL implement system view for partition states
Aleksey Plekhanov created IGNITE-10708: -- Summary: SQL implement system view for partition states Key: IGNITE-10708 URL: https://issues.apache.org/jira/browse/IGNITE-10708 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.8 Implement SQL system view to partition states in the cluster for each cache group and each node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10680) Add the ability to use started kernel context in standalone WAL iterator
Aleksey Plekhanov created IGNITE-10680:
--
Summary: Add the ability to use started kernel context in
standalone WAL iterator
Key: IGNITE-10680
URL: https://issues.apache.org/jira/browse/IGNITE-10680
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
In the current implementation it's only possible to use fake kernel context in
standalone WAL iterator. If we need to use binary meta from the running Ignite
node we must specify binary meta directory in parameters of standalone WAL
iterator factory. But there is a possible race with binary meta files
read/write since binary meta received with {{MetadataUpdateProposedMessage}}
can be written to the file and concurrently read from the same file at the same
time. This can lead to assertions like the following:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:305)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:121)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10103)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:117)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.start(CacheObjectBinaryProcessorImpl.java:251)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.binaryProcessor(StandaloneGridKernalContext.java:180)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.StandaloneGridKernalContext.(StandaloneGridKernalContext.java:155)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.prepareSharedCtx(IgniteWalIteratorFactory.java:359)
at
org.apache.ignite.internal.processors.cache.persistence.wal.reader.IgniteWalIteratorFactory.iterator(IgniteWalIteratorFactory.java:177)
{noformat}
To solve this we can use in standalone WAL iterator existing kernel context of
the started node instead of creating new fake one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10642) Cache metrics distribution mechanism should be changed from broadcast to request-response communication pattern
Aleksey Plekhanov created IGNITE-10642:
--
Summary: Cache metrics distribution mechanism should be changed
from broadcast to request-response communication pattern
Key: IGNITE-10642
URL: https://issues.apache.org/jira/browse/IGNITE-10642
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7
Reporter: Aleksey Plekhanov
In the current implementation, all cache metrics are collected on each node for
all caches and sent across the whole cluster with discovery message
({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
(MetricsUpdateFrequency, 2 seconds by default) even if no one requested them.
This mechanism should be changed in the following ways:
* Local cache metrics should be available (if configured) on each node
* If a node needs to collect data from the cluster, it sends explicit
request over communication SPI (request should contain a limited set of caches
and/or metrics)
* For performance reasons collected cluster-wide values must be cached.
Previously
collected metrics should be returned without re-requesting them again if they
are not too old
(configurable)
* The mechanism should be easily adaptable for other types of statistics, which
probably needs to be shared between nodes in the future (IO statistics, SQL
statistics, SQL execution history, etc)
* Message format should be carefully designed to minimize message size (cluster
can contain thousands of caches and hundreds of nodes)
* There must be an opportunity to configure metrics in runtime
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10172) Enabling cache statistics on a large cluster with a large number of caches can affect performance
Aleksey Plekhanov created IGNITE-10172:
--
Summary: Enabling cache statistics on a large cluster with a large
number of caches can affect performance
Key: IGNITE-10172
URL: https://issues.apache.org/jira/browse/IGNITE-10172
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
In current implementation cache metrics are collected on each node and sent
across whole cluster with discovery message
({{TcpDiscoveryMetricsUpdateMessage}}) with configured frequency
({{MetricsUpdateFrequency}}, 2 seconds by default).
If there are a lot of caches and a lot of nodes in the cluster, metrics update
message (which contain metrics for each cache on each node) can reach a
critical size.
Also frequently collecting all cache metrics have a negative performance impact.
The only way now to disable cache metrics collecting and sending with discovery
metrics update message is to disable statistics for each cache. But this also
makes impossible to request some of cache metrics locally (for the current node
only). Requesting a limited set of cache metrics on the current node doesn't
have such performance impact as the frequent collecting of all cache metrics,
but sometimes it's enough for diagnostic purposes.
To solve this introduce new system property which will disable cache metrics
sending with {{TcpDiscoveryMetricsUpdateMessage}} even if {{statisticsEnabled}}
flag is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10171) Running queries descriptor (GridRunningQueryInfo) contains generated SQL text instead of original SQL text
Aleksey Plekhanov created IGNITE-10171:
--
Summary: Running queries descriptor (GridRunningQueryInfo)
contains generated SQL text instead of original SQL text
Key: IGNITE-10171
URL: https://issues.apache.org/jira/browse/IGNITE-10171
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.8
Running queries descriptors ({{GridRunningQueryInfo}}) for SQL queries received
by {{GridQueryProcessor#runningQueries()}} method contains SQL text generated
from parsed query structure. For diagnostic purposes it's better to store
original SQL query text instaed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9780) SQL system view for cache groups
Aleksey Plekhanov created IGNITE-9780:
-
Summary: SQL system view for cache groups
Key: IGNITE-9780
URL: https://issues.apache.org/jira/browse/IGNITE-9780
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Implement SQL system view to show list of cache groups.
View must contain information: cache group id, cache group name, caches count,
and attributes related to cache group from CacheConfiguration (at least
attributes checked in {{ClusterCachesInfo#validateCacheGroupConfiguration()}}
method)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9639) Flaky failure of SqlSystemViewsSelfTest
Aleksey Plekhanov created IGNITE-9639:
-
Summary: Flaky failure of SqlSystemViewsSelfTest
Key: IGNITE-9639
URL: https://issues.apache.org/jira/browse/IGNITE-9639
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
SqlSystemViewsSelfTest fails sometimes with the following error:
{noformat}
[2018-09-18 08:23:56,275][ERROR][main][root] Test failed.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to register MBean for component:
org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1326)
at
org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3161)
at
org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.execSql(SqlSystemViewsSelfTest.java:76)
at
org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.testNodesViews(SqlSystemViewsSelfTest.java:386)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2177)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:143)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2092)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
MBean for component:
org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl@58f7fe1b
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:4312)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1727)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1982)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:439)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:633)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:379)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2393)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2529)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
... 1 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache:clsLdr=5c080ef3,igniteInstanceName=query.SqlSystemViewsSelfTest1,group=default,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4614)
at
org.apache.ignite.internal.util.IgniteUtils.registerMBean(IgniteUtils.java:4585)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.registerMbean(GridCacheProcessor.java:4308)
... 10 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9500) SQL system view for list of caches
Aleksey Plekhanov created IGNITE-9500: - Summary: SQL system view for list of caches Key: IGNITE-9500 URL: https://issues.apache.org/jira/browse/IGNITE-9500 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement SQL system view to show list of caches with basic cache information (name, cache group, atomicity mode, cache mode, data region) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9366) SQL system view for node metrics
Aleksey Plekhanov created IGNITE-9366:
-
Summary: SQL system view for node metrics
Key: IGNITE-9366
URL: https://issues.apache.org/jira/browse/IGNITE-9366
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Implement SQL system view to show metrics of each node (information is
available locally on each node). View must contain NODE_ID column and the same
set of metrics as provided by {{ClusterMetrics}} interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9318) SQL system view for list of baseline topology nodes
Aleksey Plekhanov created IGNITE-9318: - Summary: SQL system view for list of baseline topology nodes Key: IGNITE-9318 URL: https://issues.apache.org/jira/browse/IGNITE-9318 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement SQL system view to show list of baseline topology nodes. View must contain information about node consistentId and online/offline status. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
Aleksey Plekhanov created IGNITE-9303:
-
Summary: PageSnapshot can contain wrong pageId tag when not dirty
page is recycling
Key: IGNITE-9303
URL: https://issues.apache.org/jira/browse/IGNITE-9303
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
/** {@inheritDoc} */
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
/**
*
*/
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8517) Implement CacheGroupMetricsMXBean.getTotalAllocatedPages() calculation for PageMemoryNoStore
Aleksey Plekhanov created IGNITE-8517: - Summary: Implement CacheGroupMetricsMXBean.getTotalAllocatedPages() calculation for PageMemoryNoStore Key: IGNITE-8517 URL: https://issues.apache.org/jira/browse/IGNITE-8517 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Allocated pages count are calculated for cache groups only when PDS is enabled (allocated page trackers for each cache group are used in FilePageStore class). But when PageMemoryNoStore is used this metric for cache groups is not calculated (data region page tracker is used when page is allocated) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8515) Value of CacheGroupMetricsMXBean.getTotalAllocatedPages() is always 0
Aleksey Plekhanov created IGNITE-8515:
-
Summary: Value of CacheGroupMetricsMXBean.getTotalAllocatedPages()
is always 0
Key: IGNITE-8515
URL: https://issues.apache.org/jira/browse/IGNITE-8515
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Fix For: 2.6
{{DataRegionMetricsImpl#getOrAllocateGroupPageAllocationTracker}} don't save
created trackers and always returns new tracker.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8443) Flaky failure of IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode
Aleksey Plekhanov created IGNITE-8443:
-
Summary: Flaky failure of
IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode
Key: IGNITE-8443
URL: https://issues.apache.org/jira/browse/IGNITE-8443
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test fails on TC sometimes (failure rate: 30%) with the following error:
{noformat}
junit.framework.AssertionFailedError: Failed to wait for update.
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.multinode(IgniteCacheClientNodeChangingTopologyTest.java:1855)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode(IgniteCacheClientNodeChangingTopologyTest.java:1673)
{noformat}
Each time some seconds prior to failure there is error in log:
{noformat}
[ERROR][sys-stripe-10-#90529%distributed.IgniteCacheClientNodeChangingTopologyTest0%][GridDhtColocatedCache]
Failed to unmarshal at least one of the keys for lock request
message: GridNearLockRequest [topVer=AffinityTopologyVersion [topVer=10,
minorTopVer=0], miniId=1, dhtVers=[...],
subjId=5ad87047-5d80-4530-bb48-f7c26846, taskNameHash=0, createTtl=-1,
accessTtl=-1, flags=6, filter=null, super=GridDistributedLockRequest
[nodeId=5ad87047-5d80-4530-bb48-f7c26846, nearXidVer=GridCacheVersion
[topVer=136730132, order=1525250131532, nodeOrder=7], threadId=100107,
futId=3e2912f2361-94bff164-8062-4fb4-8d85-c2e89e579148, timeout=0, isInTx=true,
isInvalidate=false, isRead=false, isolation=REPEATABLE_READ, retVals=[...],
txSize=0, flags=0, keysCnt=94, super=GridDistributedBaseMessage
[ver=GridCacheVersion [topVer=136730132, order=1525250131532, nodeOrder=7],
committedVers=null, rolledbackVers=null, cnt=0, super=GridCacheIdMessage
[cacheId=1544803905
class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
[part=54, msg=Adding entry to partition that is concurrently evicted
[grp=default, part=54, shouldBeMoving=, belongs=true,
topVer=AffinityTopologyVersion [topVer=10, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=10, minorTopVer=1]]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:923)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:798)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:955)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryExx(GridDhtCacheAdapter.java:545)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:987)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest0(GridDhtTransactionalCacheAdapter.java:667)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$800(GridDhtTransactionalCacheAdapter.java:94)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12$1.run(GridDhtTransactionalCacheAdapter.java:704)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8400) Flaky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup (Grid is in invalid state)
Aleksey Plekhanov created IGNITE-8400:
-
Summary: Flaky failure of
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup
(Grid is in invalid state)
Key: IGNITE-8400
URL: https://issues.apache.org/jira/browse/IGNITE-8400
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test fails sometimes on TeamCity with exception:
{noformat}
java.lang.IllegalStateException: Grid is in invalid state to perform this
operation. It either not started yet or has already being or have stopped
[igniteInstanceName=cache.IgniteTopologyValidatorGridSplitCacheTest6,
state=STOPPED]
{noformat}
Before this exception node is dropped out of topology by coordinator:
{noformat}
[tcp-disco-msg-worker-#7831%cache.IgniteTopologyValidatorGridSplitCacheTest6%][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
Node is out of topology (probably, due to short-time network problems).
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8374) Test IgnitePdsCorruptedStoreTest.testCacheMetaCorruption hangs during node start
Aleksey Plekhanov created IGNITE-8374: - Summary: Test IgnitePdsCorruptedStoreTest.testCacheMetaCorruption hangs during node start Key: IGNITE-8374 URL: https://issues.apache.org/jira/browse/IGNITE-8374 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.5 Call to cluster().active() in IgniteKernal.ackStart() synchronously waits for state transition to complete, but due to error during activation process this transition will never end. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8166) stopGrid() hangs in some cases when node is invalidated and PDS is enabled
Aleksey Plekhanov created IGNITE-8166:
-
Summary: stopGrid() hangs in some cases when node is invalidated
and PDS is enabled
Key: IGNITE-8166
URL: https://issues.apache.org/jira/browse/IGNITE-8166
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Aleksey Plekhanov
Node invalidation via FailureProcessor can hang {{exchange-worker}} and
{{stopGrid()}} when PDS is enabled.
Reproducer (reproducer is racy, sometimes finished without hang):
{code:java}
public class StopNodeHangsTest extends GridCommonAbstractTest {
/** Offheap size for memory policy. */
private static final int SIZE = 10 * 1024 * 1024;
/** Page size. */
static final int PAGE_SIZE = 2048;
/** Number of entries. */
static final int ENTRIES = 2_000;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
DataStorageConfiguration dsCfg = new DataStorageConfiguration();
DataRegionConfiguration dfltPlcCfg = new DataRegionConfiguration();
dfltPlcCfg.setName("dfltPlc");
dfltPlcCfg.setInitialSize(SIZE);
dfltPlcCfg.setMaxSize(SIZE);
dfltPlcCfg.setPersistenceEnabled(true);
dsCfg.setDefaultDataRegionConfiguration(dfltPlcCfg);
dsCfg.setPageSize(PAGE_SIZE);
cfg.setDataStorageConfiguration(dsCfg);
cfg.setFailureHandler(new FailureHandler() {
@Override public boolean onFailure(Ignite ignite, FailureContext
failureCtx) {
return true;
}
});
return cfg;
}
public void testStopNodeHangs() throws Exception {
cleanPersistenceDir();
IgniteEx ignite0 = startGrid(0);
IgniteEx ignite1 = startGrid(1);
ignite1.cluster().active(true);
awaitPartitionMapExchange();
IgniteCache cache = ignite1.getOrCreateCache("TEST");
Map entries = new HashMap<>();
for (int i = 0; i < ENTRIES; i++)
entries.put(i, new byte[PAGE_SIZE * 2 / 3]);
cache.putAll(entries);
ignite1.context().failure().process(new
FailureContext(FailureType.CRITICAL_ERROR, null));
stopGrid(0);
stopGrid(1);
}
}
{code}
{{stopGrid(1)}} waiting until exchange finished, {{exchange-worker}} waits on
method {{GridCacheDatabaseSharedManager#checkpointReadLock}} for
{{CheckpointProgressSnapshot#cpBeginFut}}, but this future is never done
because {{db-checkpoint-thread}} got exception at
{{GridCacheDatabaseSharedManager.Checkpointer#markCheckpointBegin}} thrown by
{{FileWriteAheadLogManager#checkNode}} and leave method {{markCheckpointBegin}}
before future is done ({{curr.cpBeginFut.onDone();}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8033) Flaky failure TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC
Aleksey Plekhanov created IGNITE-8033:
-
Summary: Flaky failure
TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC
Key: IGNITE-8033
URL: https://issues.apache.org/jira/browse/IGNITE-8033
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock flakily fail on
TC. Sometimes with timeout, sometimes with the following error:
{noformat}
[2018-03-21 12:06:23,469][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at
org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.doTestDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:186)
at
org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7976) [Test failed] IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes fails on TC
Aleksey Plekhanov created IGNITE-7976:
-
Summary: [Test failed]
IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes
fails on TC
Key: IGNITE-7976
URL: https://issues.apache.org/jira/browse/IGNITE-7976
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test
{{IgnitePersistentStoreCacheGroupsTest.testClusterRestartCachesWithH2Indexes}}
always fail on TeamCity due to changes by IGNITE-7869. With following error:
{noformat}
javax.cache.CacheException: Failed to parse query. Table "PERSON" not found;
SQL statement:
SELECT p._KEY, p._VAL FROM Person p WHERE p.lname=? ORDER BY p.fname [42102-195]
...
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7969) Fluky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup
Aleksey Plekhanov created IGNITE-7969:
-
Summary: Fluky failure of
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup
Key: IGNITE-7969
URL: https://issues.apache.org/jira/browse/IGNITE-7969
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Test fails on TeamCity with exception:
{noformat}
java.lang.AssertionError: Successful tryPut after failure [gridIdx=2, sucessful
puts = 50]
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:491)
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidator0(IgniteTopologyValidatorGridSplitCacheTest.java:281)
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup(IgniteTopologyValidatorGridSplitCacheTest.java:234)
...
Caused by: class org.apache.ignite.IgniteException: Failed to put entry
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:498)
... 11 more
Suppressed: class org.apache.ignite.IgniteException: Failed to put
entry [node=cache.IgniteTopologyValidatorGridSplitCacheTest0]
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:463)
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:488)
... 11 more
Suppressed: junit.framework.AssertionFailedError: expected:<1>
but was:<2>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at
junit.framework.TestCase.assertEquals(TestCase.java:409)
at
org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:448)
... 12 more
...
{noformat}
Sometimes reproduces locally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7818) Incorrect assertion in PDS page eviction method
Aleksey Plekhanov created IGNITE-7818:
-
Summary: Incorrect assertion in PDS page eviction method
Key: IGNITE-7818
URL: https://issues.apache.org/jira/browse/IGNITE-7818
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
There is assertion in the method
org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
{code:java}
assert relRmvAddr != INVALID_REL_PTR;{code}
Which seems potentially dangerous. In some rare cases, when count of
interations more then 40% of allocated pages and all processed pages are
aquired, the {{relRmvAddr}} variable will be uninitialized and
{{AssertionException}} will be thrown. But it's a correct case and page to
evict can be found later in the method {{tryToFindSequentially.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7701) SQL system view for node attributes
Aleksey Plekhanov created IGNITE-7701: - Summary: SQL system view for node attributes Key: IGNITE-7701 URL: https://issues.apache.org/jira/browse/IGNITE-7701 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.5 Implement SQL system view to show attributes for each node in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7700) SQL system view for list of nodes
Aleksey Plekhanov created IGNITE-7700: - Summary: SQL system view for list of nodes Key: IGNITE-7700 URL: https://issues.apache.org/jira/browse/IGNITE-7700 Project: Ignite Issue Type: Task Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Fix For: 2.5 Implement SQL system view to show list of nodes in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7527) SQL system view for current node transactions
Aleksey Plekhanov created IGNITE-7527: - Summary: SQL system view for current node transactions Key: IGNITE-7527 URL: https://issues.apache.org/jira/browse/IGNITE-7527 Project: Ignite Issue Type: Improvement Components: sql Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Implement SQL system view to show active transactions on local node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
