[jira] [Assigned] (IGNITE-14457) Update Ignite 3 binary build structure
[
https://issues.apache.org/jira/browse/IGNITE-14457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-14457:
-
Assignee: Peter Ivanov
> Update Ignite 3 binary build structure
> --
>
> Key: IGNITE-14457
> URL: https://issues.apache.org/jira/browse/IGNITE-14457
> Project: Ignite
> Issue Type: Task
> Components: build
>Affects Versions: 3.0.0-alpha1
>Reporter: Valentin Kulichenko
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
>
> In the first alpha release, we provided binaries as separate single-file
> downloads for Unix and Windows. This approach doesn't work for two reasons:
> # Website download for the Unix binary doesn't work properly, because the
> file doesn't have an extension. This doesn't seem to have a reasonable
> solution.
> # Binaries that are downloaded from the website are required to include
> {{NOTICE}} and {{LICENSE}} files.
> See IGNITE-13978 and INFRA-21332 for more details.
> As a solution, let's switch to a ZIP file containing the following:
> * {{ignite}} (Unix CLI tool)
> * {{ignite.exe}} (Windows CLI tool)
> * {{NOTICE}}
> * {{LICENSE}}
> * {{README}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14457) Update Ignite 3 binary build structure
Valentin Kulichenko created IGNITE-14457:
Summary: Update Ignite 3 binary build structure
Key: IGNITE-14457
URL: https://issues.apache.org/jira/browse/IGNITE-14457
Project: Ignite
Issue Type: Task
Components: build
Affects Versions: 3.0.0-alpha1
Reporter: Valentin Kulichenko
Fix For: 3.0.0-alpha2
In the first alpha release, we provided binaries as separate single-file
downloads for Unix and Windows. This approach doesn't work for two reasons:
# Website download for the Unix binary doesn't work properly, because the file
doesn't have an extension. This doesn't seem to have a reasonable solution.
# Binaries that are downloaded from the website are required to include
{{NOTICE}} and {{LICENSE}} files.
See IGNITE-13978 and INFRA-21332 for more details.
As a solution, let's switch to a ZIP file containing the following:
* {{ignite}} (Unix CLI tool)
* {{ignite.exe}} (Windows CLI tool)
* {{NOTICE}}
* {{LICENSE}}
* {{README}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14456) Ignite Extensions: change copyrights to 2021
Amelchev Nikita created IGNITE-14456: Summary: Ignite Extensions: change copyrights to 2021 Key: IGNITE-14456 URL: https://issues.apache.org/jira/browse/IGNITE-14456 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita The copyrights must be changed to 2021. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14455) The directory with logs must contain IgniteConfiguration.xml for ducktests.
Sergei Ryzhov created IGNITE-14455: -- Summary: The directory with logs must contain IgniteConfiguration.xml for ducktests. Key: IGNITE-14455 URL: https://issues.apache.org/jira/browse/IGNITE-14455 Project: Ignite Issue Type: Test Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov The directory with logs must contain IgniteConfiguration.xml for ducktests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14417) Document performance-statistics-ext module
[ https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14417: - Fix Version/s: (was: 2.10) 2.11 > Document performance-statistics-ext module > -- > > Key: IGNITE-14417 > URL: https://issues.apache.org/jira/browse/IGNITE-14417 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.10 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.11 > > Time Spent: 4h > Remaining Estimate: 0h > > It's needed to document performance-statistics-ext module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14438) Add README.md files to cli and cli-common modules
[ https://issues.apache.org/jira/browse/IGNITE-14438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14438: - Reviewer: Vyacheslav Koptilin > Add README.md files to cli and cli-common modules > - > > Key: IGNITE-14438 > URL: https://issues.apache.org/jira/browse/IGNITE-14438 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312542#comment-17312542 ] Mikhail Petrov commented on IGNITE-14398: - [~NSAmelchev], [~nsafonov] Thanks a lot for the review! > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312540#comment-17312540 ] Mikhail Petrov commented on IGNITE-14397: - [~NSAmelchev], [~nsafonov] Thanks a lot for the review! > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 6h > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14397: - Ignite Flags: Release Notes Required > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 6h > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14398: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14397: - Fix Version/s: 2.11 > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 6h > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14397: - Ignite Flags: (was: Docs Required,Release Notes Required) > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 6h > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch
[
https://issues.apache.org/jira/browse/IGNITE-13873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-13873:
--
Fix Version/s: (was: 2.10.1)
> Milti-cell transaction changes may be not visible (during some time) after
> the Cellular switch
> --
>
> Key: IGNITE-13873
> URL: https://issues.apache.org/jira/browse/IGNITE-13873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: iep-45
> Fix For: 2.11
>
> Attachments: master (as 2.9) vs improved (as dev) .png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Transactions over some cells may be recovered after the stale data read.
> For example:
> We have 2 cells, the first contains partitions for k1, second for k2.
> Tx with put(k1,v1) and put(k2,v2) started and prepared.
> Then node from the first cell, which is the primary for k1, failed.
> Currently, the second cell (with key2) may finish the cellular switch before
> tx recovered and stale data read is possible.
> Primaries from the {{tx.transactionNodes()}} should be taken into account
> instead of the current logic that awaits for all transactions located on
> nodes who are backups to the failed primary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14454) [Ignite Website] Update for events schedule
Kseniya Romanova created IGNITE-14454: - Summary: [Ignite Website] Update for events schedule Key: IGNITE-14454 URL: https://issues.apache.org/jira/browse/IGNITE-14454 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova @mstkl please update schedule [https://ignite.apache.org/events.html] with events below: *Distributed Java DBs Under the Hood: Components & Interactions Between Them* London Java Community, Val Kulichenko April 7, 2021 During the session, we create a simple (although fully workable) distributed cache in Java, almost from scratch. We use the cache to demonstrate basic CRUD operations, as well as to demonstrate how scalability can be improved by adding resources to the system. Read more=https://www.eventbrite.co.uk/e/distributed-java-databases-under-the-hood-tickets-148903304793 *Why Distributed SQL Is Harder Than It Looks* Highload++, Stan Lukyanov May 18, 2021 In this talk, we'll cover why distributed SQL is needed, how it differs from SQL in traditional databases, what it does well, and what doesn't. Apache Ignite will be used as an example of distributed SQL support. Read more = https://www.highload.ru/spring/2021/abstracts/6686 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14453) Issue with persistence when using JDK15
Emmanuel Wiesenfeld created IGNITE-14453:
Summary: Issue with persistence when using JDK15
Key: IGNITE-14453
URL: https://issues.apache.org/jira/browse/IGNITE-14453
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.10
Environment: Apache Ignite with openJDK-15 (java version 15.0.1)
Reporter: Emmanuel Wiesenfeld
When using the following code:
{code:java}
IgniteConfiguration cfg = new IgniteConfiguration();
//data storage configuration
DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);
cfg.setDataStorageConfiguration(storageCfg);
Ignite ignite = Ignition.start(cfg);{code}
I get this upon startup:
{code:java}
SEVERE: Got exception while starting (will rollback startup routine).
java.lang.NullPointerException: Cannot invoke
"java.lang.reflect.Method.invoke(Object, Object[])" because
"org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl.mappingOffset"
is null
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl.fsync(FileWriteHandleImpl.java:449)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl.fsync(FileWriteHandleImpl.java:418)
at
org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileHandleManagerImpl.flush(FileHandleManagerImpl.java:269)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.flush(FileWriteAheadLogManager.java:934)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.tailPointer(GridCacheDatabaseSharedManager.java:1968)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1908)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1299)
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.start(IgnitionEx.java:663)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
at org.apache.ignite.Ignition.start(Ignition.java:328){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14447) Invalid meta page can be used after index re-creation
[
https://issues.apache.org/jira/browse/IGNITE-14447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312430#comment-17312430
]
Ignite TC Bot commented on IGNITE-14447:
{panel:title=Branch: [pull/8949/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8949/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5942752]]
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
CleanupIndexTreeCheckpointFailoverTest.testCorruptedTree - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5942792buildTypeId=IgniteTests24Java8_RunAll]
> Invalid meta page can be used after index re-creation
> -
>
> Key: IGNITE-14447
> URL: https://issues.apache.org/jira/browse/IGNITE-14447
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider the following scenario:
> * A user creates index "A"
> * Ignite allocates page 0x1234 as the index meta page and writes it to the
> index roots tree
> * Index is populated, query entity is written on disk
> * Checkpoint is triggered and the index pages (including root) are written
> to disk
> * User drops the index
> * The tree is deallocated, the meta page is removed from the roots tree,
> query entity without the index is written to disk. No logical record is
> written for the roots tree.
> * Node crashes without checkpoint being marked
> * Node restarts. Since the query entity does not contain the index "A", the
> index tree is not created
> * User deletes some entries, then attempts to create the index "A" again
> * Since the node did not trigger checkpoint before the crash and no logical
> record was written, the root tree contains obsolete tree with links pointing
> to non-existing data (namely, index "A" still refers to page 0x1234)
> * Depending on allocation pattern and enabled assertions flag, the node will
> either fail with an assertion, or will crash the JVM
> Fundamentally, the issue is caused by inconsistency between index roots tree
> and query entity. Ideally, we should move cache configuration to page memory
> subsystem, but this may be a big change.
> We should check whether writing a logical record on index drop that will run
> the index cleanup on recovery mitigates the issue (in other words, the index
> cleanup persistent task should be triggered even if no checkpoint was marked
> after query entity is persisted).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14452) Add checking of the iptables settings applied.
[ https://issues.apache.org/jira/browse/IGNITE-14452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14452: -- Summary: Add checking of the iptables settings applied. (was: Add cehcking of the iptables settings applied.) > Add checking of the iptables settings applied. > -- > > Key: IGNITE-14452 > URL: https://issues.apache.org/jira/browse/IGNITE-14452 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > Sometimes, we lack settings of iptables for unknows reason. Let's monitor > this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14452) Add cehcking of the iptables settings applied.
Vladimir Steshin created IGNITE-14452: - Summary: Add cehcking of the iptables settings applied. Key: IGNITE-14452 URL: https://issues.apache.org/jira/browse/IGNITE-14452 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin Sometimes, we lack settings of iptables for unknows reason. Let's monitor this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14428: Description: It's needed to refactor metric names to obey the global rule - all of them must start with name of the registry they belongs to. And add corresponding assertion. The purpose of this change is to make all metrics that belongs to one MetricRegistry have the name that obeys mentioned above rule regardless how they were registered. It helps to use a consistent approach to work with all metrics. The following metric names will be changed to obey this rule: JoinedNodes -> io.discovery.JoinedNodes LeftNodes -> io.discovery.LeftNodes FailedNodes -> io.discovery.FailedNodes PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered CommunicationErrors -> io.discovery.CommunicationErrors CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion was: It's needed to refactor metric names to obey the global rule - all of them must start with name of the registry they belongs to. And add corresponding assertion. The purpose of this change is to make all metrics that belongs to one MetricRegistry have the name that obeys mentioned above rule regardless how they were registered. It helps to use a consistent approach to work with all metrics. The following metric names will be changed to obey this rule: JoinedNodes -> io.discovery.JoinedNodes LeftNodes -> io.discovery.LeftNodes FailedNodes -> io.discovery.FailedNodes PendingMessagesRegistered -> io.discovery.JPendingMessagesRegistered CommunicationErrors -> io.discovery.CommunicationErrors CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Time Spent: 3h 20m > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-14428: Description: It's needed to refactor metric names to obey the global rule - all of them must start with name of the registry they belongs to. And add corresponding assertion. The purpose of this change is to make all metrics that belongs to one MetricRegistry have the name that obeys mentioned above rule regardless how they were registered. It helps to use a consistent approach to work with all metrics. The following metric names will be changed to obey this rule: JoinedNodes -> io.discovery.JoinedNodes LeftNodes -> io.discovery.LeftNodes FailedNodes -> io.discovery.FailedNodes PendingMessagesRegistered -> io.discovery.JPendingMessagesRegistered CommunicationErrors -> io.discovery.CommunicationErrors CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion was:It's needed to refactor metric names to obey the global rule - all of them must start with name of the registry they belongs to. And add corresponding assertion. > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Time Spent: 3h 20m > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.JPendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14375) Pending discovery messages can be erroneously send.
[ https://issues.apache.org/jira/browse/IGNITE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312345#comment-17312345 ] Stanilovsky Evgeny commented on IGNITE-14375: - additionally seems it fix [1] too, i found no fail after numerous of TC reruns. [1] https://issues.apache.org/jira/browse/IGNITE-9226 > Pending discovery messages can be erroneously send. > --- > > Key: IGNITE-14375 > URL: https://issues.apache.org/jira/browse/IGNITE-14375 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Due to pending messages logic implementation its possible to process already > outdated _DynamicCacheChangeBatch_ message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14375) Pending discovery messages can be erroneously send.
[ https://issues.apache.org/jira/browse/IGNITE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312322#comment-17312322 ] Stanilovsky Evgeny commented on IGNITE-14375: - Flaky test this branch [1], master [2] [1] https://ci.ignite.apache.org/test/5810373459874129800?currentProjectId=IgniteTests24Java8=IgniteTests24Java8_Cache5=pull%2F8943%2Fhead [2] https://ci.ignite.apache.org/test/5810373459874129800?currentProjectId=IgniteTests24Java8=IgniteTests24Java8_Cache5= > Pending discovery messages can be erroneously send. > --- > > Key: IGNITE-14375 > URL: https://issues.apache.org/jira/browse/IGNITE-14375 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Due to pending messages logic implementation its possible to process already > outdated _DynamicCacheChangeBatch_ message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14375) Pending discovery messages can be erroneously send.
[
https://issues.apache.org/jira/browse/IGNITE-14375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312318#comment-17312318
]
Ignite TC Bot commented on IGNITE-14375:
{panel:title=Branch: [pull/8943/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8943/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5942998buildTypeId=IgniteTests24Java8_RunAll]
> Pending discovery messages can be erroneously send.
> ---
>
> Key: IGNITE-14375
> URL: https://issues.apache.org/jira/browse/IGNITE-14375
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.10
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Due to pending messages logic implementation its possible to process already
> outdated _DynamicCacheChangeBatch_ message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14451) PK becomes corrupted after node restart
Taras Ledkov created IGNITE-14451: - Summary: PK becomes corrupted after node restart Key: IGNITE-14451 URL: https://issues.apache.org/jira/browse/IGNITE-14451 Project: Ignite Issue Type: Bug Reporter: Taras Ledkov Assignee: Taras Ledkov Fix For: 2.11 PK index tree becomes corrupted after node restart in case it was created through SQL API and it's fields order differs from the one in field list. For example: CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY KEY (id2, id1)) - this won't survive restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14162) Python thin gives ambiguous message when using a wrong username/password to connect
[
https://issues.apache.org/jira/browse/IGNITE-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-14162.
---
Resolution: Fixed
> Python thin gives ambiguous message when using a wrong username/password to
> connect
> ---
>
> Key: IGNITE-14162
> URL: https://issues.apache.org/jira/browse/IGNITE-14162
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Affects Versions: python-0.3.4
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: python-0.4.0
>
>
> Starting a server w/authentication, then connecting to it via a python thin
> client w/an incorrect username and password.
> The message/stacktrace is ambiguous leading clients to believe that they've
> connected, and something is amiss w/the server.
> {code:python}client = Client(username='incorrect-user-name',
> password='incorrect-password', use_ssl=False)
> client.connect('127.0.0.1', 10800)
> #client(nodes)
> print("connected to: ".format(client))
> print("cache names: ".format(client.get_cache_names)){code}
> the stacktrace is :
> {code:python}connected to:
> Traceback (most recent call last):
> cache names:
> File "C:/dev/python-thin-client/examples/get_and_put.py", line 30, in
>
> print(client.get_cache_names())
> File "C:\dev\python-thin-client\pyignite\utils.py", line 249, in ste_wrapper
> result = fn(*args, **kwargs)
> File "C:\dev\python-thin-client\pyignite\client.py", line 521, in
> get_cache_names
> return cache_get_names(self.random_node)
> File "C:\dev\python-thin-client\pyignite\utils.py", line 273, in wrapper
> return func(obj, *args, **kwargs)
> File "C:\dev\python-thin-client\pyignite\client.py", line 222, in
> random_node
> raise ReconnectError('Can not reconnect: out of nodes.') from None
> pyignite.exceptions.ReconnectError: Can not reconnect: out of nodes.{code}
> *ReconnectError: Can not reconnect: out of nodes exception*: allows the user
> to make the conclusion that the connection is successful, but something is
> wrong with the server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14450) Add Maximum CDC directory size configuration parameter
Nikolay Izhikov created IGNITE-14450: Summary: Add Maximum CDC directory size configuration parameter Key: IGNITE-14450 URL: https://issues.apache.org/jira/browse/IGNITE-14450 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Currently, without a CDC consumer wal segments in CDC folder will grow infinite. We need to add configuration property to stop CDC process if folder size enlarge exceed some preconfigured size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14450) Add Maximum CDC directory size configuration parameter
[ https://issues.apache.org/jira/browse/IGNITE-14450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-14450: - Labels: IEP-59 (was: ) > Add Maximum CDC directory size configuration parameter > -- > > Key: IGNITE-14450 > URL: https://issues.apache.org/jira/browse/IGNITE-14450 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Currently, without a CDC consumer wal segments in CDC folder will grow > infinite. > We need to add configuration property to stop CDC process if folder size > enlarge exceed some preconfigured size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312268#comment-17312268 ] Nikita Safonov commented on IGNITE-14398: - [~PetrovMikhail] , done! Left several suggestions. > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-14428: - Labels: IEP-35 (was: ) > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Time Spent: 2h > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14449) Add binary meta change event to CDCCosumer
Nikolay Izhikov created IGNITE-14449:
Summary: Add binary meta change event to CDCCosumer
Key: IGNITE-14449
URL: https://issues.apache.org/jira/browse/IGNITE-14449
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Need to provide the way to notify {{CDCConsumer}} about changes in binary meta.
Required to correctly notify subsequent systems about new types that can be
found in change events.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14441: -- Description: Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. was: Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. Now query parameters may be printed in the query plan. > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[ https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312174#comment-17312174 ] Pavel Vinokurov commented on IGNITE-14439: -- [~ilyak] Please review > NPE when accessing clustername before first exchange finished > - > > Key: IGNITE-14439 > URL: https://issues.apache.org/jira/browse/IGNITE-14439 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: Pavel Vinokurov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not > been fixed properly for two reasons. The first is one is that > _GridCacheProcessor.utilityCache_ could be accessed before the first exchange > finished. The second is that it doesn't resolve the original issue, because > _GridServiceProcessor.onKernelStop_ is followed by > _GridCacheProcessor.onKernelStop_, so caches should be already initialized. > Thus that fix should be reverted. > Revering this fix induces the issue related to accessing the utility cache by > getting cluster name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14439) NPE when accessing clustername before first exchange finished
[
https://issues.apache.org/jira/browse/IGNITE-14439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312172#comment-17312172
]
Ignite TC Bot commented on IGNITE-14439:
{panel:title=Branch: [pull/8944/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8944/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5940025]]
* {color:#013220}IgniteCacheTestSuite9:
ClusterNameBeforeActivation.testGetClusterNameBeforeSystemCacheStarted -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5940063buildTypeId=IgniteTests24Java8_RunAll]
> NPE when accessing clustername before first exchange finished
> -
>
> Key: IGNITE-14439
> URL: https://issues.apache.org/jira/browse/IGNITE-14439
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9
>Reporter: Pavel Vinokurov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [IGNITE-11406|https://issues.apache.org/jira/browse/IGNITE-11406] has not
> been fixed properly for two reasons. The first is one is that
> _GridCacheProcessor.utilityCache_ could be accessed before the first exchange
> finished. The second is that it doesn't resolve the original issue, because
> _GridServiceProcessor.onKernelStop_ is followed by
> _GridCacheProcessor.onKernelStop_, so caches should be already initialized.
> Thus that fix should be reverted.
> Revering this fix induces the issue related to accessing the utility cache by
> getting cluster name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
[
https://issues.apache.org/jira/browse/IGNITE-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-14448:
Description:
{code:java}
if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
if (connRequestor != null) {
...
if (isPairedConnection(node, tcpCommSpi))
throw new IgniteSpiException("Inverse connection protocol
doesn't support paired connections");{code}
Turns out this exception is not handled property and connection future is never
done. Then, striped pool threads wait forever on reserveClient() and cluster
grinds to halt.This happens in versions which have communication-via-discovery
and when usePairedConnections=true.
{code:java}
[12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
message to remote node [node=TcpDiscoveryNode
[id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
sockAddrs=HashSet [/127.0.0.1:0,
ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
intOrder=47, lastExchangeTime=1603983940522, loc=false,
ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
[idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
sparkJobStatus=COMPLETED], prevVal=null,
super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
nearFutId=0, flags=near]], connIdx=-1]]
class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
doesn't support paired connections
at
org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
at
org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
at
org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture
{code}
was:
{{if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
if (connRequestor != null) {
...
if (isPairedConnection(node, tcpCommSpi))
throw new IgniteSpiException("Inverse connection protocol
doesn't support paired connections");}}
Turns out this exception is not handled property and connection future is never
done. Then, striped pool threads wait forever on reserveClient() and cluster
grinds to halt.
This happens in versions which have communication-via-discovery and when
usePairedConnections=true.
{{[12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
message to remote node [node=TcpDiscoveryNode
[id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
sockAddrs=HashSet [/127.0.0.1:0,
ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
intOrder=47, lastExchangeTime=1603983940522, loc=false,
ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
[idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
sparkJobStatus=COMPLETED], prevVal=null,
super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
nearFutId=0, flags=near]], connIdx=-1]]
class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
doesn't support paired connections
at
org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
at
[jira] [Created] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
Semyon Danilov created IGNITE-14448:
---
Summary: Failure to connect to node leads to hanging connection
future if paired connections are used
Key: IGNITE-14448
URL: https://issues.apache.org/jira/browse/IGNITE-14448
Project: Ignite
Issue Type: Bug
Components: networking
Affects Versions: 2.10
Reporter: Semyon Danilov
Assignee: Semyon Danilov
{{if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
if (connRequestor != null) {
...
if (isPairedConnection(node, tcpCommSpi))
throw new IgniteSpiException("Inverse connection protocol
doesn't support paired connections");}}
Turns out this exception is not handled property and connection future is never
done. Then, striped pool threads wait forever on reserveClient() and cluster
grinds to halt.
This happens in versions which have communication-via-discovery and when
usePairedConnections=true.
{{[12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
message to remote node [node=TcpDiscoveryNode
[id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
sockAddrs=HashSet [/127.0.0.1:0,
ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
intOrder=47, lastExchangeTime=1603983940522, loc=false,
ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
[idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
sparkJobStatus=COMPLETED], prevVal=null,
super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
nearFutId=0, flags=near]], connIdx=-1]]
class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
doesn't support paired connections
at
org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
at
org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
at
org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13642) Nodes fail when they meet objects of unknown type in metastorage
[
https://issues.apache.org/jira/browse/IGNITE-13642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov resolved IGNITE-13642.
Resolution: Duplicate
> Nodes fail when they meet objects of unknown type in metastorage
>
>
> Key: IGNITE-13642
> URL: https://issues.apache.org/jira/browse/IGNITE-13642
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Denis Mekhanikov
>Priority: Blocker
> Labels: 2.9.1-rc
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] 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=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
> nodeConfiguration().setClientMode(true);
> IgniteKernal ignite = (IgniteKernal)
[jira] [Updated] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14347:
---
Issue Type: Bug (was: Improvement)
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Bug
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] 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=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312119#comment-17312119
]
Ivan Bessonov commented on IGNITE-14347:
[~atri] by the way, I see that you completely copied
https://issues.apache.org/jira/browse/IGNITE-13642 instead of assigning it to
yourself, what was your motivation?
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] 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=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following
[jira] [Updated] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14347:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] 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=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
>
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312116#comment-17312116
]
Ivan Bessonov commented on IGNITE-14347:
[~atri] I'll merge it, thank you for the contribution!
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] 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=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
>
[jira] [Created] (IGNITE-14447) Invalid meta page can be used after index re-creation
Ivan Bessonov created IGNITE-14447: -- Summary: Invalid meta page can be used after index re-creation Key: IGNITE-14447 URL: https://issues.apache.org/jira/browse/IGNITE-14447 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 2.11 Consider the following scenario: * A user creates index "A" * Ignite allocates page 0x1234 as the index meta page and writes it to the index roots tree * Index is populated, query entity is written on disk * Checkpoint is triggered and the index pages (including root) are written to disk * User drops the index * The tree is deallocated, the meta page is removed from the roots tree, query entity without the index is written to disk. No logical record is written for the roots tree. * Node crashes without checkpoint being marked * Node restarts. Since the query entity does not contain the index "A", the index tree is not created * User deletes some entries, then attempts to create the index "A" again * Since the node did not trigger checkpoint before the crash and no logical record was written, the root tree contains obsolete tree with links pointing to non-existing data (namely, index "A" still refers to page 0x1234) * Depending on allocation pattern and enabled assertions flag, the node will either fail with an assertion, or will crash the JVM Fundamentally, the issue is caused by inconsistency between index roots tree and query entity. Ideally, we should move cache configuration to page memory subsystem, but this may be a big change. We should check whether writing a logical record on index drop that will run the index cleanup on recovery mitigates the issue (in other words, the index cleanup persistent task should be triggered even if no checkpoint was marked after query entity is persisted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
