[jira] [Updated] (IGNITE-12067) SQL: metrics of executions of user queries
[ https://issues.apache.org/jira/browse/IGNITE-12067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin updated IGNITE-12067: Labels: IEP-35 (was: ) > SQL: metrics of executions of user queries > -- > > Key: IGNITE-12067 > URL: https://issues.apache.org/jira/browse/IGNITE-12067 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Ivan Pavlukhin >Priority: Major > Labels: IEP-35 > > Lets add: > - Counter of success executed user queries. > - Counter of failed executed user queries. > - Counter of failed by OOM executed user queries. > - Counter of cancelled user queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12479) All binary types are registered twice
[
https://issues.apache.org/jira/browse/IGNITE-12479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12479:
Release Note: Register binary types metadata only once per type. (was:
Only register binary types metadata once per type.)
> All binary types are registered twice
> -
>
> Key: IGNITE-12479
> URL: https://issues.apache.org/jira/browse/IGNITE-12479
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a POJO is put into a cache, its binary type is registered twice during
> marshalling.
> Example:
> {code:java}
> public class MetadataRegistrationExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> Person p = new Person("Denis");
> ignite.getOrCreateCache("cache").put(1, p);
> }
> static class Person {
> private String name;
> public Person(String name) {
> this.name = name;
> }
> }
> }
> {code}
>
> Here is the generated debug log from the package
> {noformat}
> [23:31:14,020][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, changedSchemas=[],
> holder=null, fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928,
> ver=0]]]
> [23:31:14,023][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateProposedListener [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
> acceptedVer=0, schemasCnt=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Versions are stamped on coordinator [typeId=-1210012928, changedSchemas=[],
> pendingVer=1, acceptedVer=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Updated metadata on originating node: [typeId=-1210012928, pendingVer=1,
> acceptedVer=0]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
> [id=599e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
> acceptedVer=1, duplicated=false]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Completing future MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=1]] for [typeId=-1210012928, pendingVer=1,
> acceptedVer=1]
> [23:31:14,026][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=4ms,
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=1]],
> tx=null]
> [23:31:14,027][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person,
> changedSchemas=[1975878747], holder=[typeId=-1210012928, pendingVer=1,
> acceptedVer=1], fut=MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=0]]]
> [23:31:14,027][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateProposedListener [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
> acceptedVer=0, schemasCnt=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Versions are stamped on coordinator [typeId=-1210012928,
> changedSchemas=[1975878747], pendingVer=2, acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Updated metadata on originating node: [typeId=-1210012928, pendingVer=2,
> acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
> [id=d99e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
> acceptedVer=2, duplicated=false]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Completing future MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=2]] for [typeId=-1210012928, pendingVer=2,
> acceptedVer=2]
> [23:31:14,029][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=1ms,
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=2]],
> tx=null]
> {noformat}
> You can see, that a type is registered twice. First it's registered without
> any fields, and only the second time the type is registered
[jira] [Commented] (IGNITE-9216) Uncomment 28 test classes in IgniteCacheTestSuite (Cache 1)
[
https://issues.apache.org/jira/browse/IGNITE-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027758#comment-17027758
]
Ignite TC Bot commented on IGNITE-9216:
---
{panel:title=Branch: [pull/7346/head] Base: [master] : Possible Blockers
(81)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=4977602]]
* ZookeeperDiscoverySpiTestSuite3:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite3:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithTxTwoNodesOneBackup -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite3:
GridEventConsumeSelfTest.testNodeJoinWithProjection - Test has low fail rate in
base branch 1,1% and is not flaky
* ZookeeperDiscoverySpiTestSuite3: GridEventConsumeSelfTest.testEventsByFilter
- Test has low fail rate in base branch 1,1% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
31|https://ci.ignite.apache.org/viewLog.html?buildId=4977548]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteCacheEntryListenerWithZkDiscoAtomicTest.testSynchronousEventsListenerNodeFailed
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
IgniteCacheEntryListenerWithZkDiscoAtomicTest.testEvents - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectExchangeInProgress - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheIdleVerifyDumpExcludedCacheGrp -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testBaselineAutoAdjustmentSettings - Test
has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheIdleVerifyTwoConflictTypes - Test
has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testUnusedWalPrint - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheIdleVerifyDumpForCorruptedDataOnSystemCache
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheIdleVerifyMultipleCacheFilterOptions
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheConfigMultiLineOutputFormatTwoNodeManyCaches
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerClusterByClassTest.testCacheConfigSingleLineOutputFormatSingleNodeSignleCache
- Test has low fail rate in base branch 0,0% and is not flaky
... and 20 tests blockers
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
28|https://ci.ignite.apache.org/viewLog.html?buildId=4977547]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientReconnectTest.testReconnectServersRestart_4 - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryConcurrentStartAndStartStopTest.testStartStop4 - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryConcurrentStartAndStartStopTest.testStartStop3 - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testStartNoZk - Test has low fail rate
in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testStartNoServer_WaitForServers1 - Test
has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testServersLeft_FailOnTimeout - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testConnectionCheck - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientReconnectTest.testReconnectServersRestart_3 - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testClientReconnects - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCustomEventsTest.testCustomEventsSimple1_SingleNode - Test
has low fail rate in base branch 0,0% and is not flaky
*
[jira] [Assigned] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-10960:
---
Assignee: (was: Ivan Pavlukhin)
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-10960:
---
Assignee: Ivan Pavlukhin
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Assignee: Ivan Pavlukhin
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh reassigned IGNITE-10960:
-
Assignee: (was: Roman Shtykh)
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12615) Add warning that cluster deactivation purges data from memory
Denis A. Magda created IGNITE-12615: --- Summary: Add warning that cluster deactivation purges data from memory Key: IGNITE-12615 URL: https://issues.apache.org/jira/browse/IGNITE-12615 Project: Ignite Issue Type: Task Affects Versions: 2.7.6 Reporter: Denis A. Magda Assignee: Artem Budnikov Fix For: 2.8 Baseline topology [1] and control script's [2] documentation needs to have a warning callout saying that a cluster deactivation procedure will purge data from memory requiring users to reload data back after the activation. For caches that persist data in the native persistence, this will happen automatically, for all the other cases the user has to reload data manually. [1] https://apacheignite.readme.io/docs/baseline-topology [2] https://apacheignite-tools.readme.io/docs/control-script#section-activation-deactivation-and-topology-management -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12607) PartitionsExchangeAwareTest is flaky
[ https://issues.apache.org/jira/browse/IGNITE-12607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027682#comment-17027682 ] Ivan Rakov commented on IGNITE-12607: - The test doesn't seem to be flaky anymore: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7339%2Fhead=builds [~slava.koptilin] Can you please take a look? > PartitionsExchangeAwareTest is flaky > > > Key: IGNITE-12607 > URL: https://issues.apache.org/jira/browse/IGNITE-12607 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Proof: > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6/4972239 > Seems like cache update sometimes is not possible even before topologies are > locked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12580) NPE in GridMetricManager
[
https://issues.apache.org/jira/browse/IGNITE-12580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12580:
Labels: IEP-35 (was: )
> NPE in GridMetricManager
>
>
> Key: IGNITE-12580
> URL: https://issues.apache.org/jira/browse/IGNITE-12580
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> NPE is thrown during cache recovery:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7534)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:234)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:152)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:816)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:675)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1375)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:615)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1017)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:958)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:946)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:895)
> at
> org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.doTestSimple(LocalWalModeChangeDuringRebalancingSelfTest.java:263)
> at
> org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.testWalDisabledDuringRebalancing(LocalWalModeChangeDuringRebalancingSelfTest.java:234)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2124)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:396)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.stop(GridCacheAdapter.java:669)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1024)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:998)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCaches(GridCacheProcessor.java:754)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onBaselineChange(GridCacheProcessor.java:5460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:982)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:849)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3236)
> at
>
[jira] [Updated] (IGNITE-12571) Statistics of query cache statements
[ https://issues.apache.org/jira/browse/IGNITE-12571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-12571: Labels: IEP-35 (was: ) > Statistics of query cache statements > > > Key: IGNITE-12571 > URL: https://issues.apache.org/jira/browse/IGNITE-12571 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Minor > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to collect hit/miss statistics for the query cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12574) Fix failing IoStatisticsBasicIndexSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-12574: Labels: IEP-35 (was: ) > Fix failing IoStatisticsBasicIndexSelfTest > -- > > Key: IGNITE-12574 > URL: https://issues.apache.org/jira/browse/IGNITE-12574 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to move > org.apache.ignite.internal.processors.cache.index.IoStatisticsBasicIndexSelfTest > into a test suite with enabled persistence. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11977) Data streamer pool MXBean is registered as ThreadPoolMXBean instead of StripedExecutorMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-11977: Labels: IEP-35 (was: ) > Data streamer pool MXBean is registered as ThreadPoolMXBean instead of > StripedExecutorMXBean > > > Key: IGNITE-11977 > URL: https://issues.apache.org/jira/browse/IGNITE-11977 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stanislav Lukyanov >Assignee: Ruslan Kamashev >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Data streamer pool is registered with a ThreadPoolMXBean while it is actually > a StripedExecutor and can use a StripedExecutorMXBean. > Need to change the registration in the IgniteKernal code. It should be > registered the same way as the striped executor pool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12468) ClassCastException on thinClient in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027658#comment-17027658
]
Aleksey Plekhanov commented on IGNITE-12468:
[~Pavlukhin],
1. Yes, it duplicates partially, but it used for different purposes with
different parameters set, I'm not sure we can get rid of duplication. I will
try to add some thick client operations to the test.
2. I've also noticed {{KEEP_BINARIES}} flag, even trying to use it, but in some
cases, it still needs recursive collections, arrays and maps unwrapping (when
we unmarshalling OBJ and OPTM_MARSH types). Also when KEEP_BINARIES flag is set
{{deserialize()}} method is used new handles map is created and this can be an
issue.
> ClassCastException on thinClient in Apache Ignite
> -
>
> Key: IGNITE-12468
> URL: https://issues.apache.org/jira/browse/IGNITE-12468
> Project: Ignite
> Issue Type: Bug
> Components: binary, clients, thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Assignee: Aleksey Plekhanov
>Priority: Major
>
>
> {code:java}
> ClientConfiguration cfg = new
> ClientConfiguration().setAddresses("127.0.0.1:10800");
> try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
> System.out.println(">>> Thin client put-get example started.");
> final String CACHE_NAME = "put-get-example";
> ClientCache cache =
> igniteClient.getOrCreateCache(CACHE_NAME);
> Person p = new Person();
> //put
> HashMap hm = new HashMap();
> hm.put(1, p);
> cache.put(1, hm);
> //get
> HashMap map = (HashMap)cache.get(1);
> Person p2 = map.get(1);
> System.out.format(">>> Loaded [%s] from the cache.\n",p2);
> }
> catch (ClientException e) {
> System.err.println(e.getMessage());
> e.printStackTrace();
> }
> catch (Exception e) {
> System.err.format("Unexpected failure: %s\n", e);
> e.printStackTrace();
> }
> {code}
>
> I use the thin client of apache-ignite.
> I Create a hashmap and put the Person
> class(org.apache.ignite.examples.model.Person) object into it.
> And when I take it out of the hashmap, I get the following exceptions:
>
> {code:java}
> > java.lang.ClassCastException:
> > org.apache.enite.internal.binary.BinaryObjectImpl cannot be cast to
> > org.apache.engite.examples.model.Person.
> {code}
> An exception is given in the code below.
>
> {code:java}
> Person p2 = map.get(1);
> {code}
>
> However, there is no exception if I modify the code as follows:
>
> {code:java}
> BinaryObject bo = (BinaryObject) map.get(1);
> Person p2 = bo.deserialize();
> {code}
> I don't think that's necessary. Is there another solution?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9216) Uncomment 28 test classes in IgniteCacheTestSuite (Cache 1)
[
https://issues.apache.org/jira/browse/IGNITE-9216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-9216:
Ignite Flags: (was: Docs Required)
> Uncomment 28 test classes in IgniteCacheTestSuite (Cache 1)
> ---
>
> Key: IGNITE-9216
> URL: https://issues.apache.org/jira/browse/IGNITE-9216
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> //GridTestUtils.addTestIfNeeded(suite,
> CacheEntryProcessorCopySelfTest.class, ignoredTests);
> // suite.addTestSuite(GridCacheP2PUndeploySelfTest.class);
> //suite.addTestSuite(GridCacheTtlManagerEvictionSelfTest.class);
> //suite.addTestSuite(GridIoManagerSelfTest.class);
> //suite.addTestSuite(CacheAtomicSingleMessageCountSelfTest.class);
>
> //suite.addTestSuite(GridCacheAtomicUsersAffinityMapperSelfTest.class);
> //suite.addTestSuite(GridCacheClearLocallySelfTest.class);
> //suite.addTestSuite(GridCacheConcurrentGetCacheOnClientTest.class);
>
> //suite.addTestSuite(GridCacheFullTextQueryMultithreadedSelfTest.class);
> //suite.addTestSuite(GridCacheKeyCheckNearEnabledSelfTest.class);
> //suite.addTestSuite(GridCacheKeyCheckSelfTest.class);
> //suite.addTestSuite(GridCacheLeakTest.class);
> //suite.addTestSuite(GridCacheMultiUpdateLockSelfTest.class);
> //suite.addTestSuite(GridCacheMvccFlagsTest.class);
>
> //suite.addTestSuite(GridCacheReplicatedUsersAffinityMapperSelfTest.class);
> //suite.addTestSuite(GridCacheReturnValueTransferSelfTest.class);
> //suite.addTestSuite(GridCacheSlowTxWarnTest.class);
> //suite.addTestSuite(GridCacheTtlManagerLoadTest.class);
> //suite.addTestSuite(GridCacheTxUsersAffinityMapperSelfTest.class);
> //suite.addTestSuite(IgniteInternalCacheRemoveTest.class);
> //suite.addTestSuite(IgniteCacheBinaryEntryProcessorSelfTest.class);
> //suite.addTestSuite(IgniteCacheObjectPutSelfTest.class);
> //suite.addTestSuite(IgniteCacheSerializationSelfTest.class);
> //suite.addTestSuite(IgniteCacheStartStopLoadTest.class);
> //suite.addTestSuite(IgniteCachingProviderSelfTest.class);
> //suite.addTestSuite(IgniteOnePhaseCommitNearSelfTest.class);
> //suite.addTestSuite(IgniteStaticCacheStartSelfTest.class);
> //suite.addTestSuite(InterceptorWithKeepBinaryCacheFullApiTest.class);
>//suite.addTest(new TestSuite(IgfsSizeSelfTest.class));
>//suite.addTestSuite(IgfsPathSelfTest.class);
>//suite.addTestSuite(IgfsBackupFailoverSelfTest.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027645#comment-17027645
]
Ignite TC Bot commented on IGNITE-12605:
{panel:title=Branch: [pull/7341/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4976995buildTypeId=IgniteTests24Java8_RunAll]
> Historical (WAL) rebalance can start on a cleared partition if some baseline
> node leaves the cluster and then joins back.
> -
>
> Key: IGNITE-12605
> URL: https://issues.apache.org/jira/browse/IGNITE-12605
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
> Environment:
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: WalRebalanceOnCleanPartitionReproducerUnstable.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> _(scenario: cluster with 3 nodes, node3 starts historical rebalancing and
> then node2 leaves cluster)_
> On partition map exchange initiated by baseline node leaving, the historical
> supplier is not provided in the full message (assignPartitionStates() isn't
> called on coordinator when a node leaves). Since we don't have a historical
> supplier "historical" partition scheduled for clearing, then when a node
> joins back assignPartitionStates() is called and we have a supplier for
> historical rebalance, but partition may be cleared already.
> After such rebalance we have inconsistent partitions on a "historically
> rebalanced" node (with consistent partition counters and state).
> "Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but
> this issue can be "unstable" reproduced without it (see attachment)).
>
> Reproducer shows the following error.
> {noformat}
> java.lang.AssertionError:
> |--|---|
> | | entries count |
> | part |---|
> | | node1 | node2 | node3 |
> |--|---|
> | 0 | 6250 | 6250 | 3125 |
> | 1 | 6250 | 6250 | 3125 |
> | 2 | 6250 | 6250 | 3125 |
> ...
> | 31 | 6250 | 6250 | 3125 |
> |--|---|---|---|
> {noformat}
> (partitions on node3 have been cleared before start historical rebalance).
>
> Reproducer:
> {code:java}
> public class WalRebalanceOnCleanPartitionReproducer extends
> GridCommonAbstractTest {
> /** Block predicate. */
> private P2 blockPred;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String gridName)
> throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(gridName);
> cfg.setConsistentId(gridName);
> cfg.setRebalanceThreadPoolSize(1);
> CacheConfiguration ccfg1 = new CacheConfiguration(DEFAULT_CACHE_NAME)
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setBackups(2)
> .setAffinity(new RendezvousAffinityFunction(false, 32))
> .setRebalanceMode(CacheRebalanceMode.ASYNC);
> cfg.setCacheConfiguration(ccfg1);
> TestRecordingCommunicationSpi commSpi = new
> TestRecordingCommunicationSpi();
> commSpi.blockMessages(blockPred);
> cfg.setCommunicationSpi(commSpi);
> DataStorageConfiguration dsCfg = new DataStorageConfiguration()
> .setConcurrencyLevel(Runtime.getRuntime().availableProcessors() *
> 4)
> .setCheckpointFrequency(5_000)
> .setWalMode(WALMode.LOG_ONLY)
> .setPageSize(1024)
> .setWalSegmentSize(8 * 1024 * 1024)
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setName("dfltDataRegion")
> .setPersistenceEnabled(true)
> .setMaxSize(512 * 1024 * 1024)
> );
> cfg.setDataStorageConfiguration(dsCfg);
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected void beforeTestsStarted() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.beforeTestsStarted();
> }
> /**
> *
> */
> @Test
> @WithSystemProperty(key = IGNITE_PDS_WAL_REBALANCE_THRESHOLD, value = "0")
> public void testHistoricalRebalanceRestart() throws Exception {
> IgniteEx crd = startGrid(0);
> crd.cluster().state(ClusterState.ACTIVE);
> crd.cluster().baselineAutoAdjustEnabled(false);
> Ignite node1 = startGrid(1);
> Ignite node2 = startGrid(2);
> List blt = new
>
[jira] [Commented] (IGNITE-12607) PartitionsExchangeAwareTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-12607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027579#comment-17027579
]
Ignite TC Bot commented on IGNITE-12607:
{panel:title=Branch: [pull/7339/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4974468buildTypeId=IgniteTests24Java8_RunAll]
> PartitionsExchangeAwareTest is flaky
>
>
> Key: IGNITE-12607
> URL: https://issues.apache.org/jira/browse/IGNITE-12607
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Proof:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6/4972239
> Seems like cache update sometimes is not possible even before topologies are
> locked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12468) ClassCastException on thinClient in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027571#comment-17027571
]
Ivan Pavlukhin commented on IGNITE-12468:
-
[~alex_pl], I took a look and I would like to spend some more time to complete
the review. There are a couple of things which bothers me:
# It seems we duplicate
{{org.apache.ignite.internal.processors.cache.CacheObjectUtils#unwrapBinary}}
code for a client. If we cannot avoid duplication, we can at least cover thin
and thick client with the same set of tests to guarantee consistent behavior.
And it would be really useful to have such tests.
# A little bit side note. Also I noticed that
{{org.apache.ignite.internal.binary.GridBinaryMarshaller#KEEP_BINARIES}} flag
holder can be used to enable deserialization to Java objects. But it is not
used at all and seems it is not sufficient to do full deserialization.
> ClassCastException on thinClient in Apache Ignite
> -
>
> Key: IGNITE-12468
> URL: https://issues.apache.org/jira/browse/IGNITE-12468
> Project: Ignite
> Issue Type: Bug
> Components: binary, clients, thin client
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Assignee: Aleksey Plekhanov
>Priority: Major
>
>
> {code:java}
> ClientConfiguration cfg = new
> ClientConfiguration().setAddresses("127.0.0.1:10800");
> try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
> System.out.println(">>> Thin client put-get example started.");
> final String CACHE_NAME = "put-get-example";
> ClientCache cache =
> igniteClient.getOrCreateCache(CACHE_NAME);
> Person p = new Person();
> //put
> HashMap hm = new HashMap();
> hm.put(1, p);
> cache.put(1, hm);
> //get
> HashMap map = (HashMap)cache.get(1);
> Person p2 = map.get(1);
> System.out.format(">>> Loaded [%s] from the cache.\n",p2);
> }
> catch (ClientException e) {
> System.err.println(e.getMessage());
> e.printStackTrace();
> }
> catch (Exception e) {
> System.err.format("Unexpected failure: %s\n", e);
> e.printStackTrace();
> }
> {code}
>
> I use the thin client of apache-ignite.
> I Create a hashmap and put the Person
> class(org.apache.ignite.examples.model.Person) object into it.
> And when I take it out of the hashmap, I get the following exceptions:
>
> {code:java}
> > java.lang.ClassCastException:
> > org.apache.enite.internal.binary.BinaryObjectImpl cannot be cast to
> > org.apache.engite.examples.model.Person.
> {code}
> An exception is given in the code below.
>
> {code:java}
> Person p2 = map.get(1);
> {code}
>
> However, there is no exception if I modify the code as follows:
>
> {code:java}
> BinaryObject bo = (BinaryObject) map.get(1);
> Person p2 = bo.deserialize();
> {code}
> I don't think that's necessary. Is there another solution?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12612) Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496
[ https://issues.apache.org/jira/browse/IGNITE-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027568#comment-17027568 ] Alexey Goncharuk commented on IGNITE-12612: --- [~Denis Chudov] thanks for the quick fix, merged to master. > Failing test > IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after > IGNITE-12496 > --- > > Key: IGNITE-12612 > URL: https://issues.apache.org/jira/browse/IGNITE-12612 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > In IGNITE-12496 a new method of destroying index was added > (H2TreeIndex#asyncDestroy), and there are no changes from IGNITE-11987 in it, > the changes are only present in old H2TreeIndex#destroy. We should apply > changes to new method. > Also it would be better to refactor both methods to prevent such errors in > future. > Failing test history > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1153260173537232526=%3Cdefault%3E=testDetails] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12612) Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496
[ https://issues.apache.org/jira/browse/IGNITE-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12612: -- Fix Version/s: 2.9 > Failing test > IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after > IGNITE-12496 > --- > > Key: IGNITE-12612 > URL: https://issues.apache.org/jira/browse/IGNITE-12612 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > In IGNITE-12496 a new method of destroying index was added > (H2TreeIndex#asyncDestroy), and there are no changes from IGNITE-11987 in it, > the changes are only present in old H2TreeIndex#destroy. We should apply > changes to new method. > Also it would be better to refactor both methods to prevent such errors in > future. > Failing test history > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1153260173537232526=%3Cdefault%3E=testDetails] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027496#comment-17027496
]
Aleksey Plekhanov edited comment on IGNITE-12003 at 1/31/20 2:11 PM:
-
[~Pavlukhin], got it, thank you. Looks like it fixed by IGNITE-12479 (at least
the new reproducer passes on 2.8 with IGNITE-12479 cherry-picked, and doesn't
passes without it)
was (Author: alex_pl):
[~Pavlukhin], got it, thank you. Looks like it fixed by IGNITE-12479 (at least
this reproducer passes with IGNITE-12479)
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12612) Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496
[ https://issues.apache.org/jira/browse/IGNITE-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027522#comment-17027522 ] Denis Chudov commented on IGNITE-12612: --- [~agoncharuk] could you please review this fix? > Failing test > IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after > IGNITE-12496 > --- > > Key: IGNITE-12612 > URL: https://issues.apache.org/jira/browse/IGNITE-12612 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In IGNITE-12496 a new method of destroying index was added > (H2TreeIndex#asyncDestroy), and there are no changes from IGNITE-11987 in it, > the changes are only present in old H2TreeIndex#destroy. We should apply > changes to new method. > Also it would be better to refactor both methods to prevent such errors in > future. > Failing test history > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1153260173537232526=%3Cdefault%3E=testDetails] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12612) Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496
[
https://issues.apache.org/jira/browse/IGNITE-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027521#comment-17027521
]
Ignite TC Bot commented on IGNITE-12612:
{panel:title=Branch: [pull/7343/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4976264buildTypeId=IgniteTests24Java8_RunAll]
> Failing test
> IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after
> IGNITE-12496
> ---
>
> Key: IGNITE-12612
> URL: https://issues.apache.org/jira/browse/IGNITE-12612
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-12496 a new method of destroying index was added
> (H2TreeIndex#asyncDestroy), and there are no changes from IGNITE-11987 in it,
> the changes are only present in old H2TreeIndex#destroy. We should apply
> changes to new method.
> Also it would be better to refactor both methods to prevent such errors in
> future.
> Failing test history
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1153260173537232526=%3Cdefault%3E=testDetails]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12504) Auto-adjust breaks existing code, should be disabled by default
[
https://issues.apache.org/jira/browse/IGNITE-12504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027512#comment-17027512
]
Maxim Muzafarov commented on IGNITE-12504:
--
[~akalashnikov][~ilyak]
So, let's close the issue, right?
> Auto-adjust breaks existing code, should be disabled by default
> ---
>
> Key: IGNITE-12504
> URL: https://issues.apache.org/jira/browse/IGNITE-12504
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.8
>
>
> We have automatic baseline adjustment now. However, it is 'on' by default,
> which means it breaks existing code. I see new exceptions when starting an
> existing project after bumping Ignite dependency version:
> {code}
> Caused by:
> org.apache.ignite.internal.processors.cluster.BaselineAdjustForbiddenException:
> Baseline auto-adjust is enabled, please turn-off it before try to adjust
> baseline manually
> {code}
> (Please see reproducer from attached UL discussion)
> I think we should disable auto-adjust by default, let people enable it when
> they see it fit.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027503#comment-17027503
]
Ivan Pavlukhin edited comment on IGNITE-12003 at 1/31/20 1:54 PM:
--
Requested stack trace (2.7.6).
{code}
class org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
object with compact footer: -1880776568
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2012)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:286)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:185)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:832)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:795)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:640)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:504)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:503)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:189)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:126)
at
org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:82)
at
org.apache.ignite.internal.binary.ThinClientCompactFooterDeserializationProblem.clientGet(ThinClientCompactFooterDeserializationProblem.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
{code}
was (Author: pavlukhin):
Requested stack trace (2.8 branch).
{code}
class org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
object with compact footer (Ignite work directory might have been cleared after
restart. Make sure that IGNITE_HOME does not point to a temp folder or any
other folder that is destroyed/cleared on restarts) [typeId=-1880776568,
IGNITE_HOME='/home/ipavlukhin/work/vcs/ignite']
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2015)
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:826)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:789)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:633)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:528)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:555)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:560)
at
[jira] [Comment Edited] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027503#comment-17027503
]
Ivan Pavlukhin edited comment on IGNITE-12003 at 1/31/20 1:46 PM:
--
Requested stack trace (2.8 branch).
{code}
class org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
object with compact footer (Ignite work directory might have been cleared after
restart. Make sure that IGNITE_HOME does not point to a temp folder or any
other folder that is destroyed/cleared on restarts) [typeId=-1880776568,
IGNITE_HOME='/home/ipavlukhin/work/vcs/ignite']
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2015)
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:826)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:789)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:633)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:528)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:555)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:560)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:247)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:160)
at
org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:222)
at
org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:509)
at
org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
at
org.apache.ignite.internal.binary.ThinClientCompactFooterDeserializationProblem.clientGet(ThinClientCompactFooterDeserializationProblem.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
{code}
was (Author: pavlukhin):
Requested stack trace.
{code}
class org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
object with compact footer (Ignite work directory might have been cleared after
restart. Make sure that IGNITE_HOME does not point to a temp folder or any
other folder that is destroyed/cleared on restarts) [typeId=-1880776568,
IGNITE_HOME='/home/ipavlukhin/work/vcs/ignite']
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2015)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:287)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:186)
at
[jira] [Commented] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027503#comment-17027503
]
Ivan Pavlukhin commented on IGNITE-12003:
-
Requested stack trace.
{code}
class org.apache.ignite.binary.BinaryObjectException: Cannot find metadata for
object with compact footer (Ignite work directory might have been cleared after
restart. Make sure that IGNITE_HOME does not point to a temp folder or any
other folder that is destroyed/cleared on restarts) [typeId=-1880776568,
IGNITE_HOME='/home/ipavlukhin/work/vcs/ignite']
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2015)
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:826)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:789)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserialize(BinaryObjectImpl.java:633)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:528)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:555)
at
org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:560)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:247)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
at
org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:160)
at
org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:222)
at
org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:509)
at
org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111)
at
org.apache.ignite.internal.binary.ThinClientCompactFooterDeserializationProblem.clientGet(ThinClientCompactFooterDeserializationProblem.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
{code}
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for
[jira] [Commented] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027496#comment-17027496
]
Aleksey Plekhanov commented on IGNITE-12003:
[~Pavlukhin], got it, thank you. Looks like it fixed by IGNITE-12479 (at least
this reproducer passes with IGNITE-12479)
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
[ https://issues.apache.org/jira/browse/IGNITE-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12614: - Assignee: Vladimir Steshin > Disallow silent deactivation of cluster to prevent in-mem data loss. > > > Key: IGNITE-12614 > URL: https://issues.apache.org/jira/browse/IGNITE-12614 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > Currently, anyone is able to deactivate cluster with command line utility > (control.sh). Probably with JMX too. That would lead to data loss when the > persistence is off. In-memory data is erased during deactivation. Such > behavior can be considered as unexpected to user. > Suggestions: > 1)Disallow silent deactivation of cluster keeping caches. Show a warning > like “Your cluster has in-memory cache configured. During deactivation all > data from these caches will be cleared!” > 2)Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
[ https://issues.apache.org/jira/browse/IGNITE-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12614: -- Description: Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivation of cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. was: Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivate cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. > Disallow silent deactivation of cluster to prevent in-mem data loss. > > > Key: IGNITE-12614 > URL: https://issues.apache.org/jira/browse/IGNITE-12614 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > > Currently, anyone is able to deactivate cluster with command line utility > (control.sh). Probably with JMX too. That would lead to data loss when the > persistence is off. In-memory data is erased during deactivation. Such > behavior can be considered as unexpected to user. > Suggestions: > 1)Disallow silent deactivation of cluster keeping caches. Show a warning > like “Your cluster has in-memory cache configured. During deactivation all > data from these caches will be cleared!” > 2)Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
Vladimir Steshin created IGNITE-12614: - Summary: Disallow silent deactivation of cluster to prevent in-mem data loss. Key: IGNITE-12614 URL: https://issues.apache.org/jira/browse/IGNITE-12614 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivate cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027459#comment-17027459
]
Ivan Pavlukhin commented on IGNITE-12003:
-
[~alex_pl], to my shame the reproducer contained an extra line of code breaking
reproducibility. There was a cache _put_ before _get_ in a method intended to
fail with an exception, consequently a metadata was registered locally and test
passed. I updated the reproducer.
But there are also interesting news. I checked it against a bunch of versions
(2.7, 2.7.5, 2.7.6, 2.8 branch, master). Surprising news for me is that the
issues seems to be fixed in master! But unfortunately not in all prior versions
(including upcoming 2.8). Will spend some time to find where it was fixed.
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12568:
Description:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
If we try to register message with direct type for which already exists
registered message then node start process must be terminated (directly, with
out any failure handlers).
If we get message with unknown direct type (there is now registered message for
this direct type) then failure handler be invoked but this is topic for
discussion and should be considered separately.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].get();
}
{code}
was:
Currently existing {{MessageFactory}} implementations (at least
{{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
problem: it is possible to register several messages with the same direct type.
It could lead to the cluster freeze due to unexpected unmarshaling error.
*Solution:*
Each message should be registered and during registration we can check that
there is no registered message with the same type. Otherwise we should not
start node and print error message.
*Proposed implementation:*
Instead of {{switch-case}} block new array of size 2^16 should be created.
Each array cell should contain message default constructor reference or lambda
which is responsible for message instance creation. So during message
unmarshaling system just lookup ctor-ref or lambda from array by index and
invoke it in order to create proper message instance.
All message factory extensions and custom message should be registered at the
same array before communication SPI will be started.
If we try to register message with direct type for which already exists
registered message then node start process must be terminated (directly, with
out any failure handlers).
If we get message with unknown direct type (there is now registered message for
this direct type) then failure handler be invoked.
It could affect perfromance so we should run microbenchmark for this change.
Additional benefit of this change is improving code readability. At present we
have the following code:
{code:java}
@Override public Message create(short type) {
Message msg = null;
switch (type) {
case -61:
msg = new IgniteDiagnosticMessage();
break;
case -53:
msg = new SchemaOperationStatusMessage();
break;
// etc.
}
{code}
After refactoring it will looks like:
{code:java}
private Supplier[] msgCtrs;
public GridIoMessageFactory(MessageFactory[] ext) {
this.ext = ext;
registerMessage(-61, IgniteDiagnosticMessage::new)
registerMessage(-53, SchemaOperationStatusMessage::new)
}
@Override public Message create(short type) {
return msgCtros[type].get();
}
{code}
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL:
[jira] [Updated] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-12605:
--
Description:
_(scenario: cluster with 3 nodes, node3 starts historical rebalancing and then
node2 leaves cluster)_
On partition map exchange initiated by baseline node leaving, the historical
supplier is not provided in the full message (assignPartitionStates() isn't
called on coordinator when a node leaves). Since we don't have a historical
supplier "historical" partition scheduled for clearing, then when a node joins
back assignPartitionStates() is called and we have a supplier for historical
rebalance, but partition may be cleared already.
After such rebalance we have inconsistent partitions on a "historically
rebalanced" node (with consistent partition counters and state).
"Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but this
issue can be "unstable" reproduced without it (see attachment)).
Reproducer shows the following error.
{noformat}
java.lang.AssertionError:
|--|---|
| | entries count |
| part |---|
| | node1 | node2 | node3 |
|--|---|
| 0 | 6250 | 6250 | 3125 |
| 1 | 6250 | 6250 | 3125 |
| 2 | 6250 | 6250 | 3125 |
...
| 31 | 6250 | 6250 | 3125 |
|--|---|---|---|
{noformat}
(partitions on node3 have been cleared before start historical rebalance).
Reproducer:
{code:java}
public class WalRebalanceOnCleanPartitionReproducer extends
GridCommonAbstractTest {
/** Block predicate. */
private P2 blockPred;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
cfg.setConsistentId(gridName);
cfg.setRebalanceThreadPoolSize(1);
CacheConfiguration ccfg1 = new CacheConfiguration(DEFAULT_CACHE_NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setBackups(2)
.setAffinity(new RendezvousAffinityFunction(false, 32))
.setRebalanceMode(CacheRebalanceMode.ASYNC);
cfg.setCacheConfiguration(ccfg1);
TestRecordingCommunicationSpi commSpi = new
TestRecordingCommunicationSpi();
commSpi.blockMessages(blockPred);
cfg.setCommunicationSpi(commSpi);
DataStorageConfiguration dsCfg = new DataStorageConfiguration()
.setConcurrencyLevel(Runtime.getRuntime().availableProcessors() * 4)
.setCheckpointFrequency(5_000)
.setWalMode(WALMode.LOG_ONLY)
.setPageSize(1024)
.setWalSegmentSize(8 * 1024 * 1024)
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setName("dfltDataRegion")
.setPersistenceEnabled(true)
.setMaxSize(512 * 1024 * 1024)
);
cfg.setDataStorageConfiguration(dsCfg);
return cfg;
}
/** {@inheritDoc} */
@Override protected void beforeTestsStarted() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.beforeTestsStarted();
}
/**
*
*/
@Test
@WithSystemProperty(key = IGNITE_PDS_WAL_REBALANCE_THRESHOLD, value = "0")
public void testHistoricalRebalanceRestart() throws Exception {
IgniteEx crd = startGrid(0);
crd.cluster().state(ClusterState.ACTIVE);
crd.cluster().baselineAutoAdjustEnabled(false);
Ignite node1 = startGrid(1);
Ignite node2 = startGrid(2);
List blt = new
ArrayList<>(crd.context().discovery().aliveServerNodes());
crd.cluster().setBaselineTopology(blt);
IgniteCache cache0 = crd.cache(DEFAULT_CACHE_NAME);
System.out.println(">>> load 100k entries");
loadData(cache0, 0, 100_000);
forceCheckpoint();
System.out.println(">>> stop node 2");
node2.close();
awaitPartitionMapExchange();
System.out.println(">>> load 100k entries again");
loadData(cache0, 100_000, 100_000);
blockPred = (node, msg) -> {
if (msg instanceof GridDhtPartitionDemandMessage) {
GridDhtPartitionDemandMessage msg0 =
(GridDhtPartitionDemandMessage)msg;
return msg0.groupId() == CU.cacheId(DEFAULT_CACHE_NAME);
}
return false;
};
startGrid(2);
TestRecordingCommunicationSpi spi2 =
TestRecordingCommunicationSpi.spi(grid(2));
spi2.waitForBlocked();
spi2.stopBlock();
// Forces rebalanceing to restart without assign partition states.
System.out.println(">>> stop grid 1");
node1.close();
spi2.blockMessages(blockPred);
[jira] [Updated] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-12605:
--
Description:
_(scenario: cluster with 3 nodes, node3 starts historical rebalancing and then
node2 leaves cluster)_
On partition map exchange initiated by baseline node leaving, the historical
supplier is not provided in the full message (assignPartitionStates() isn't
called on coordinator when a node leaves). Since we don't have a historical
supplier "historical" partition scheduled for clearing, then when a node joins
back assignPartitionStates() is called and we have a supplier for historical
rebalance, but partition may be cleared already.
After such rebalance we have inconsistent partitions on a "historically
rebalanced" node (with consistent partition counters and state).
"Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but this
issue can be "unstable" reproduced without it (see attachment)).
Reproducer shows the following error.
{noformat}
java.lang.AssertionError:
|--|---|
| | entries count |
| part |---|
| | node1 | node2 | node3 |
|--|---|
| 0 | 6250 | 6250 | 3125 |
| 1 | 6250 | 6250 | 3125 |
| 2 | 6250 | 6250 | 3125 |
...
| 31 | 6250 | 6250 | 3125 |
|--|---|---|---|
{noformat}
(partitions on node3 have been cleared before start historical rebalance).
Reproducer:
{code:java}
public class WalRebalanceOnCleanPartitionReproducer extends
GridCommonAbstractTest {
/** Block predicate. */
private P2 blockPred;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
cfg.setConsistentId(gridName);
cfg.setRebalanceThreadPoolSize(1);
CacheConfiguration ccfg1 = new CacheConfiguration(DEFAULT_CACHE_NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setBackups(2)
.setAffinity(new RendezvousAffinityFunction(false, 32))
.setRebalanceMode(CacheRebalanceMode.ASYNC);
cfg.setCacheConfiguration(ccfg1);
TestRecordingCommunicationSpi commSpi = new
TestRecordingCommunicationSpi();
commSpi.blockMessages(blockPred);
cfg.setCommunicationSpi(commSpi);
DataStorageConfiguration dsCfg = new DataStorageConfiguration()
.setConcurrencyLevel(Runtime.getRuntime().availableProcessors() * 4)
.setCheckpointFrequency(5_000)
.setWalMode(WALMode.LOG_ONLY)
.setPageSize(1024)
.setWalSegmentSize(8 * 1024 * 1024)
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setName("dfltDataRegion")
.setPersistenceEnabled(true)
.setMaxSize(512 * 1024 * 1024)
);
cfg.setDataStorageConfiguration(dsCfg);
return cfg;
}
/** {@inheritDoc} */
@Override protected void beforeTestsStarted() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.beforeTestsStarted();
}
/**
*
*/
@Test
@WithSystemProperty(key = IGNITE_PDS_WAL_REBALANCE_THRESHOLD, value = "0")
public void testHistoricalRebalanceRestart() throws Exception {
IgniteEx crd = startGrid(0);
crd.cluster().state(ClusterState.ACTIVE);
crd.cluster().baselineAutoAdjustEnabled(false);
Ignite node1 = startGrid(1);
Ignite node2 = startGrid(2);
List blt = new
ArrayList<>(crd.context().discovery().aliveServerNodes());
crd.cluster().setBaselineTopology(blt);
IgniteCache cache0 = crd.cache(DEFAULT_CACHE_NAME);
System.out.println(">>> load 100k entries");
loadData(cache0, 0, 100_000);
forceCheckpoint();
System.out.println(">>> stop node 2");
node2.close();
awaitPartitionMapExchange();
System.out.println(">>> load 100k entries again");
loadData(cache0, 100_000, 100_000);
blockPred = (node, msg) -> {
if (msg instanceof GridDhtPartitionDemandMessage) {
GridDhtPartitionDemandMessage msg0 =
(GridDhtPartitionDemandMessage)msg;
return msg0.groupId() == CU.cacheId(DEFAULT_CACHE_NAME);
}
return false;
};
startGrid(2);
TestRecordingCommunicationSpi spi2 =
TestRecordingCommunicationSpi.spi(grid(2));
spi2.waitForBlocked();
spi2.stopBlock();
// Forces rebalanceing to restart without assign partition states.
System.out.println(">>> stop grid 1");
node1.close();
spi2.blockMessages(blockPred);
[jira] [Updated] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-12605:
--
Description:
_(scenario: cluster with 3 nodes, node3 starts historical rebalancing and then
node2 leaves cluster)_
On partition map exchange initiated by baseline node leaving, the historical
supplier is not provided in the full message (assignPartitionStates() isn't
called on coordinator when a node leaves). Since we don't have a historical
supplier "historical" partition scheduled for clearing, then when a node joins
back assignPartitionStates() is called and we have a supplier for historical
rebalance, but partition may be cleared already.
After such rebalance we have inconsistent partitions on a "historically
rebalanced" node (with consistent partition counters and state).
"Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but this
issue can be "unstable" reproduced without it (see attachment)).
Reproducer shows the following error.
(partitions on node3 have been cleared before start historical rebalance).
{noformat}
java.lang.AssertionError:
|--|---|
| | entries count |
| part |---|
| | node1 | node2 | node3 |
|--|---|
| 0 | 6250 | 6250 | 3125 |
| 1 | 6250 | 6250 | 3125 |
| 2 | 6250 | 6250 | 3125 |
...
| 31 | 6250 | 6250 | 3125 |
|--|---|---|---|
{noformat}
Reproducer:
{code:java}
public class WalRebalanceOnCleanPartitionReproducer extends
GridCommonAbstractTest {
/** Block predicate. */
private P2 blockPred;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
cfg.setConsistentId(gridName);
cfg.setRebalanceThreadPoolSize(1);
CacheConfiguration ccfg1 = new CacheConfiguration(DEFAULT_CACHE_NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setBackups(2)
.setAffinity(new RendezvousAffinityFunction(false, 32))
.setRebalanceMode(CacheRebalanceMode.ASYNC);
cfg.setCacheConfiguration(ccfg1);
TestRecordingCommunicationSpi commSpi = new
TestRecordingCommunicationSpi();
commSpi.blockMessages(blockPred);
cfg.setCommunicationSpi(commSpi);
DataStorageConfiguration dsCfg = new DataStorageConfiguration()
.setConcurrencyLevel(Runtime.getRuntime().availableProcessors() * 4)
.setCheckpointFrequency(5_000)
.setWalMode(WALMode.LOG_ONLY)
.setPageSize(1024)
.setWalSegmentSize(8 * 1024 * 1024)
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setName("dfltDataRegion")
.setPersistenceEnabled(true)
.setMaxSize(512 * 1024 * 1024)
);
cfg.setDataStorageConfiguration(dsCfg);
return cfg;
}
/** {@inheritDoc} */
@Override protected void beforeTestsStarted() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.beforeTestsStarted();
}
/**
*
*/
@Test
@WithSystemProperty(key = IGNITE_PDS_WAL_REBALANCE_THRESHOLD, value = "0")
public void testHistoricalRebalanceRestart() throws Exception {
IgniteEx crd = startGrid(0);
crd.cluster().state(ClusterState.ACTIVE);
crd.cluster().baselineAutoAdjustEnabled(false);
Ignite node1 = startGrid(1);
Ignite node2 = startGrid(2);
List blt = new
ArrayList<>(crd.context().discovery().aliveServerNodes());
crd.cluster().setBaselineTopology(blt);
IgniteCache cache0 = crd.cache(DEFAULT_CACHE_NAME);
System.out.println(">>> load 100k entries");
loadData(cache0, 0, 100_000);
forceCheckpoint();
System.out.println(">>> stop node 2");
node2.close();
awaitPartitionMapExchange();
System.out.println(">>> load 100k entries again");
loadData(cache0, 100_000, 100_000);
blockPred = (node, msg) -> {
if (msg instanceof GridDhtPartitionDemandMessage) {
GridDhtPartitionDemandMessage msg0 =
(GridDhtPartitionDemandMessage)msg;
return msg0.groupId() == CU.cacheId(DEFAULT_CACHE_NAME);
}
return false;
};
startGrid(2);
TestRecordingCommunicationSpi spi2 =
TestRecordingCommunicationSpi.spi(grid(2));
spi2.waitForBlocked();
spi2.stopBlock();
// Forces rebalanceing to restart without assign partition states.
System.out.println(">>> stop grid 1");
node1.close();
spi2.blockMessages(blockPred);
[jira] [Updated] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-12605:
--
Description:
_(scenario: cluster with 3 nodes, node3 starts historical rebalancing and then
node2 leaves cluster)_
On partition map exchange initiated by baseline node leaving, the historical
supplier is not provided in the full message (assignPartitionStates() isn't
called on coordinator when a node leaves). Since we don't have a historical
supplier "historical" partition scheduled for clearing, then when a node joins
back assignPartitionStates() is called and we have a supplier for historical
rebalance, but partition may be cleared already.
After such rebalance we have inconsistent partitions on a "historically
rebalanced" node (with consistent partition counters and state).
"Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but this
issue can be "unstable" reproduced without it (see attachment)).
Reproducer shows the following error.
{noformat}
java.lang.AssertionError:
|--|---|
| | entries count |
| part |---|
| | node1 | node2 | node3 |
|--|---|
| 0 | 6250 | 6250 | 3125 |
| 1 | 6250 | 6250 | 3125 |
| 2 | 6250 | 6250 | 3125 |
...
| 31 | 6250 | 6250 | 3125 |
|--|---|---|---|
{noformat}
(partitions on node3 have been cleared before start historical rebalance).
Reproducer:
{code:java}
public class WalRebalanceOnCleanPartitionReproducer extends
GridCommonAbstractTest {
/** Block predicate. */
private P2 blockPred;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
cfg.setConsistentId(gridName);
cfg.setRebalanceThreadPoolSize(1);
CacheConfiguration ccfg1 = new CacheConfiguration(DEFAULT_CACHE_NAME)
.setCacheMode(CacheMode.PARTITIONED)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setBackups(2)
.setAffinity(new RendezvousAffinityFunction(false, 32))
.setRebalanceMode(CacheRebalanceMode.ASYNC);
cfg.setCacheConfiguration(ccfg1);
TestRecordingCommunicationSpi commSpi = new
TestRecordingCommunicationSpi();
commSpi.blockMessages(blockPred);
cfg.setCommunicationSpi(commSpi);
DataStorageConfiguration dsCfg = new DataStorageConfiguration()
.setConcurrencyLevel(Runtime.getRuntime().availableProcessors() * 4)
.setCheckpointFrequency(5_000)
.setWalMode(WALMode.LOG_ONLY)
.setPageSize(1024)
.setWalSegmentSize(8 * 1024 * 1024)
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setName("dfltDataRegion")
.setPersistenceEnabled(true)
.setMaxSize(512 * 1024 * 1024)
);
cfg.setDataStorageConfiguration(dsCfg);
return cfg;
}
/** {@inheritDoc} */
@Override protected void beforeTestsStarted() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.beforeTestsStarted();
}
/**
*
*/
@Test
@WithSystemProperty(key = IGNITE_PDS_WAL_REBALANCE_THRESHOLD, value = "0")
public void testHistoricalRebalanceRestart() throws Exception {
IgniteEx crd = startGrid(0);
crd.cluster().state(ClusterState.ACTIVE);
crd.cluster().baselineAutoAdjustEnabled(false);
Ignite node1 = startGrid(1);
Ignite node2 = startGrid(2);
List blt = new
ArrayList<>(crd.context().discovery().aliveServerNodes());
crd.cluster().setBaselineTopology(blt);
IgniteCache cache0 = crd.cache(DEFAULT_CACHE_NAME);
System.out.println(">>> load 100k entries");
loadData(cache0, 0, 100_000);
forceCheckpoint();
System.out.println(">>> stop node 2");
node2.close();
awaitPartitionMapExchange();
System.out.println(">>> load 100k entries again");
loadData(cache0, 100_000, 100_000);
blockPred = (node, msg) -> {
if (msg instanceof GridDhtPartitionDemandMessage) {
GridDhtPartitionDemandMessage msg0 =
(GridDhtPartitionDemandMessage)msg;
return msg0.groupId() == CU.cacheId(DEFAULT_CACHE_NAME);
}
return false;
};
startGrid(2);
TestRecordingCommunicationSpi spi2 =
TestRecordingCommunicationSpi.spi(grid(2));
spi2.waitForBlocked();
spi2.stopBlock();
// Forces rebalanceing to restart without assign partition states.
System.out.println(">>> stop grid 1");
node1.close();
spi2.blockMessages(blockPred);
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Description:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
See attached reproducer [^ThinClientCompactFooterDeserializationProblem].
was:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
See attached reproducer.
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Description:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
was:
Experiment:
1. Start server.
2. Start thin client, configure to use compact footer. Put some Pojo into cache.
3. Start another client (compact footer enabled). Try to read Pojo saved in
previous step (Pojo class is available).
Result -- {{BinaryObjectException("Cannot find metadata for object with compact
footer: " + typeId)}}.
See attached reproducer [^ThinClientCompactFooterDeserializationProblem].
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer [^ThinClientCompactFooterDeserializationProblem.java].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Attachment: ThinClientCompactFooterDeserializationProblem.java
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12003:
Attachment: (was: ThinClientCompactFooterDeserializationProblem.java)
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12605) Historical (WAL) rebalance can start on a cleared partition if some baseline node leaves the cluster and then joins back.
[
https://issues.apache.org/jira/browse/IGNITE-12605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027440#comment-17027440
]
Pavel Pereslegin commented on IGNITE-12605:
---
I don’t think that calling the {{assignPartitionStates()}} method when the node
leaves is the right way, because I’m pretty sure that we may encounter a
similar problem when the only supplier (historical) “blinks”, so I propose an
even more trivial solution - reset the initial update counter value before
scheduling the partition for clearing.
> Historical (WAL) rebalance can start on a cleared partition if some baseline
> node leaves the cluster and then joins back.
> -
>
> Key: IGNITE-12605
> URL: https://issues.apache.org/jira/browse/IGNITE-12605
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
> Environment:
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Attachments: WalRebalanceOnCleanPartitionReproducerUnstable.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> _(scenario: cluster with 3 nodes, node3 starts historical rebalancing and
> then node2 leaves cluster)_
> On partition map exchange initiated by baseline node leaving, the historical
> supplier is not provided in the full message (assignPartitionStates() isn't
> called on coordinator when a node leaves). Since we don't have a historical
> supplier "historical" partition scheduled for clearing, then when a node
> joins back assignPartitionStates() is called and we have a supplier for
> historical rebalance, but partition may be cleared already.
> After such rebalance we have inconsistent partitions on a "historically
> rebalanced" node (with consistent partition counters and state).
> "Inlined" reproducer uses TestRecordingCommunicationSpi to sync nodes (but
> this issue can be "unstable" reproduced without it (see attachment)).
> Reproducer shows the following errors.
> Error 1 (partitions on node3 have been cleared before start historical
> rebalance).
> {noformat}
> java.lang.AssertionError:
> |--|---|
> | | entries count |
> | part |---|
> | | node1 | node2 | node3 |
> |--|---|
> | 0 | 6250 | 6250 | 3125 |
> | 1 | 6250 | 6250 | 3125 |
> | 2 | 6250 | 6250 | 3125 |
> ...
> | 31 | 6250 | 6250 | 3125 |
> |--|---|---|---|
> {noformat}
> Error 2 (should be investigated deeply).
> {noformat}
> java.lang.AssertionError: Reached end of WAL but not all partitions are done
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.advance(GridCacheOffheapManager.java:1419)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.next(GridCacheOffheapManager.java:1295)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:1255)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:1163)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.nextX(IgniteRebalanceIteratorImpl.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:215)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.peek(IgniteRebalanceIteratorImpl.java:155)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:316)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleDemandMessage$1(GridDhtPreloader.java:374)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
> Reproducer:
> {code:java}
> import java.util.ArrayList;
> import java.util.LinkedHashSet;
> import java.util.List;
> import java.util.Set;
> import java.util.concurrent.CountDownLatch;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.IgniteDataStreamer;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.CacheRebalanceMode;
> import
[jira] [Assigned] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12581: - Assignee: (was: Vladimir Steshin) > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: Vladimir Steshin > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12596: - Assignee: (was: Vladimir Steshin) > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12595) Parametrization of GridCacheSetAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12595: - Assignee: (was: Vladimir Steshin) > Parametrization of GridCacheSetAbstractSelfTest > --- > > Key: IGNITE-12595 > URL: https://issues.apache.org/jira/browse/IGNITE-12595 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Trivial > > org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest > might be used with params. Not the best candidate due to usage/extending in > differect sub-packages. But is still able to reduce tests code base. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027438#comment-17027438 ] Vladimir Steshin commented on IGNITE-12581: --- Attached file with list (smalltests.txt) of the small tests which can be reviewed for parameterization refactoring. > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12581: -- Attachment: smalltests.txt > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12568:
Fix Version/s: 2.9
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> If we try to register message with direct type for which already exists
> registered message then node start process must be terminated (directly, with
> out any failure handlers).
> If we get message with unknown direct type (there is now registered message
> for this direct type) then failure handler be invoked.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12568) MessageFactory implementations refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027436#comment-17027436
]
Ignite TC Bot commented on IGNITE-12568:
{panel:title=Branch: [pull/7302/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4972045buildTypeId=IgniteTests24Java8_RunAll]
> MessageFactory implementations refactoring
> --
>
> Key: IGNITE-12568
> URL: https://issues.apache.org/jira/browse/IGNITE-12568
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently existing {{MessageFactory}} implementations (at least
> {{GridIoMessageFactory}} and {{GridH2ValueMessageFactory}}) have serious
> problem: it is possible to register several messages with the same direct
> type. It could lead to the cluster freeze due to unexpected unmarshaling
> error.
> *Solution:*
> Each message should be registered and during registration we can check that
> there is no registered message with the same type. Otherwise we should not
> start node and print error message.
> *Proposed implementation:*
> Instead of {{switch-case}} block new array of size 2^16 should be created.
> Each array cell should contain message default constructor reference or
> lambda which is responsible for message instance creation. So during message
> unmarshaling system just lookup ctor-ref or lambda from array by index and
> invoke it in order to create proper message instance.
> All message factory extensions and custom message should be registered at the
> same array before communication SPI will be started.
> If we try to register message with direct type for which already exists
> registered message then node start process must be terminated (directly, with
> out any failure handlers).
> If we get message with unknown direct type (there is now registered message
> for this direct type) then failure handler be invoked.
> It could affect perfromance so we should run microbenchmark for this change.
> Additional benefit of this change is improving code readability. At present
> we have the following code:
> {code:java}
> @Override public Message create(short type) {
> Message msg = null;
> switch (type) {
> case -61:
> msg = new IgniteDiagnosticMessage();
> break;
> case -53:
> msg = new SchemaOperationStatusMessage();
> break;
> // etc.
> }
> {code}
> After refactoring it will looks like:
> {code:java}
> private Supplier[] msgCtrs;
> public GridIoMessageFactory(MessageFactory[] ext) {
> this.ext = ext;
>registerMessage(-61, IgniteDiagnosticMessage::new)
>registerMessage(-53, SchemaOperationStatusMessage::new)
> }
> @Override public Message create(short type) {
> return msgCtros[type].get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11797) Fix consistency issues for atomic and mixed tx-atomic cache groups.
[ https://issues.apache.org/jira/browse/IGNITE-11797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027430#comment-17027430 ] Pavel Pereslegin commented on IGNITE-11797: --- [~ascherbakov], thanks for the clarification. > Fix consistency issues for atomic and mixed tx-atomic cache groups. > --- > > Key: IGNITE-11797 > URL: https://issues.apache.org/jira/browse/IGNITE-11797 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > IGNITE-10078 only solves consistency problems for tx mode. > For atomic caches the rebalance consistency issues still remain and should be > fixed together with improvement of atomic cache protocol consistency. > Also, need to disable dynamic start of atomic cache in group having only tx > caches because it's not working in current state. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027421#comment-17027421 ] Ryabov Dmitrii commented on IGNITE-12049: - [~ascherbakov] Currently, we can use attrs of thin clients only for authentication. > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 2h > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6804:
Comment: was deleted
(was: {panel:title=Branch: [pull/6976/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4973964]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSplitterSelfTest.testReplicatedTablesUsingPartitionedCacheClient -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4973959]]
* dll: CacheTest.TestCacheWithExpiryPolicyOnUpdate - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 TIMEOUT ,
TC_BUILD_FAILURE |https://ci.ignite.apache.org/viewLog.html?buildId=4973960]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4973988buildTypeId=IgniteTests24Java8_RunAll])
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[
https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027412#comment-17027412
]
Ignite TC Bot commented on IGNITE-6804:
---
{panel:title=Branch: [pull/6976/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4973988buildTypeId=IgniteTests24Java8_RunAll]
> Print a warning if HashMap is passed into bulk update operations
>
>
> Key: IGNITE-6804
> URL: https://issues.apache.org/jira/browse/IGNITE-6804
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis A. Magda
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: usability
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Ignite newcomers tend to stumble on deadlocks simply because the keys are
> passed in an unordered HashMap. Propose to do the following:
> * update bulk operations Java docs.
> * print out a warning if not SortedMap (e.g. HashMap,
> Weak/Identity/Concurrent/Linked HashMap etc) is passed into
> a bulk method (instead of SortedMap) and contains more than 1 element.
> However, we should make sure that we only print that warning once and not
> every time the API is called.
> * do not produce warning for explicit optimistic transactions
> More details are here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12049) Add user attributes to thin clients
[ https://issues.apache.org/jira/browse/IGNITE-12049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027403#comment-17027403 ] Alexey Scherbakov commented on IGNITE-12049: [~SomeFire] What's the relation between authAttributes on thin clients and userAttributes on IgniteConfiguration ? Shouldn't they be always "userAttributes" ? > Add user attributes to thin clients > --- > > Key: IGNITE-12049 > URL: https://issues.apache.org/jira/browse/IGNITE-12049 > Project: Ignite > Issue Type: Improvement >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Time Spent: 2h > Remaining Estimate: 0h > > Add user attributes to thin clients (like node attributes for server nodes). > Make sure that custom authenticators can use these attributes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12613) Scala (Visor Console) test failed on Java 8+
Vasiliy Sisko created IGNITE-12613: -- Summary: Scala (Visor Console) test failed on Java 8+ Key: IGNITE-12613 URL: https://issues.apache.org/jira/browse/IGNITE-12613 Project: Ignite Issue Type: Improvement Components: visor Affects Versions: mas Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: mas Failed test on TC agents with Java 9+ [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] Noticed that Scala libraries and scalatest library are different for different java versions. Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12613) Scala (Visor Console) test failed on Java 9+
[ https://issues.apache.org/jira/browse/IGNITE-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko updated IGNITE-12613: --- Summary: Scala (Visor Console) test failed on Java 9+ (was: Scala (Visor Console) test failed on Java 8+) > Scala (Visor Console) test failed on Java 9+ > > > Key: IGNITE-12613 > URL: https://issues.apache.org/jira/browse/IGNITE-12613 > Project: Ignite > Issue Type: Improvement > Components: visor >Affects Versions: mas >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Fix For: mas > > > Failed test on TC agents with Java 9+ > [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ScalaVisorConsole/4975900] > Noticed that Scala libraries and scalatest library are different for > different java versions. > Scala libraries and scalatest library should be updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12003) Java thin client fails to get object with compact footer from cache
[
https://issues.apache.org/jira/browse/IGNITE-12003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027380#comment-17027380
]
Aleksey Plekhanov commented on IGNITE-12003:
[~Pavlukhin], I can't reproduce it using your reproducer on 2.7.5, 2.7.6 and
current master. Can you please also attach a full stack trace of the error?
> Java thin client fails to get object with compact footer from cache
> ---
>
> Key: IGNITE-12003
> URL: https://issues.apache.org/jira/browse/IGNITE-12003
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Ivan Pavlukhin
>Priority: Major
> Attachments: ThinClientCompactFooterDeserializationProblem.java
>
>
> Experiment:
> 1. Start server.
> 2. Start thin client, configure to use compact footer. Put some Pojo into
> cache.
> 3. Start another client (compact footer enabled). Try to read Pojo saved in
> previous step (Pojo class is available).
> Result -- {{BinaryObjectException("Cannot find metadata for object with
> compact footer: " + typeId)}}.
> See attached reproducer.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
[
https://issues.apache.org/jira/browse/IGNITE-10960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027348#comment-17027348
]
Ivan Pavlukhin commented on IGNITE-10960:
-
[~shroman], are you still working on this issue? If not could you please stop
progress and set the issue unassigned?
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key
> --
>
> Key: IGNITE-10960
> URL: https://issues.apache.org/jira/browse/IGNITE-10960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mikhail Cherkasov
>Assignee: Roman Shtykh
>Priority: Blocker
> Attachments: ThinClientGets.java
>
>
> Thin client cannot retrieve data that was inserted with the Thick Ignite
> client when using a composite key.
>
> See the attached reproducer:
> ThinClientGets.java
>
> thickCache.put(new TestKey("a", "0"), 1);
> thickCache.get(new TestKey("a", "0")); // returns 1
> thinCache.get(new TestKey("a", "0")) // returns null
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10698) Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
[
https://issues.apache.org/jira/browse/IGNITE-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lev Kiselev reassigned IGNITE-10698:
Assignee: Lev Kiselev
> Get rid of @MXBeanParametersNames and @MXBeanParametersDescriptions
> ---
>
> Key: IGNITE-10698
> URL: https://issues.apache.org/jira/browse/IGNITE-10698
> Project: Ignite
> Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Lev Kiselev
>Priority: Major
> Labels: newbie, usability
> Fix For: 3.0
>
>
> {noformat}
> @MXBeanDescription("Returns or kills transactions matching the filter
> conditions.")
> @MXBeanParametersNames(
> {
> "minDuration",
> "minSize",
> "prj",
> "consistentIds",
> "xid",
> "lbRegex",
> "limit",
> "order",
> "detailed",
> "kill"
> }
> )
> @MXBeanParametersDescriptions(
> {
> "Minimum duration (seconds).",
> "Minimum size.",
> "Projection (servers|clients).",
> "Consistent ids (separated by comma).",
> "Transaction XID.",
> "Label regexp.",
> "Limit a number of transactions collected on each node.",
> "Order by DURATION|SIZE.",
> "Show detailed description, otherwise only count.",
> "Kill matching transactions (be careful)."
> }
> )
> {noformat}
> Above looks pretty ugly and is very error prone due to messing names and
> descr order or number of strings.
> I would suggest to introduce individual parameters annotations and get them
> via mtd.getParamterAnnotations() at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12612) Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496
Denis Chudov created IGNITE-12612: - Summary: Failing test IoStatisticsBasicIndexSelfTest.testMetricRegistryRemovedOnIndexDrop after IGNITE-12496 Key: IGNITE-12612 URL: https://issues.apache.org/jira/browse/IGNITE-12612 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Assignee: Denis Chudov In IGNITE-12496 a new method of destroying index was added (H2TreeIndex#asyncDestroy), and there are no changes from IGNITE-11987 in it, the changes are only present in old H2TreeIndex#destroy. We should apply changes to new method. Also it would be better to refactor both methods to prevent such errors in future. Failing test history [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1153260173537232526=%3Cdefault%3E=testDetails] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11797) Fix consistency issues for atomic and mixed tx-atomic cache groups.
[ https://issues.apache.org/jira/browse/IGNITE-11797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027295#comment-17027295 ] Alexey Scherbakov commented on IGNITE-11797: [~xtern] This change is necessary until we fix all remaining issues with atomic caches consistency. Right now it's possible some update will be absent in the WAL causing this assertion to trigger if a primary node has left under load and returned later. Reproducible by AtomicPartitionCounterStateConsistencyHistoryRebalanceTest (added in this contribution). The assertion should be enabled again after the consistency fix is done. > Fix consistency issues for atomic and mixed tx-atomic cache groups. > --- > > Key: IGNITE-11797 > URL: https://issues.apache.org/jira/browse/IGNITE-11797 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > IGNITE-10078 only solves consistency problems for tx mode. > For atomic caches the rebalance consistency issues still remain and should be > fixed together with improvement of atomic cache protocol consistency. > Also, need to disable dynamic start of atomic cache in group having only tx > caches because it's not working in current state. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12582) It is needed to set used cache for Spring Data dynamically
[ https://issues.apache.org/jira/browse/IGNITE-12582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chernolyas updated IGNITE-12582: --- Summary: It is needed to set used cache for Spring Data dynamically (was: It is needed to set used cache for Spring Data by property) > It is needed to set used cache for Spring Data dynamically > -- > > Key: IGNITE-12582 > URL: https://issues.apache.org/jira/browse/IGNITE-12582 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.7.6 >Reporter: Sergey Chernolyas >Assignee: Sergey Chernolyas >Priority: Major > > Hi! > My project needs to configure used cache by property, like > ""[spring.data|http://spring.data/].mongodb.uri: > mongodb://:@:/" from Spring Data for > MongoDB. Now, I can set cache for particular repository by annotation > "RepositoryConfig" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12611) EntryProcessorPermissionCheckTest.test: Test looks flaky
[ https://issues.apache.org/jira/browse/IGNITE-12611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027273#comment-17027273 ] Denis Garus edited comment on IGNITE-12611 at 1/31/20 8:18 AM: --- I've started the Security suite a few times, and everything looks ok. [Security suite|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?branch=pull%2F7342%2Fhead=overview=builds] was (Author: garus.d.g): I've started the Security suite a few times, and everything looks ok. [Security suite|[https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?branch=pull%2F7342%2Fhead=overview=builds]] > EntryProcessorPermissionCheckTest.test: Test looks flaky > > > Key: IGNITE-12611 > URL: https://issues.apache.org/jira/browse/IGNITE-12611 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Test looks flaky.Test status change in build without changes: from failed to > successful -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12611) EntryProcessorPermissionCheckTest.test: Test looks flaky
[ https://issues.apache.org/jira/browse/IGNITE-12611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027273#comment-17027273 ] Denis Garus commented on IGNITE-12611: -- I've started the Security suite a few times, and everything looks ok. [Security suite|[https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?branch=pull%2F7342%2Fhead=overview=builds]] > EntryProcessorPermissionCheckTest.test: Test looks flaky > > > Key: IGNITE-12611 > URL: https://issues.apache.org/jira/browse/IGNITE-12611 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Test looks flaky.Test status change in build without changes: from failed to > successful -- This message was sent by Atlassian Jira (v8.3.4#803005)
