[jira] [Created] (IGNITE-14766) Ignite.close() hardcodes cancel = true
Scott Feldstein created IGNITE-14766:
Summary: Ignite.close() hardcodes cancel = true
Key: IGNITE-14766
URL: https://issues.apache.org/jira/browse/IGNITE-14766
Project: Ignite
Issue Type: Improvement
Reporter: Scott Feldstein
{{Ignite.close()}} hardcodes {{cancel = true}} in
[IgniteKernal.close()|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L3821]
{code:java}
@Override public void close() throws IgniteException {
Ignition.stop(igniteInstanceName, true);
}
{code}
Spring automatically calls {{close()}} when ignite is injected into the context
as a bean. When the application context is shutdown it would be great to be
able to change this to {{cancel = false}} to allow ignite to gracefully shutdown
I'd like to see this logic injected into runtime using a java system property
to override this behavior. This would allow ignite to be gracefully shutdown
without having to write an extra shutdown hook.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14699) Provide Index Queries API
[ https://issues.apache.org/jira/browse/IGNITE-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14699: Description: Phase 1 from: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] Some notes about implementation: 1. MergeSort reducer of index queries isn't part of this ticket. So this ticket should provide queries for operations: lt, gt, lte, gte, between. See IGNITE-14703. 2. There is no lock on Index in moment of querying. So concurrent operations on index can affect result of query. SQL also doesn't lock index. 3. QueryParallelism doesn't affects IndexQuery. IndexQuery reuse infrastructure of CacheQuery, and it doesn't use info about segments. It should be done in a separate ticket, providing parallelism by segments. Currently we initialize cursor over segments within same thread sequentially. Segments initialization is fast operation, so there is no much overhead. 4. By the same reason IndexQuery fetches index lazy. SQL fetches index when query is initialized, after that user iterates over prepared result. IndexQuery doesn't prepare result. In case of multiple segments, it will slow down IndexQuery while parallelism isn't implemented. From other side, it make result more sensitive for concurrent operations on an index. After implementing query parallelism, we can will 3rd issue. 4th should be discussed after that, after some performance testing. was: Phase 1 from: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] Some notes about implementation: 1. MergeSort reducer of index queries isn't part of this ticket. So this ticket should provide queries for operations: lt, gt, lte, gte, between. 2. > Provide Index Queries API > - > > Key: IGNITE-14699 > URL: https://issues.apache.org/jira/browse/IGNITE-14699 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Time Spent: 10m > Remaining Estimate: 0h > > Phase 1 from: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] > Some notes about implementation: > 1. MergeSort reducer of index queries isn't part of this ticket. So this > ticket should provide queries for operations: lt, gt, lte, gte, between. See > IGNITE-14703. > 2. There is no lock on Index in moment of querying. So concurrent operations > on index can affect result of query. SQL also doesn't lock index. > 3. QueryParallelism doesn't affects IndexQuery. IndexQuery reuse > infrastructure of CacheQuery, and it doesn't use info about segments. It > should be done in a separate ticket, providing parallelism by segments. > Currently we initialize cursor over segments within same thread sequentially. > Segments initialization is fast operation, so there is no much overhead. > 4. By the same reason IndexQuery fetches index lazy. SQL fetches index when > query is initialized, after that user iterates over prepared result. > IndexQuery doesn't prepare result. In case of multiple segments, it will slow > down IndexQuery while parallelism isn't implemented. From other side, it make > result more sensitive for concurrent operations on an index. > > After implementing query parallelism, we can will 3rd issue. 4th should be > discussed after that, after some performance testing. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14699) Provide Index Queries API
[ https://issues.apache.org/jira/browse/IGNITE-14699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14699: Description: Phase 1 from: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] Some notes about implementation: 1. MergeSort reducer of index queries isn't part of this ticket. So this ticket should provide queries for operations: lt, gt, lte, gte, between. 2. was: Phase 1 from: [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] Note that merge sort reducer of index queries isn't part of this ticket. So this ticket should provide queries for operations: lt, gt, lte, gte, between. > Provide Index Queries API > - > > Key: IGNITE-14699 > URL: https://issues.apache.org/jira/browse/IGNITE-14699 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Time Spent: 10m > Remaining Estimate: 0h > > Phase 1 from: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-71%3A+Public+API+for+secondary+index+search] > Some notes about implementation: > 1. MergeSort reducer of index queries isn't part of this ticket. So this > ticket should provide queries for operations: lt, gt, lte, gte, between. > 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14762) Leader refresh sometimes blocks indefinitely
[
https://issues.apache.org/jira/browse/IGNITE-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14762:
-
Description:
{{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a request
from a node to itself.
h2. Probable cause
We suspect that {{DelegatingTransportFactory#requestResponseToSelf}} contains a
race condition: {{Flux}} returned by the {{listen()}} method might be lazily
evaluated, in which case the client will start listening for messages after the
message event handlers have already been executed, so no new incoming messages
will actually be detected.
was:{{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a
request from a node to itself.
> Leader refresh sometimes blocks indefinitely
>
>
> Key: IGNITE-14762
> URL: https://issues.apache.org/jira/browse/IGNITE-14762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3, networking
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a
> request from a node to itself.
> h2. Probable cause
> We suspect that {{DelegatingTransportFactory#requestResponseToSelf}} contains
> a race condition: {{Flux}} returned by the {{listen()}} method might be
> lazily evaluated, in which case the client will start listening for messages
> after the message event handlers have already been executed, so no new
> incoming messages will actually be detected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14765) Stop of Ignite node should be supported by ignite-ctl tool
Alexander Lapin created IGNITE-14765: Summary: Stop of Ignite node should be supported by ignite-ctl tool Key: IGNITE-14765 URL: https://issues.apache.org/jira/browse/IGNITE-14765 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin To be provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[ https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349369#comment-17349369 ] Mirza Aliev commented on IGNITE-14764: -- LGTM > Consolidation of managers and metastorage server implementation. > > > Key: IGNITE-14764 > URL: https://issues.apache.org/jira/browse/IGNITE-14764 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Blocker > Labels: 3.0.0-alpha2, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > After merging meta storage server logic few bugs of ignition start, table > creation and atomic operations were revealed. Some of them will be specified > in greater detail and fixed within corresponding tickets: > * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading > tableConfiguration from ConfigurationManager within SchemaManager > * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh > sometimes blocks indefinitely > * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, > etc support > Other issues will be fixed within given ticket: > * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 > should be used instead. That produced Mutilple AssertionErros. > * Incorrect masterKey invoke condition in DistributedConfigurationStorage: > Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no > MASTER_KEY, which is always true on initial node startup without PDS > * Schema descriptor serialization issues > * String type is unsupported. > * Incorrect assignment calculation based on Vault, TableConfiguration from > ConfigurationManager will be used instead. > * Empty metastorageNodes configuration property. Default value will be added. > * Incorrect tblId parsing in SchemaManager > * and few more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[ https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-14764: - Reviewer: Mirza Aliev > Consolidation of managers and metastorage server implementation. > > > Key: IGNITE-14764 > URL: https://issues.apache.org/jira/browse/IGNITE-14764 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Blocker > Labels: 3.0.0-alpha2, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > After merging meta storage server logic few bugs of ignition start, table > creation and atomic operations were revealed. Some of them will be specified > in greater detail and fixed within corresponding tickets: > * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading > tableConfiguration from ConfigurationManager within SchemaManager > * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh > sometimes blocks indefinitely > * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, > etc support > Other issues will be fixed within given ticket: > * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 > should be used instead. That produced Mutilple AssertionErros. > * Incorrect masterKey invoke condition in DistributedConfigurationStorage: > Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no > MASTER_KEY, which is always true on initial node startup without PDS > * Schema descriptor serialization issues > * String type is unsupported. > * Incorrect assignment calculation based on Vault, TableConfiguration from > ConfigurationManager will be used instead. > * Empty metastorageNodes configuration property. Default value will be added. > * Incorrect tblId parsing in SchemaManager > * and few more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14762) Leader refresh sometimes blocks indefinitely
[
https://issues.apache.org/jira/browse/IGNITE-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349368#comment-17349368
]
Semyon Danilov commented on IGNITE-14762:
-
The patch looks good to me
> Leader refresh sometimes blocks indefinitely
>
>
> Key: IGNITE-14762
> URL: https://issues.apache.org/jira/browse/IGNITE-14762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3, networking
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a
> request from a node to itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-14658: --- Assignee: Mikhail Petrov (was: Nikolay Izhikov) > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14044) Cache with node filter is not destroyed properly on the filtered node.
[
https://issues.apache.org/jira/browse/IGNITE-14044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349347#comment-17349347
]
Maxim Muzafarov commented on IGNITE-14044:
--
[~xtern]
Hello, I've looked through you changes - the main issue that current patch
doesn't covers the cases when a single cache destroyed in a shared cache group.
I can suggest an implementation draft plan:
- in the {{processCacheStopRequestOnExchangeDone}} we should destroy the cache
configuration of stopping cache on a filtered node no matter cache adapter
exists or not;
- onCacheGroupsStopped of database shared manager should have a list of cache
descriptors for input instead of cache group context since some of them may be
null on filtered nodes;
- {{shutdownForCacheGroup}} shouldn't perform delete cache configurations, it
should check that they don't exist instead;
- {{stopCacheGroup}} must be reworked with common sense when we should delete
{{cachesInfo.cleanupRemovedGroup}} only
> Cache with node filter is not destroyed properly on the filtered node.
> --
>
> Key: IGNITE-14044
> URL: https://issues.apache.org/jira/browse/IGNITE-14044
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce the problem:
> # Start 2 nodes
> # Create a cache with node filter (filter second node)
> # Destroy cache
> # Restart nodes
> Expected: cache was destroyed on both nodes.
> Actual: cache was destroyed only on one node, the second node cannot join
> the cluster with the following error:
> {noformat}
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Joining node has
> caches with data which are not presented on cluster, it could mean that they
> were already destroyed, to add the node to cluster - remove directories with
> the caches[cache1]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2052)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1197)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:472)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2154)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> ... 23 more
> {noformat}
> Reproducer
> {code:java}
> public class IgnitePdsDestroyCacheWithNodeFilterTest extends
> GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setConsistentId(igniteInstanceName)
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> }
> @Test
> public void testDestroyCacheWithNodeFilter() throws Exception {
> cleanPersistenceDir();
> Ignite ignite = startGrids(2);
> ignite.cluster().state(ClusterState.ACTIVE);
> UUID nodeId0 = ignite.cluster().localNode().id();
> CacheConfiguration cfg1 = new
> CacheConfiguration<>("cache1")
> .setCacheMode(CacheMode.REPLICATED)
> .setNodeFilter(n -> nodeId0.equals(n.id()));
> IgniteCache cache1 = ignite.createCache(cfg1);
> cache1.destroy();
> forceCheckpoint();
> awaitPartitionMapExchange();
> stopAllGrids();
> ignite = startGrids(2); // failing here
> ignite.cluster().state(ClusterState.ACTIVE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349343#comment-17349343
]
Stephen Darlington commented on IGNITE-14750:
-
[~zstan], no, I don't know how it happened is the short version. They deleted
the files before I was able to see the directory structure. A Null Pointer
Exception here could be caused by it being a file rather than a directory.
Maxim suggests it could be a concurrency issue, which is also plausible. As far
as I can tell, File#listFiles() throws a SecurityException if it doesn't have
permission. "I don't know" isn't terribly satisfying, but that's why I improved
the error handling.
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349329#comment-17349329 ] Denis Chudov commented on IGNITE-14728: --- [~erixon] LGTM. > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Assignee: Eduard Rakhmankulov >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most > part of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349313#comment-17349313
]
Ivan Bessonov commented on IGNITE-14756:
[~maliev] thank you for the fix, looks right!
> NPE on reading tableConfiguration from ConfigurationManager within
> SchemaManager
>
>
> Key: IGNITE-14756
> URL: https://issues.apache.org/jira/browse/IGNITE-14756
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes we get following NPE
>
> {code:java}
> SEVERE: Failed to notify configuration listener.
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
> at
> reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
> at
> reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
> at
> reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
> at
> reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
> at
> reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
> at
> reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
> at
> reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
> at
> java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
> at
> org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abs
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14756:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> NPE on reading tableConfiguration from ConfigurationManager within
> SchemaManager
>
>
> Key: IGNITE-14756
> URL: https://issues.apache.org/jira/browse/IGNITE-14756
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Sometimes we get following NPE
>
> {code:java}
> SEVERE: Failed to notify configuration listener.
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
> at
> reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
> at
> reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
> at
> reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
> at
> reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
> at
> reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
> at
> reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
> at
> reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
> at
> java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
> at
> org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
>
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[ https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14764: - Description: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS * Schema descriptor serialization issues * String type is unsupported. * Incorrect assignment calculation based on Vault, TableConfiguration from ConfigurationManager will be used instead. * Empty metastorageNodes configuration property. Default value will be added. * Incorrect tblId parsing in SchemaManager * and few more. was: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS * Column serialization issue because of serialization lambda * String type is unsupported. * Incorrect assignment calculation based on Vault, TableConfiguration from ConfigurationManager will be used instead. * Empty metastorageNodes configuration property. Default value will be added. > Consolidation of managers and metastorage server implementation. > > > Key: IGNITE-14764 > URL: https://issues.apache.org/jira/browse/IGNITE-14764 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Blocker > Labels: 3.0.0-alpha2, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After merging meta storage server logic few bugs of ignition start, table > creation and atomic operations were revealed. Some of them will be specified > in greater detail and fixed within corresponding tickets: > * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading > tableConfiguration from ConfigurationManager within SchemaManager > * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh > sometimes blocks indefinitely > * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, > etc support > Other issues will be fixed within given ticket: > * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 > should be used instead. That produced Mutilple AssertionErros. > * Incorrect masterKey invoke condition in DistributedConfigurationStorage: > Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no > MASTER_KEY, which is always true on initial node startup without PDS > * Schema descriptor serialization issues > * String type is unsupported. > * Incorrect assignment calculation based on Vault, TableConfiguration from > ConfigurationManager will be used instead. > * Empty metastorageNodes configuration property. Default value will be added. > * Incorrect tblId parsing in SchemaManager > * and few more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349303#comment-17349303
]
Stanilovsky Evgeny commented on IGNITE-14750:
-
[~sdarlington] hello ! you said : "but it turns out to be a file" do you have
ideas how this could happen ? Does file permissions are the same on whole nodes
?
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[ https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14764: - Description: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS * Column serialization issue because of serialization lambda * String type is unsupported. * Incorrect assignment calculation based on Vault, TableConfiguration from ConfigurationManager will be used instead. was: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS > Consolidation of managers and metastorage server implementation. > > > Key: IGNITE-14764 > URL: https://issues.apache.org/jira/browse/IGNITE-14764 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Blocker > Labels: 3.0.0-alpha2, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After merging meta storage server logic few bugs of ignition start, table > creation and atomic operations were revealed. Some of them will be specified > in greater detail and fixed within corresponding tickets: > * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading > tableConfiguration from ConfigurationManager within SchemaManager > * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh > sometimes blocks indefinitely > * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, > etc support > Other issues will be fixed within given ticket: > * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 > should be used instead. That produced Mutilple AssertionErros. > * Incorrect masterKey invoke condition in DistributedConfigurationStorage: > Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no > MASTER_KEY, which is always true on initial node startup without PDS > * Column serialization issue because of serialization lambda > * String type is unsupported. > * Incorrect assignment calculation based on Vault, TableConfiguration from > ConfigurationManager will be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.conc
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.conc
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.conc
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.conc
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.conc
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[ https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-14764: - Description: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS * Column serialization issue because of serialization lambda * String type is unsupported. * Incorrect assignment calculation based on Vault, TableConfiguration from ConfigurationManager will be used instead. * Empty metastorageNodes configuration property. Default value will be added. was: After merging meta storage server logic few bugs of ignition start, table creation and atomic operations were revealed. Some of them will be specified in greater detail and fixed within corresponding tickets: * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading tableConfiguration from ConfigurationManager within SchemaManager * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh sometimes blocks indefinitely * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, etc support Other issues will be fixed within given ticket: * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 should be used instead. That produced Mutilple AssertionErros. * Incorrect masterKey invoke condition in DistributedConfigurationStorage: Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no MASTER_KEY, which is always true on initial node startup without PDS * Column serialization issue because of serialization lambda * String type is unsupported. * Incorrect assignment calculation based on Vault, TableConfiguration from ConfigurationManager will be used instead. > Consolidation of managers and metastorage server implementation. > > > Key: IGNITE-14764 > URL: https://issues.apache.org/jira/browse/IGNITE-14764 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Vladislav Pyatkov >Priority: Blocker > Labels: 3.0.0-alpha2, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After merging meta storage server logic few bugs of ignition start, table > creation and atomic operations were revealed. Some of them will be specified > in greater detail and fixed within corresponding tickets: > * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading > tableConfiguration from ConfigurationManager within SchemaManager > * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh > sometimes blocks indefinitely > * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64, > etc support > Other issues will be fixed within given ticket: > * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1 > should be used instead. That produced Mutilple AssertionErros. > * Incorrect masterKey invoke condition in DistributedConfigurationStorage: > Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no > MASTER_KEY, which is always true on initial node startup without PDS > * Column serialization issue because of serialization lambda > * String type is unsupported. > * Incorrect assignment calculation based on Vault, TableConfiguration from > ConfigurationManager will be used instead. > * Empty metastorageNodes configuration property. Default value will be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[
https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-14764:
-
Description:
After merging meta storage server logic few bugs of ignition start, table
creation and atomic operations were revealed. Some of them will be specified in
greater detail and fixed within corresponding tickets:
* https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
tableConfiguration from ConfigurationManager within SchemaManager
* https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
sometimes blocks indefinitely
* https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
etc support
Other issues will be fixed within given ticket:
* Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
should be used instead. That produced Mutilple AssertionErros.
* Incorrect masterKey invoke condition in DistributedConfigurationStorage:
Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no
MASTER_KEY, which is always true on initial node startup without PDS
was:
After merging meta storage server logic few bugs of ignition start, table
creation and atomic operations were revealed. Some of them will be specified in
greater detail and fixed within corresponding tickets:
* https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
tableConfiguration from ConfigurationManager within SchemaManager
* https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
sometimes blocks indefinitely
* https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
etc support
Other issues will be fixed within given ticket:
* Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
should be used instead. That produced Mutilple AssertionErros.
* Incorrect masterKey invoke condition in DistributedConfigurationStorage
{code:java}
Conditions.revision(MASTER_KEY).eq(ver.get())
{code}
That won't work if there's no MASTER_KEY, which is always true on initial node
startup without PDS
> Consolidation of managers and metastorage server implementation.
>
>
> Key: IGNITE-14764
> URL: https://issues.apache.org/jira/browse/IGNITE-14764
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: 3.0.0-alpha2, ignite-3
>
> After merging meta storage server logic few bugs of ignition start, table
> creation and atomic operations were revealed. Some of them will be specified
> in greater detail and fixed within corresponding tickets:
> * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
> tableConfiguration from ConfigurationManager within SchemaManager
> * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
> sometimes blocks indefinitely
> * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
> etc support
> Other issues will be fixed within given ticket:
> * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
> should be used instead. That produced Mutilple AssertionErros.
> * Incorrect masterKey invoke condition in DistributedConfigurationStorage:
> Conditions.revision(MASTER_KEY).eq(ver.get()) That won't work if there's no
> MASTER_KEY, which is always true on initial node startup without PDS
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
[
https://issues.apache.org/jira/browse/IGNITE-14764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-14764:
-
Description:
After merging meta storage server logic few bugs of ignition start, table
creation and atomic operations were revealed. Some of them will be specified in
greater detail and fixed within corresponding tickets:
* https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
tableConfiguration from ConfigurationManager within SchemaManager
* https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
sometimes blocks indefinitely
* https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
etc support
Other issues will be fixed within given ticket:
* Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
should be used instead. That produced Mutilple AssertionErros.
* Incorrect masterKey invoke condition in DistributedConfigurationStorage
{code:java}
Conditions.revision(MASTER_KEY).eq(ver.get())
{code}
That won't work if there's no MASTER_KEY, which is always true on initial node
startup without PDS
was:
After merging meta storage server logic few bugs of ignition start, table
creation and atomic operations were revealed. Some of them will be specified in
greater detail and fixed within corresponding tickets:
* https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
tableConfiguration from ConfigurationManager within SchemaManager
* https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
sometimes blocks indefinitely
* https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
etc support
Other issues will be fixed within given ticket:
* Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
should be used instead. That produced Mutilple AssertionErros.
* Incorrect masterKey invoke condition in DistributedConfigurationStorage
{code:java}
Conditions.revision(MASTER_KEY).eq(ver.get())
{code}
That won't work if there's no MASTER_KEY, which is always true on initial node
startup without PDS
> Consolidation of managers and metastorage server implementation.
>
>
> Key: IGNITE-14764
> URL: https://issues.apache.org/jira/browse/IGNITE-14764
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: 3.0.0-alpha2, ignite-3
>
> After merging meta storage server logic few bugs of ignition start, table
> creation and atomic operations were revealed. Some of them will be specified
> in greater detail and fixed within corresponding tickets:
> * https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
> tableConfiguration from ConfigurationManager within SchemaManager
> * https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
> sometimes blocks indefinitely
> * https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
> etc support
> Other issues will be fixed within given ticket:
> * Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
> should be used instead. That produced Mutilple AssertionErros.
> * Incorrect masterKey invoke condition in DistributedConfigurationStorage
> {code:java}
> Conditions.revision(MASTER_KEY).eq(ver.get())
> {code}
> That won't work if there's no MASTER_KEY, which is always true on initial
> node startup without PDS
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14764) Consolidation of managers and metastorage server implementation.
Alexander Lapin created IGNITE-14764:
Summary: Consolidation of managers and metastorage server
implementation.
Key: IGNITE-14764
URL: https://issues.apache.org/jira/browse/IGNITE-14764
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Vladislav Pyatkov
After merging meta storage server logic few bugs of ignition start, table
creation and atomic operations were revealed. Some of them will be specified in
greater detail and fixed within corresponding tickets:
* https://issues.apache.org/jira/browse/IGNITE-14756 - NPE on reading
tableConfiguration from ConfigurationManager within SchemaManager
* https://issues.apache.org/jira/browse/IGNITE-14762 - Leader refresh
sometimes blocks indefinitely
* https://issues.apache.org/jira/browse/IGNITE-14290 Includes INT32, INT64,
etc support
Other issues will be fixed within given ticket:
* Incoorect usage of appliedRevision as watch revision. appliedRevision + 1
should be used instead. That produced Mutilple AssertionErros.
* Incorrect masterKey invoke condition in DistributedConfigurationStorage
{code:java}
Conditions.revision(MASTER_KEY).eq(ver.get())
{code}
That won't work if there's no MASTER_KEY, which is always true on initial node
startup without PDS
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[
https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349281#comment-17349281
]
Ignite TC Bot commented on IGNITE-14728:
{panel:title=Branch: [pull/9110/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9110/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6015464]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerPropertiesTest.testPropertyWalRebalanceThreshold -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6015472&buildTypeId=IgniteTests24Java8_RunAll]
> Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed
> property
> --
>
> Key: IGNITE-14728
> URL: https://issues.apache.org/jira/browse/IGNITE-14728
> Project: Ignite
> Issue Type: Improvement
>Reporter: Eduard Rakhmankulov
>Assignee: Eduard Rakhmankulov
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that
> determines a count of entries of partition starting from which cluster will
> try applying historical rebalance for that partition.
> But the system property is not convenient to use and is hidden from most
> part of users.
> I propose the creation of a new DMS property *wal.rebalance.threshold*
> instead of a system property.
> The next algorithm will be used:
> # On node start *wal.rebalance.threshold* property will be checked.
> # If there is no value, then the old system property
> *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS.
> # If a system property is not defined then the default value from java will
> be written to DMS (*500*).
> # On property check print to log value and source of value.
> Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349282#comment-17349282 ] Eduard Rakhmankulov commented on IGNITE-14728: -- [~Denis Chudov] please look again > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Assignee: Eduard Rakhmankulov >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most > part of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14763) Inconsistence btwee meta storage client interface and server implementation
[
https://issues.apache.org/jira/browse/IGNITE-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14763:
Description:
{{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
{{keyFrom}} as "Start key of range (inclusive). Could be null." while
{{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for {{keyForm}}.
Needs to allow meta storage take {{null}} value for {{keyFrom}}.
was:
{{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
{{keyFrom}} as "Start key of range (inclusive). Could be {@code null}." while
{{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for {{keyForm}}.
Needs to allow meta storage take {{null}} value for {{keyFrom}}.
> Inconsistence btwee meta storage client interface and server implementation
> ---
>
> Key: IGNITE-14763
> URL: https://issues.apache.org/jira/browse/IGNITE-14763
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
>
> {{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
> {{keyFrom}} as "Start key of range (inclusive). Could be null." while
> {{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for
> {{keyForm}}.
> Needs to allow meta storage take {{null}} value for {{keyFrom}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14763) Inconsistence btwee meta storage client interface and server implementation
Andrey N. Gura created IGNITE-14763:
---
Summary: Inconsistence btwee meta storage client interface and
server implementation
Key: IGNITE-14763
URL: https://issues.apache.org/jira/browse/IGNITE-14763
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
Assignee: Andrey N. Gura
{{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
{{keyFrom}} as "_Start key of range (inclusive). Could be {@code null}._" while
{{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for {{keyForm}}.
Needs to allow meta storage take {{null}} value for {{keyFrom}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14763) Inconsistence btwee meta storage client interface and server implementation
[
https://issues.apache.org/jira/browse/IGNITE-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14763:
Description:
{{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
{{keyFrom}} as "Start key of range (inclusive). Could be {@code null}." while
{{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for {{keyForm}}.
Needs to allow meta storage take {{null}} value for {{keyFrom}}.
was:
{{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
{{keyFrom}} as "_Start key of range (inclusive). Could be {@code null}._" while
{{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for {{keyForm}}.
Needs to allow meta storage take {{null}} value for {{keyFrom}}.
> Inconsistence btwee meta storage client interface and server implementation
> ---
>
> Key: IGNITE-14763
> URL: https://issues.apache.org/jira/browse/IGNITE-14763
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
>
> {{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
> {{keyFrom}} as "Start key of range (inclusive). Could be {@code null}." while
> {{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for
> {{keyForm}}.
> Needs to allow meta storage take {{null}} value for {{keyFrom}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14741) Extend coverage of unit tests to public methods of Affinity and Table managers
[ https://issues.apache.org/jira/browse/IGNITE-14741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14741: Fix Version/s: 3.0.0-alpha2 > Extend coverage of unit tests to public methods of Affinity and Table managers > -- > > Key: IGNITE-14741 > URL: https://issues.apache.org/jira/browse/IGNITE-14741 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h > Remaining Estimate: 0h > > We have to cover all public method of any components by unit tests. > In this issue we cover Affinity and Table managers by the unit tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14762) Leader refresh sometimes blocks indefinitely
[
https://issues.apache.org/jira/browse/IGNITE-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14762:
Labels: ignite-3 (was: )
> Leader refresh sometimes blocks indefinitely
>
>
> Key: IGNITE-14762
> URL: https://issues.apache.org/jira/browse/IGNITE-14762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> {{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a
> request from a node to itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14762) Leader refresh sometimes blocks indefinitely
Aleksandr Polovtcev created IGNITE-14762:
Summary: Leader refresh sometimes blocks indefinitely
Key: IGNITE-14762
URL: https://issues.apache.org/jira/browse/IGNITE-14762
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
{{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a request
from a node to itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14759) Wrong offset calculation for fix-sized column when nullmap is omitted.
[ https://issues.apache.org/jira/browse/IGNITE-14759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14759: -- Summary: Wrong offset calculation for fix-sized column when nullmap is omitted. (was: Wrong fixlen column offset calculation when nullmap is omitted. ) > Wrong offset calculation for fix-sized column when nullmap is omitted. > -- > > Key: IGNITE-14759 > URL: https://issues.apache.org/jira/browse/IGNITE-14759 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > > Method _Row.fixlenColumnOffset()_ returns wrong result for columns if schema > contains fixedsize columns only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14762) Leader refresh sometimes blocks indefinitely
[
https://issues.apache.org/jira/browse/IGNITE-14762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14762:
-
Fix Version/s: 3.0.0-alpha2
> Leader refresh sometimes blocks indefinitely
>
>
> Key: IGNITE-14762
> URL: https://issues.apache.org/jira/browse/IGNITE-14762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Fix For: 3.0.0-alpha2
>
>
> {{RaftGroupServiceImpl#refreshLeader}} sometimes blocks when sending a
> request from a node to itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14755) Meta storage is not public interface, so all classes should be moved to the internal package.
[
https://issues.apache.org/jira/browse/IGNITE-14755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14755:
Fix Version/s: 3.0.0-alpha2
> Meta storage is not public interface, so all classes should be moved to the
> internal package.
> -
>
> Key: IGNITE-14755
> URL: https://issues.apache.org/jira/browse/IGNITE-14755
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Meta storage is not public interface, so all classes should be moved to the
> internal package.
> It affects modules {{ignite-metastorage-client}} and
> {{ignite-metastorage-common}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14578) Bootstrap configuation manager with distributed configuration
[ https://issues.apache.org/jira/browse/IGNITE-14578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14578: Labels: iep-73 ignite-3 (was: iep-73) > Bootstrap configuation manager with distributed configuration > - > > Key: IGNITE-14578 > URL: https://issues.apache.org/jira/browse/IGNITE-14578 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73, ignite-3 > > Update IgntionImpl with code that will > * Add distributed root keys. > * Bootstrap distributed configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14413) Start of Ignite node should be supported by ignite-ctl tool
[ https://issues.apache.org/jira/browse/IGNITE-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14413: Labels: iep-73 ignite-3 (was: iep-73) > Start of Ignite node should be supported by ignite-ctl tool > --- > > Key: IGNITE-14413 > URL: https://issues.apache.org/jira/browse/IGNITE-14413 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: iep-73, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14581) Implement IgniteImpl close method
[ https://issues.apache.org/jira/browse/IGNITE-14581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14581: Labels: iep-73 ignite-3 (was: iep-73) > Implement IgniteImpl close method > - > > Key: IGNITE-14581 > URL: https://issues.apache.org/jira/browse/IGNITE-14581 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14581) Implement IgniteImpl close method
[ https://issues.apache.org/jira/browse/IGNITE-14581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14581: Fix Version/s: 3.0.0-alpha2 > Implement IgniteImpl close method > - > > Key: IGNITE-14581 > URL: https://issues.apache.org/jira/browse/IGNITE-14581 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73, ignite-3 > Fix For: 3.0.0-alpha2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14413) Start of Ignite node should be supported by ignite-ctl tool
[ https://issues.apache.org/jira/browse/IGNITE-14413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-14413: Fix Version/s: 3.0.0-alpha2 > Start of Ignite node should be supported by ignite-ctl tool > --- > > Key: IGNITE-14413 > URL: https://issues.apache.org/jira/browse/IGNITE-14413 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: iep-73, ignite-3 > Fix For: 3.0.0-alpha2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14756:
Labels: ignite-3 (was: )
> NPE on reading tableConfiguration from ConfigurationManager within
> SchemaManager
>
>
> Key: IGNITE-14756
> URL: https://issues.apache.org/jira/browse/IGNITE-14756
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> Sometimes we get following NPE
>
> {code:java}
> SEVERE: Failed to notify configuration listener.
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
> at
> reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
> at
> reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
> at
> reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
> at
> reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
> at
> reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
> at
> reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
> at
> reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
> at
> java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
> at
> org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractC
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14756:
Fix Version/s: 3.0.0-alpha2
> NPE on reading tableConfiguration from ConfigurationManager within
> SchemaManager
>
>
> Key: IGNITE-14756
> URL: https://issues.apache.org/jira/browse/IGNITE-14756
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Mirza Aliev
>Priority: Blocker
> Fix For: 3.0.0-alpha2
>
>
> Sometimes we get following NPE
>
> {code:java}
> SEVERE: Failed to notify configuration listener.
> java.util.concurrent.CompletionException: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
> at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
> at
> reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
> at
> reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
> at
> reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
> at
> reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
> at
> reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
> at
> reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
> at
> reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
> at
> reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
> at
> reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
> at
> reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
> at
> java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
> at
> org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
> at
> org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
[jira] [Commented] (IGNITE-14737) Calcite. Equals predicate with multiple results from subqueries must fail.
[
https://issues.apache.org/jira/browse/IGNITE-14737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349262#comment-17349262
]
Stanilovsky Evgeny commented on IGNITE-14737:
-
[~alex_pl], [~tledkov-gridgain] guys can u help with merge ? thanks
> Calcite. Equals predicate with multiple results from subqueries must fail.
>
>
> Key: IGNITE-14737
> URL: https://issues.apache.org/jira/browse/IGNITE-14737
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Suppose table looks like :
> *products*
> ||name||cat_id||subcat_id||
> |n1|1|10|
> |n2|2|10|
> |n3|3|11|
> and request :
> {noformat}
> SELECT NAME FROM products WHERE CAT_ID = (SELECT CAT_ID FROM products WHERE
> SUBCAT_ID = 10)
> {noformat}
> for now it correctly executed and returns undefined results, proposal :
> return ERROR and appropriate message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12747) Calcite integration. Correlated queries support.
[ https://issues.apache.org/jira/browse/IGNITE-12747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349261#comment-17349261 ] Stanilovsky Evgeny commented on IGNITE-12747: - [~alex_pl] fixed, can u check once more plz ? thanks > Calcite integration. Correlated queries support. > > > Key: IGNITE-12747 > URL: https://issues.apache.org/jira/browse/IGNITE-12747 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Andrey Mashenkov >Priority: Critical > Time Spent: 1h 10m > Remaining Estimate: 0h > > Rewrite correlated subqueries. > Useful links: > [https://zhuanlan.zhihu.com/p/60380557] > [https://zhuanlan.zhihu.com/p/62338250] > [https://zhuanlan.zhihu.com/p/66227661] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14758) Add messages to asserts in meta storage server implementation
[
https://issues.apache.org/jira/browse/IGNITE-14758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349181#comment-17349181
]
Kirill Gusakov commented on IGNITE-14758:
-
LGTM
> Add messages to asserts in meta storage server implementation
> -
>
> Key: IGNITE-14758
> URL: https://issues.apache.org/jira/browse/IGNITE-14758
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: ignite-3, ipe-61
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{SimpleInMemoryKeyValueStorage}} contains {{assert}}'s with out messages.
> Needs add messages to such assert.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14653) Generify Vault and Metastorage services interfaces
[
https://issues.apache.org/jira/browse/IGNITE-14653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-14653:
-
Description:
Currently, we have two separate interfaces {{ValutService}} and
{{MetastorageService}}, but they have a lot of common methods. Seems that it
would be convenient to have a common interface.
* Retrieve a common interface for vault and metastorage
* We need a common interface for listeners on vault and metastorage with
{{onUpdate}} and {{onError}} methods
* We should have {{Entry}} interface for vault that will be extended with
metastorage {{Entry}} with extra revision logic
* Also seems that {{Watcher}} from metastorage and vault might have a common
parent
* Use common contract for {{watch}} method in vault and metastorage
was:
Currently, we have two separate interfaces {{ValutService}} and
{{MetastorageService}}, but they have a lot of common methods. Seems that it
would be convenient to have a common interface.
* Retrieve a common interface for vault and metastorage
* We need a common interface for listeners on vault and metastorage with
{{onUpdate}} and {{onError}} methods
* We should have {{Entry}} interface for vault that will be extended with
metastorage {{Entry}} with extra revision logic
* Also seems that {{Watcher}} from metastorage and vault might have a common
parent
* Use common contract for {{watch}} method in vault and metastorage
> Generify Vault and Metastorage services interfaces
> ---
>
> Key: IGNITE-14653
> URL: https://issues.apache.org/jira/browse/IGNITE-14653
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: iep-61, ignite-3
>
> Currently, we have two separate interfaces {{ValutService}} and
> {{MetastorageService}}, but they have a lot of common methods. Seems that it
> would be convenient to have a common interface.
> * Retrieve a common interface for vault and metastorage
> * We need a common interface for listeners on vault and metastorage with
> {{onUpdate}} and {{onError}} methods
> * We should have {{Entry}} interface for vault that will be extended with
> metastorage {{Entry}} with extra revision logic
> * Also seems that {{Watcher}} from metastorage and vault might have a common
> parent
> * Use common contract for {{watch}} method in vault and metastorage
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14761) "Page locks dump" messages print lots of newlines, no page locks
[ https://issues.apache.org/jira/browse/IGNITE-14761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-14761. -- Resolution: Invalid Does not seem to be the case in master. > "Page locks dump" messages print lots of newlines, no page locks > > > Key: IGNITE-14761 > URL: https://issues.apache.org/jira/browse/IGNITE-14761 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > > I can see the following message in the log: > [CacheDiagnosticManager] Page locks dump: > and then 1134 newlines. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14761) "Page locks dump" messages print lots of newlines, no page locks
Ilya Kasnacheev created IGNITE-14761: Summary: "Page locks dump" messages print lots of newlines, no page locks Key: IGNITE-14761 URL: https://issues.apache.org/jira/browse/IGNITE-14761 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.10 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev I can see the following message in the log: [CacheDiagnosticManager] Page locks dump: and then 1134 newlines. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14760) Refactor GridResourceProcessor for reusage
[ https://issues.apache.org/jira/browse/IGNITE-14760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-14760: - Description: Logic to inject resource should be reused inside IgniteCDC to inject Logger, ApplicationContext, Spring bean, etc. > Refactor GridResourceProcessor for reusage > -- > > Key: IGNITE-14760 > URL: https://issues.apache.org/jira/browse/IGNITE-14760 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Logic to inject resource should be reused inside IgniteCDC to inject Logger, > ApplicationContext, Spring bean, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14760) Refactor GridResourceProcessor for reusage
Nikolay Izhikov created IGNITE-14760: Summary: Refactor GridResourceProcessor for reusage Key: IGNITE-14760 URL: https://issues.apache.org/jira/browse/IGNITE-14760 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14759) Wrong fixlen column offset calculation when nullmap is omitted.
Andrey Mashenkov created IGNITE-14759: - Summary: Wrong fixlen column offset calculation when nullmap is omitted. Key: IGNITE-14759 URL: https://issues.apache.org/jira/browse/IGNITE-14759 Project: Ignite Issue Type: Bug Reporter: Andrey Mashenkov Assignee: Andrey Mashenkov Fix For: 3.0.0-alpha2 Method _Row.fixlenColumnOffset()_ returns wrong result for columns if schema contains fixedsize columns only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14758) Add messages to asserts in meta storage server implementation
Andrey N. Gura created IGNITE-14758:
---
Summary: Add messages to asserts in meta storage server
implementation
Key: IGNITE-14758
URL: https://issues.apache.org/jira/browse/IGNITE-14758
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
Assignee: Andrey N. Gura
Fix For: 3.0.0-alpha2
{{SimpleInMemoryKeyValueStorage}} contains {{assert}}'s with out messages.
Needs add messages to such assert.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14758) Add messages to asserts in meta storage server implementation
[
https://issues.apache.org/jira/browse/IGNITE-14758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14758:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add messages to asserts in meta storage server implementation
> -
>
> Key: IGNITE-14758
> URL: https://issues.apache.org/jira/browse/IGNITE-14758
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: ignite-3, ipe-61
> Fix For: 3.0.0-alpha2
>
>
> {{SimpleInMemoryKeyValueStorage}} contains {{assert}}'s with out messages.
> Needs add messages to such assert.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14638) Calcite engine. Support for INTERSECT operator
[ https://issues.apache.org/jira/browse/IGNITE-14638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349132#comment-17349132 ] Aleksey Plekhanov commented on IGNITE-14638: [~taras.ledkov], [~korlov], can you please have a look at the patch? > Calcite engine. Support for INTERSECT operator > -- > > Key: IGNITE-14638 > URL: https://issues.apache.org/jira/browse/IGNITE-14638 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, INTERSECT operator is not supported -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14724) Calcite engine. Create table with DATE column creates INTEGER column
[
https://issues.apache.org/jira/browse/IGNITE-14724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349131#comment-17349131
]
Aleksey Plekhanov commented on IGNITE-14724:
[~taras.ledkov], [~korlov], can you please have a look at the patch?
> Calcite engine. Create table with DATE column creates INTEGER column
>
>
> Key: IGNITE-14724
> URL: https://issues.apache.org/jira/browse/IGNITE-14724
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t(d DATE)", true);
> sql("INSERT INTO t VALUES (date '2021-01-01')", true);
> {code}
> Fails with:
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Cannot assign to target field 'D' of type INTEGER from source field 'DATE
> '2021-01-01'' of type DATE{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14737) Calcite. Equals predicate with multiple results from subqueries must fail.
[
https://issues.apache.org/jira/browse/IGNITE-14737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349107#comment-17349107
]
Konstantin Orlov commented on IGNITE-14737:
---
[~zstan], the patch looks good to me. Please resolve all conflicts and proceed
with merging.
> Calcite. Equals predicate with multiple results from subqueries must fail.
>
>
> Key: IGNITE-14737
> URL: https://issues.apache.org/jira/browse/IGNITE-14737
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Suppose table looks like :
> *products*
> ||name||cat_id||subcat_id||
> |n1|1|10|
> |n2|2|10|
> |n3|3|11|
> and request :
> {noformat}
> SELECT NAME FROM products WHERE CAT_ID = (SELECT CAT_ID FROM products WHERE
> SUBCAT_ID = 10)
> {noformat}
> for now it correctly executed and returns undefined results, proposal :
> return ERROR and appropriate message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14757) Calcite. CorrelatedNestedLoopJoinRule with batched instantiation fail with current tests.
Stanilovsky Evgeny created IGNITE-14757: --- Summary: Calcite. CorrelatedNestedLoopJoinRule with batched instantiation fail with current tests. Key: IGNITE-14757 URL: https://issues.apache.org/jira/browse/IGNITE-14757 Project: Ignite Issue Type: Bug Components: sql Reporter: Stanilovsky Evgeny changing CorrelatedNestedLoopJoinRule#INSTANCE into CorrelatedNestedLoopJoinRule#INSTANCE_BATCHED and further call of IgniteCalciteTestSuite will stops all tets progress. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12885) Checkpoint thread executes partitions fsync in single thread
[ https://issues.apache.org/jira/browse/IGNITE-12885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-12885: Assignee: Ilya Kasnacheev (was: Ivan Bessonov) > Checkpoint thread executes partitions fsync in single thread > > > Key: IGNITE-12885 > URL: https://issues.apache.org/jira/browse/IGNITE-12885 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > It should use "asyncRunner" if it was configured, this will optimize > checkpoint speed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-2909) Checking cache object type in runtime
[ https://issues.apache.org/jira/browse/IGNITE-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-2909: - Assignee: (was: Vladislav Pyatkov) > Checking cache object type in runtime > - > > Key: IGNITE-2909 > URL: https://issues.apache.org/jira/browse/IGNITE-2909 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 1.5.0.final >Reporter: Denis A. Magda >Priority: Major > Labels: community > > In some cases there is necessity to control a type of object that is being > inserted into a cache. > Presently this kind of check is accomplished at compile time only relying > on Java Generics. However it doesn't prevent us from connecting to a > cluster using a non-generic instance of a cache and put any kind of data in > it. This may be not a harmful intention but rather a silly developer mistake. > It's preferable to rely on the cache interceptor based solution: > - user will create a generic interceptor that will accept "typeName" in its > constructor; > - class of this interceptor will be placed in the classpath of all the nodes; > - when a new cache is started statically (Spring cfg) or dynamically this > interceptor can be set with a particular allowed "typeName"; > - when interceptor is invoked allowed typeId (taken from allowed "typeName") > will be compared with a typeID of a key/value being inserted; > - exception has to be thrown if allowed typeId is not equal to a key/value > typeId being inserted. > We need to allow to throw exceptions from interceptor and provide an example > on how perform type validation using interceptors based approach. > Refer to the discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Controlling-type-of-object-inserted-in-IgniteCache-td8128.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14006) Node fails with assertion error during event listener registration
[
https://issues.apache.org/jira/browse/IGNITE-14006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov reassigned IGNITE-14006:
---
Assignee: (was: Mikhail Petrov)
> Node fails with assertion error during event listener registration
> --
>
> Key: IGNITE-14006
> URL: https://issues.apache.org/jira/browse/IGNITE-14006
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Node fails with assertion error during event listener registration from
> client node in case the remote filter class is missing on one or more server
> nodes:
> {code:java}
> [2021-01-17
> 15:49:00,313][ERROR][disco-notifier-worker-#83%continuous.CacheContinuousQueryExternalNodeFilterTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.AssertionError]]
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$LocalRoutineInfo.(GridContinuousProcessor.java:2117)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1447)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:117)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:220)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:211)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:670)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:533)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2635)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2673)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** */
> public class CacheContinuousQueryExternalNodeFilterTest extends
> GridCommonAbstractTest {
> /** */
> private static final String EXT_EVT_FILTER_CLS =
> "org.apache.ignite.tests.p2p.GridEventConsumeFilter";
> /** */
> private static final URL[] URLS;
> static {
> try {
> URLS = new URL[] {new URL(getProperty("p2p.uri.cls.second"))};
> }
> catch (MalformedURLException e) {
> throw new RuntimeException(e);
> }
> }
> /** */
> private final ClassLoader extLdr = getExternalClassLoader();
> /** */
> private final ClassLoader secondExtLdr = new URLClassLoader(URLS,
> U.gridClassLoader());
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setPeerClassLoadingEnabled(false);
> cfg.setFailureHandler(new StopNodeOrHaltFailureHandler());
> if (getTestIgniteInstanceName(0).equals(igniteInstanceName))
> cfg.setClassLoader(secondExtLdr);
> else
> cfg.setClassLoader(extLdr);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrids(2);
> IgniteEx cli = startClientGrid(2);
> Class> rmtFilter =
> (Class>)extLdr
> .loadClass(EXT_EVT_FILTER_CLS);
> try {
> cli.events().remoteListen(null, rmtFilter.newInstance(),
> EVT_CACHE_OBJECT_PUT);
> }
> catch (Throwable ignored) {
> // No-op.
> }
> // waits for all node to handle an error occurred during processing
> of StartRoutineDiscoveryMessage
> U.sleep(3000);
> }
> }
> {code}
> The root cause of described above behavior is:
> First node that can't unmarshall StartRoutineDiscoveryMessage leaves
> GridContinuousHandler property as null and since StartRoutineDiscoveryMessage
> is mutable marshalls it again and sends it to the next node. So every node in
> the ring after that node can't obtain GridContinuo
[jira] [Commented] (IGNITE-14741) Extend coverage of unit tests to public methods of Affinity and Table managers
[ https://issues.apache.org/jira/browse/IGNITE-14741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349082#comment-17349082 ] Alexey Scherbakov commented on IGNITE-14741: [~v.pyatkov] [~alapin] Merged to master #f8eaa3636e1249c89fa3a5feb439c3f6219a84b4 > Extend coverage of unit tests to public methods of Affinity and Table managers > -- > > Key: IGNITE-14741 > URL: https://issues.apache.org/jira/browse/IGNITE-14741 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 1h > Remaining Estimate: 0h > > We have to cover all public method of any components by unit tests. > In this issue we cover Affinity and Table managers by the unit tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14745) Storage API and basic configuration module
[
https://issues.apache.org/jira/browse/IGNITE-14745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-14745:
-
Description:
Introduce basic Storage API described in
[IEP-74|https://cwiki.apache.org/confluence/display/IGNITE/IEP-74+Data+Storage]
in a separate module.
For now Storage API should contain only four basic methods to read, update and
remove keys from Storage and to iterate over available keys:
{code:java}
/** Interface providing methods to read, remove and update keys in storage. */
public interface Storage {
/** Reads a DataRow for a given Key. */
public DataRow read(Key key);
/** Removes DataRow associated with a given Key. */
public void remove(Key key);
/** Executes an update with custom logic implemented by UpdateClosure
interface. */
public update(Key key, UpdateClosure clo);
/** Obtains Iterator over some DataRows in storage. */
public Iterator iterator(/* parameters */).
}
{code}
This simplistic API is based on IgniteCacheOffheapManager from existing code
base of Ignite 2.x. Only essential methods were left for the initial version of
interface but it obviously will be refined during development.
Details about some classes like Key or UpdateClosure are not clear yet and can
be omitted (basic stub classes may be used).
Implement basic configuration that is expected to be common for any Storage
implementation.
was:
Introduce basic Storage API described in
[IEP-74|https://cwiki.apache.org/confluence/display/IGNITE/IEP-74+Data+Storage]
in a separate module.
For now Storage API should contain only four basic methods to read, update and
remove keys from Storage and to iterate over available keys:
{code:java}
/** Interface providing methods to read, remove and update keys in storage. */
public interface Storage {
/** Reads a DataRow for a given Key. */
public DataRow read(Key key);
/** Removes DataRow associated with a given Key. */
public void remove(Key key);
/** Executes an update with custom logic implemented by UpdateClosure
interface. */
public update(Key key, UpdateClosure clo);
/** Obtains Iterator over some DataRows in storage. */
public Iterator iterator(/* parameters */).
}
{code}
Details about some classes like Key or UpdateClosure are not clear yet and can
be omitted (basic stub classes may be used).
Implement basic configuration that is expected to be common for any Storage
implementation.
> Storage API and basic configuration module
> --
>
> Key: IGNITE-14745
> URL: https://issues.apache.org/jira/browse/IGNITE-14745
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Chugunov
>Priority: Major
> Labels: iep-74, ignite-3
> Fix For: 3.0
>
>
> Introduce basic Storage API described in
> [IEP-74|https://cwiki.apache.org/confluence/display/IGNITE/IEP-74+Data+Storage]
> in a separate module.
> For now Storage API should contain only four basic methods to read, update
> and remove keys from Storage and to iterate over available keys:
> {code:java}
> /** Interface providing methods to read, remove and update keys in storage. */
> public interface Storage {
> /** Reads a DataRow for a given Key. */
> public DataRow read(Key key);
>
> /** Removes DataRow associated with a given Key. */
> public void remove(Key key);
>
> /** Executes an update with custom logic implemented by UpdateClosure
> interface. */
> public update(Key key, UpdateClosure clo);
>
> /** Obtains Iterator over some DataRows in storage. */
> public Iterator iterator(/* parameters */).
> }
> {code}
> This simplistic API is based on IgniteCacheOffheapManager from existing code
> base of Ignite 2.x. Only essential methods were left for the initial version
> of interface but it obviously will be refined during development.
> Details about some classes like Key or UpdateClosure are not clear yet and
> can be omitted (basic stub classes may be used).
> Implement basic configuration that is expected to be common for any Storage
> implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14739) Enable a permanent wal recording of transactions states records.
[ https://issues.apache.org/jira/browse/IGNITE-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349040#comment-17349040 ] Stanilovsky Evgeny commented on IGNITE-14739: - !screenshot-1.png! > Enable a permanent wal recording of transactions states records. > > > Key: IGNITE-14739 > URL: https://issues.apache.org/jira/browse/IGNITE-14739 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > After [1] was merged, i suggest to enable transactions states wal logging on > a permanent basis. This will allow to correctly restore transactional states > after partial or whole nodes crash. > [1] https://issues.apache.org/jira/browse/IGNITE-6324 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14739) Enable a permanent wal recording of transactions states records.
[ https://issues.apache.org/jira/browse/IGNITE-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-14739: Attachment: screenshot-1.png > Enable a permanent wal recording of transactions states records. > > > Key: IGNITE-14739 > URL: https://issues.apache.org/jira/browse/IGNITE-14739 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > After [1] was merged, i suggest to enable transactions states wal logging on > a permanent basis. This will allow to correctly restore transactional states > after partial or whole nodes crash. > [1] https://issues.apache.org/jira/browse/IGNITE-6324 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
Alexander Lapin created IGNITE-14756:
Summary: NPE on reading tableConfiguration from
ConfigurationManager within SchemaManager
Key: IGNITE-14756
URL: https://issues.apache.org/jira/browse/IGNITE-14756
Project: Ignite
Issue Type: Bug
Reporter: Alexander Lapin
Assignee: Mirza Aliev
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLo
[jira] [Updated] (IGNITE-14756) NPE on reading tableConfiguration from ConfigurationManager within SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-14756:
-
Description:
Sometimes we get following NPE
{code:java}
SEVERE: Failed to notify configuration listener.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.schema.SchemaManager.initSchemaForTable(SchemaManager.java:173)
at
org.apache.ignite.internal.table.distributed.TableManager.lambda$listenForTableChange$0(TableManager.java:221)
at
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
reactor.core.publisher.MonoToCompletableFuture.onNext(MonoToCompletableFuture.java:63)
at
reactor.core.publisher.SerializedSubscriber.onNext(SerializedSubscriber.java:99)
at
reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onNext(FluxTimeout.java:174)
at
reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:76)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableSubscriber.onNext(FluxFilterFuseable.java:112)
at
reactor.core.publisher.FluxFilterFuseable$FilterFuseableConditionalSubscriber.onNext(FluxFilterFuseable.java:330)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drainRegular(FluxOnBackpressureBuffer.java:261)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.drain(FluxOnBackpressureBuffer.java:225)
at
reactor.core.publisher.FluxOnBackpressureBuffer$BackpressureBufferSubscriber.onNext(FluxOnBackpressureBuffer.java:184)
at
reactor.core.publisher.DirectProcessor$DirectInner.onNext(DirectProcessor.java:333)
at
reactor.core.publisher.DirectProcessor.onNext(DirectProcessor.java:142)
at
reactor.core.publisher.FluxCreate$IgnoreSink.next(FluxCreate.java:618)
at
reactor.core.publisher.FluxCreate$SerializedSink.next(FluxCreate.java:153)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.onMessage(ScaleCubeDirectMarshallerTransport.java:166)
at
org.apache.ignite.network.internal.netty.ConnectionManager.lambda$onMessage$2(ConnectionManager.java:140)
at
java.base/java.util.concurrent.CopyOnWriteArrayList.forEach(CopyOnWriteArrayList.java:803)
at
org.apache.ignite.network.internal.netty.ConnectionManager.onMessage(ConnectionManager.java:140)
at
org.apache.ignite.network.internal.netty.MessageHandler.channelRead(MessageHandler.java:46)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.u
