[jira] [Created] (IGNITE-13085) Download page broken link for 2.8.0
Sebb created IGNITE-13085: - Summary: Download page broken link for 2.8.0 Key: IGNITE-13085 URL: https://issues.apache.org/jira/browse/IGNITE-13085 Project: Ignite Issue Type: Bug Reporter: Sebb The download page has broken links for version 2.8.0 It looks like the release was removed from the mirrors without updating the page to point to the archive server. To reduce the likelihood of broken links, it's best to allow some overlap between old and new releases, e.g. - publish new release (2.8.1) to dist.apache.org/release - wait a day or so for mirrors to catch up - update the download page to include the new release (2.8.1) - change the previous release (2.8.0) to link to the archive server - send the announce mail for the new release (2.8.1) - remove the previous release (2.8.0) from dist.apache.org/release This should minimise the chance of a user encountering a broken link. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13074) Thin client: Default compute cluster group should be "server nodes", but currently "all nodes"
[
https://issues.apache.org/jira/browse/IGNITE-13074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118156#comment-17118156
]
Ignite TC Bot commented on IGNITE-13074:
{panel:title=Branch: [pull/7850/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5339788buildTypeId=IgniteTests24Java8_RunAll]
> Thin client: Default compute cluster group should be "server nodes", but
> currently "all nodes"
> --
>
> Key: IGNITE-13074
> URL: https://issues.apache.org/jira/browse/IGNITE-13074
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When executing compute tasks from thin client without specifying cluster
> group, tasks should be executed only on server nodes. But currently client
> nodes are also included.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12625:
---
Description:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
Also, we need to unwrap binaries recursively since all objects inside
collections, arrays and maps become binary objects after
marshaling/unmarshalling (see IGNITE-12468)
Also, we don't know do we really need to deserialize binary objects. If object
was originally binary there is no evidence of this after
marshaling/unmarshaling on server-side. This leads to problems when a binary
object was created for unknown class.
Reproducer:
{code:java}
cache.put(0, client.binary().builder("TestType").setField("test",
"val").build())
cache.get(0){code}
Will throw exception:
{noformat}
class org.apache.ignite.binary.BinaryInvalidTypeException: TestType
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
at
org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
at
org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
To avoid double marshaling we could pass byte array from request content to
cache directly (for example using {{CacheObject}}), but we don't have object
size in thin client protocol, so in any case, we need to traverse the objects.
Also, we don't have the ability to get {{CacheObject}} from the cache now, so
such an approach will only work in one way, for "put" operations, but not for
"get" operations.
was:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
Also, we need to unwrap binaries recursively since all objects inside
collections, arrays and maps become binary objects after
marshaling/unmarshalling (see IGNITE-12468)
Also, we don't know do we really need to deserialize binary objects. If object
was originally binary there is no evidence of this after
marshaling/unmarshaling on server-side. This leads to problems when a binary
object was created for unknown class.
Reproducer:
{code:java}
cache.put(0, client.binary().builder("TestType").setField("test",
"val").build())
cache.get(0){code}
Will throw exception:
{noformat}
class org.apache.ignite.binary.BinaryInvalidTypeException: TestTypeclass
org.apache.ignite.binary.BinaryInvalidTypeException: TestType
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
at
org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
at
org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
at
[jira] [Updated] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12625:
---
Description:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
Also, we need to unwrap binaries recursively since all objects inside
collections, arrays and maps become binary objects after
marshaling/unmarshalling (see IGNITE-12468)
Also, we don't know do we really need to deserialize binary objects. If object
was originally binary there is no evidence of this after
marshaling/unmarshaling on server-side. This leads to problems when a binary
object was created for unknown class.
Reproducer:
{code:java}
cache.put(0, client.binary().builder("TestType").setField("test",
"val").build())
cache.get(0){code}
Will throw exception:
{noformat}
class org.apache.ignite.binary.BinaryInvalidTypeException: TestTypeclass
org.apache.ignite.binary.BinaryInvalidTypeException: TestType
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
at
org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
at
org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
To avoid double marshaling we could pass byte array from request content to
cache directly (for example using {{CacheObject}}), but we don't have object
size in thin client protocol, so in any case, we need to traverse the objects.
Also, we don't have the ability to get {{CacheObject}} from the cache now, so
such an approach will only work in one way, for "put" operations, but not for
"get" operations.
was:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
Also, we need to unwrap binaries recursively since all objects inside
collections, arrays and maps become binary objects after
marshaling/unmarshalling (see IGNITE-12468)
Also, we don't know do we really need to deserialize binary objects. If object
was originally binary there is no evidence of this after
marshaling/unmarshaling on server-side. This leads to problems when a binary
object was created for unknown class.
Reproducer:
{code:java}
cache.put(0, client.binary().builder("TestType").setField("test",
"val").build())
cache.get(0){code}
Will throw exception:
{noformat}
class org.apache.ignite.binary.BinaryInvalidTypeException: TestTypeclass
org.apache.ignite.binary.BinaryInvalidTypeException: TestType
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
at
org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
at
org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
[jira] [Updated] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12625:
---
Description:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
Also, we need to unwrap binaries recursively since all objects inside
collections, arrays and maps become binary objects after
marshaling/unmarshalling (see IGNITE-12468)
Also, we don't know do we really need to deserialize binary objects. If object
was originally binary there is no evidence of this after
marshaling/unmarshaling on server-side. This leads to problems when a binary
object was created for unknown class.
Reproducer:
{code:java}
cache.put(0, client.binary().builder("TestType").setField("test",
"val").build())
cache.get(0){code}
Will throw exception:
{noformat}
class org.apache.ignite.binary.BinaryInvalidTypeException: TestTypeclass
org.apache.ignite.binary.BinaryInvalidTypeException: TestType
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319)
at
org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74)
at
org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558)
at
org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat}
To avoid double marshaling we could pass byte array from request content to
cache directly (for example using {{CacheObject}}), but we don't have object
size in thin client protocol, so in any case, we need to traverse the objects.
Also, we don't have the ability to get {{CacheObject}} from the cache now, so
such an approach will only work in one way, for "put" operations, but not for
"get" operations.
was:
For each thin client cache operation marshaling/unmarshaling of objects
performed twice. For example, cache "put" operation marshal object on the
client-side, then unmarshal object (with keep binaries) on the server-side and
marshal it again before putting it to the cache. It causes some undesirable
effects. For example, references to the same binary object in a collection (
{{new ArrayList(Arrays.asList(person, person))}} ) deserialized as different
objects.
Reproducer:
{code:java}
try (IgniteClient client = startClient()) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
Person person = new Person(0, "name");
cache.put(0, new Object[] {person, person} );
Object[] res = cache.get(0);
assertTrue(res[0] == res[1]);
}{code}
To avoid double marshalling we could pass byte array from request content to
cache directly (for example using {{CacheObject}}), but we don't have object
size in thin client protocol, so in any case, we need to traverse the objects.
Also, we don't have the ability to get {{CacheObject}} from the cache now, so
such an approach will only work in one way, for "put" operations, but not for
"get" operations.
> Thin client: Marshaling/unmarshaling of objects performed twice
> ---
>
> Key: IGNITE-12625
> URL: https://issues.apache.org/jira/browse/IGNITE-12625
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> For each thin client cache operation marshaling/unmarshaling of objects
> performed twice. For example, cache "put" operation marshal object on the
> client-side, then unmarshal object (with keep binaries) on the server-side
> and marshal it again before putting it to the cache. It causes some
> undesirable effects. For example, references to the same binary object in a
> collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized
> as
[jira] [Updated] (IGNITE-12967) Start cluster snapshot from client node
[ https://issues.apache.org/jira/browse/IGNITE-12967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12967: - Release Note: Add support starting snapshot from a client node > Start cluster snapshot from client node > --- > > Key: IGNITE-12967 > URL: https://issues.apache.org/jira/browse/IGNITE-12967 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.9 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Users should be able to start cluster snapshots from client node by sending > compute requests on server node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12978) Cancel snapshot command
[ https://issues.apache.org/jira/browse/IGNITE-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12978: - Ignite Flags: Release Notes Required Release Note: Add canceling snapshot command > Cancel snapshot command > --- > > Key: IGNITE-12978 > URL: https://issues.apache.org/jira/browse/IGNITE-12978 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.9 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Add the ability to cancel snapshot operation through JMX and command line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12967) Start cluster snapshot from client node
[ https://issues.apache.org/jira/browse/IGNITE-12967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12967: - Ignite Flags: Release Notes Required > Start cluster snapshot from client node > --- > > Key: IGNITE-12967 > URL: https://issues.apache.org/jira/browse/IGNITE-12967 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.9 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Users should be able to start cluster snapshots from client node by sending > compute requests on server node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12961) Start snapshot operation via control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12961:
-
Ignite Flags: Release Notes Required
Release Note: Start snapshot from control.sh support
> Start snapshot operation via control.sh
> ---
>
> Key: IGNITE-12961
> URL: https://issues.apache.org/jira/browse/IGNITE-12961
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add the ability to start snapshot operation via {{control.sh}} command line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12961) Start snapshot operation via control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12961:
-
Release Note: Add start snapshot command to control.sh (was: Start
snapshot from control.sh support)
> Start snapshot operation via control.sh
> ---
>
> Key: IGNITE-12961
> URL: https://issues.apache.org/jira/browse/IGNITE-12961
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Add the ability to start snapshot operation via {{control.sh}} command line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11998) Fix DataPageScan for fragmented pages.
[ https://issues.apache.org/jira/browse/IGNITE-11998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11998: - Fix Version/s: (was: 2.9) > Fix DataPageScan for fragmented pages. > -- > > Key: IGNITE-11998 > URL: https://issues.apache.org/jira/browse/IGNITE-11998 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Maxim Muzafarov >Priority: Blocker > > Fragmented pages crash JVM when accessed by DataPageScan scanner/query > optimized scanner. It happens when scanner accesses data in later chunk in > fragmented entry but treats it like the first one, expecting length of the > payload, which is absent and replaced with raw entry data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12978) Cancel snapshot command
[ https://issues.apache.org/jira/browse/IGNITE-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118005#comment-17118005 ] Maxim Muzafarov commented on IGNITE-12978: -- [~NSAmelchev] Thank you for the review. Merged to the master branch. > Cancel snapshot command > --- > > Key: IGNITE-12978 > URL: https://issues.apache.org/jira/browse/IGNITE-12978 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.9 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Add the ability to cancel snapshot operation through JMX and command line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12900) Calcite integration. Use RowHandler to access fields.
[ https://issues.apache.org/jira/browse/IGNITE-12900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-12900. --- Release Note: Done in scope of IGNITE-12715 Resolution: Done > Calcite integration. Use RowHandler to access fields. > - > > Key: IGNITE-12900 > URL: https://issues.apache.org/jira/browse/IGNITE-12900 > Project: Ignite > Issue Type: Task >Reporter: Igor Seliverstov >Priority: Major > > Currently only Object[] can be used as a row because most of execution nodes > require Object[] as a row type. Let's use generic row types with appropriate > RowHandler in execution nodes and compiled expressions to get more > flexibility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11393) Create IgniteLinkTaglet.toString() implementation for Java9+
[ https://issues.apache.org/jira/browse/IGNITE-11393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117926#comment-17117926 ] Aleksey Plekhanov commented on IGNITE-11393: Seems like some of java8 javadoc builds have been broken with the new version of maven-javadoc-plugin. Further investigation needed. > Create IgniteLinkTaglet.toString() implementation for Java9+ > > > Key: IGNITE-11393 > URL: https://issues.apache.org/jira/browse/IGNITE-11393 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Aleksey Plekhanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > New implementation was added according to the new Java API for Javadoc. > But the main method kept empty, need to implement toString() to process > IgniteLink annotation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[
https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117908#comment-17117908
]
Maxim Muzafarov commented on IGNITE-10959:
--
[~Pavlukhin]
Hello, I've found some code changes probably related to the current issue in
GGCE (suppose associated with GG-17432). At first glance, they related to
memory consumption.
I'm not diving deep into those details yet, but can you please share some
details at those fix? I'm going to continue the investigation, should I?
Are there any corner cases left uncovered? I've applied those changes and
checked the attached reproducer {{CacheContinuousQueryMemoryUsageTest}}
locally, it seems it still fails (the \{{backupQ}} remains uncleared).
> Memory leaks in continuous query handlers
> -
>
> Key: IGNITE-10959
> URL: https://issues.apache.org/jira/browse/IGNITE-10959
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Maxim Muzafarov
>Priority: Critical
> Attachments: CacheContinuousQueryMemoryUsageTest.java,
> CacheContinuousQueryMemoryUsageTest.result,
> CacheContinuousQueryMemoryUsageTest2.java,
> Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt,
> Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt,
> Memory_blowup_in_Ignite_CacheContinuousQueryHandler.txt,
> continuousquery_leak_profile.png
>
>
> Continuous query handlers don't clear internal data structures after cache
> events are processed.
> A test, that reproduces the problem, is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12846) Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description in binary release
[
https://issues.apache.org/jira/browse/IGNITE-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12846:
-
Fix Version/s: (was: 2.8.1)
2.9
> Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description
> in binary release
> -
>
> Key: IGNITE-12846
> URL: https://issues.apache.org/jira/browse/IGNITE-12846
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.8
>Reporter: Stepan Pilschikov
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.9
>
>
> apache-ignite-2.8.0-bin/docs/javadoc/overview-summary.html does not contain
> description block for org.apache.ignite.ml.knn.utils.indices
> Actual:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
>
> {code}
> Expected:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
> [Some description]
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12943:
-
Fix Version/s: (was: 2.8.1)
2.9
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Labels: IEP-35
> Fix For: 2.9
>
>
> As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter
> out metrics for a specific exporter instance. For instance, this is how we
> can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add {{Metrics Filtering}} section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> {{MetricExporterSpi.setExportFilter}} JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> {{MetricExporterSpi.setMetricsFilter}} to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10947) CPP: Fix documentation on how to build Ignite C++ on Linux
[
https://issues.apache.org/jira/browse/IGNITE-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-10947:
-
Fix Version/s: (was: 2.8.1)
2.9
> CPP: Fix documentation on how to build Ignite C++ on Linux
> --
>
> Key: IGNITE-10947
> URL: https://issues.apache.org/jira/browse/IGNITE-10947
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, platforms
>Reporter: Igor Sapego
>Priority: Major
> Fix For: 2.9
>
>
> We now have build step (IGNITE-10940) that performs following steps during
> release of the binary package of the Ignite:
> {code}
> # libtoolize
> # aclocal
> # autoheader
> # automake --add-missing
> # autoreconf
> {code}
> So we now should change documentation, that users only need to run following
> commands to build Ignite C++ from binary distribution of Ignite.
> {code}
> # ./configure
> # make
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: FailureDetectionResearch.patch
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: FailureDetectionResearch.patch, WorstCase_log.log,
> WostCase.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolongs node failure detection upto: ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’.
> Suggestions:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it not a constant.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 4) Remove hardcoded sleep of 200ms when marking previous node alive:
> {code:java}
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
>...
>try {
> Thread.sleep(200);
>}
>catch (InterruptedException e) {
> Thread.currentThread().interrupt();
>}
>...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13084) Update BouncyCastle dependency for ignite-aws
[ https://issues.apache.org/jira/browse/IGNITE-13084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13084: -- Labels: security (was: ) > Update BouncyCastle dependency for ignite-aws > - > > Key: IGNITE-13084 > URL: https://issues.apache.org/jira/browse/IGNITE-13084 > Project: Ignite > Issue Type: Task >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: security > > h3. bcprov-ext-jdk15on-1.54 has a lot of known CVE's, so it must be updated > to fix potential security issues -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13084) Update BouncyCastle dependency for ignite-aws
Semyon Danilov created IGNITE-13084: --- Summary: Update BouncyCastle dependency for ignite-aws Key: IGNITE-13084 URL: https://issues.apache.org/jira/browse/IGNITE-13084 Project: Ignite Issue Type: Task Affects Versions: 2.7.6 Reporter: Semyon Danilov Assignee: Semyon Danilov h3. bcprov-ext-jdk15on-1.54 has a lot of known CVE's, so it must be updated to fix potential security issues -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13083) Double adding "onSegmentArchived" observer to SegmentArchivedStorage
Semyon Danilov created IGNITE-13083: --- Summary: Double adding "onSegmentArchived" observer to SegmentArchivedStorage Key: IGNITE-13083 URL: https://issues.apache.org/jira/browse/IGNITE-13083 Project: Ignite Issue Type: Bug Affects Versions: 2.7.6 Reporter: Semyon Danilov Assignee: Semyon Danilov SegmentCompressStorage is build with static method SegmentCompressStorage#buildCompressStorage, where private constructor is called, and the same observer storage::onSegmentArchived is added to same SegmentArchivedStorage in constructor and in the static method. This can cause double call of SegmentCompressStorage#onSegmentArchived. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level
[
https://issues.apache.org/jira/browse/IGNITE-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-5214:
---
Assignee: Ilya Kasnacheev (was: Nikolay Tikhonov)
> ConcurrentModificationException with enable DEBUG log level
> ---
>
> Key: IGNITE-5214
> URL: https://issues.apache.org/jira/browse/IGNITE-5214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nikolay Tikhonov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: IGNITE_5214.patch
>
>
> ConcurrentModificationException with
> org.apache.ignite.continuous.query=DEBUG
> {noformat}
> Unexpected exception during cache update
> java.util.ConcurrentModificationException: null
> at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
> at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
> at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
> at java.util.AbstractMap.toString(AbstractMap.java:554)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
> at
> com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
> at
> com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
> at
>
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117749#comment-17117749
]
Anton Kalashnikov commented on IGNITE-12911:
[~ilyak] can you please clarify a little more your concerns?
>From my point of view, these are two different problems(Corrupt tree vs
>incorrect binary object) on two different levels(primitive problem - incorrect
>length of array vs conceptual problem - incorrect work with deduplicated
>objects) in two different cases.
Honestly, I a little confused about why we can't merge two independent tasks
independently? Maybe I missed something and these tasks are not so independent
as I think. Can you share your thoughts with me, please?
Secondly, it's impossible to fix IGNITE-13080 without this fix because your
test always would fail with CorruptTree
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] 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.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
>
[jira] [Updated] (IGNITE-13039) Get rid of possibility to change final static fields through reflection for test purpose.
[ https://issues.apache.org/jira/browse/IGNITE-13039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13039: -- Fix Version/s: 2.9 > Get rid of possibility to change final static fields through reflection for > test purpose. > - > > Key: IGNITE-13039 > URL: https://issues.apache.org/jira/browse/IGNITE-13039 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Minor > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Rare for tests purpose there is a need for changing some private fields > through reflection. > Changing *static final* fields in this manner could bring more tears, check > for example [1] and [2]. > [1] > https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection > [2] http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-13082:
-
Assignee: Andrey Mashenkov
> Deadlock between topology update and CQ registration.
> -
>
> Key: IGNITE-13082
> URL: https://issues.apache.org/jira/browse/IGNITE-13082
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: deadlock
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Relevant stack traces:Relevant stack traces:
>
> {code:java}
> "sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on
> condition [0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfc138298> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.lang.Thread.run(Thread.java:748)
> {code}
>
> {code:java}
> "disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on
> condition [0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfbde5f30> (a
>
[jira] [Commented] (IGNITE-12359) Migrate RocketMQ module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-12359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117720#comment-17117720 ] Ilya Kasnacheev commented on IGNITE-12359: -- We still have a mention of it in assembly/libs/README.txt - I think we should remove it alongside with some others. I'm not sure where this file goes to. Otherwise, LGTM. > Migrate RocketMQ module to ignite-extensions > > > Key: IGNITE-12359 > URL: https://issues.apache.org/jira/browse/IGNITE-12359 > Project: Ignite > Issue Type: Sub-task > Components: streaming >Affects Versions: 2.8 >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Migrate RocketMQ module to ignite-extensions > [https://github.com/apache/ignite-extensions] > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Fix Version/s: 2.9
> Deadlock between topology update and CQ registration.
> -
>
> Key: IGNITE-13082
> URL: https://issues.apache.org/jira/browse/IGNITE-13082
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Relevant stack traces:Relevant stack traces:
>
> {code:java}
> "sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on
> condition [0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfc138298> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.lang.Thread.run(Thread.java:748)
> {code}
>
> {code:java}
> "disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on
> condition [0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfbde5f30> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
>
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Deadlock between topology update and CQ registration.
> -
>
> Key: IGNITE-13082
> URL: https://issues.apache.org/jira/browse/IGNITE-13082
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Relevant stack traces:Relevant stack traces:
>
> {code:java}
> "sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on
> condition [0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfc138298> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.lang.Thread.run(Thread.java:748)
> {code}
>
> {code:java}
> "disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on
> condition [0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfbde5f30> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
>
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Labels: deadlock (was: )
> Deadlock between topology update and CQ registration.
> -
>
> Key: IGNITE-13082
> URL: https://issues.apache.org/jira/browse/IGNITE-13082
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: deadlock
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Relevant stack traces:Relevant stack traces:
>
> {code:java}
> "sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on
> condition [0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfc138298> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.lang.Thread.run(Thread.java:748)
> {code}
>
> {code:java}
> "disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on
> condition [0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfbde5f30> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
>
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Affects Version/s: 2.7
> Deadlock between topology update and CQ registration.
> -
>
> Key: IGNITE-13082
> URL: https://issues.apache.org/jira/browse/IGNITE-13082
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Relevant stack traces:Relevant stack traces:
>
> {code:java}
> "sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on
> condition [0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfc138298> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.lang.Thread.run(Thread.java:748)
> {code}
>
> {code:java}
> "disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
> #85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on
> condition [0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
> sun.misc.Unsafe.park(Native Method) - parking to wait for
> <0xfbde5f30> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
>
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Description:
Relevant stack traces:Relevant stack traces:
{code:java}
"sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on condition
[0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfc138298>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
"disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on condition
[0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfbde5f30>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localUpdateCounters(GridDhtPartitionTopologyImpl.java:2810)
at
[jira] [Updated] (IGNITE-13082) Deadlock between topology update and CQ registration.
[
https://issues.apache.org/jira/browse/IGNITE-13082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-13082:
--
Description:
Relevant stack traces:Relevant stack traces:
{code:java}
"sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on condition
[0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfc138298>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
"disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on condition
[0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfbde5f30>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localUpdateCounters(GridDhtPartitionTopologyImpl.java:2810)
at
[jira] [Comment Edited] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117713#comment-17117713
]
Alexey Kukushkin edited comment on IGNITE-12823 at 5/27/20, 12:13 PM:
--
[~ptupitsyn], the fix looks almost OK, just need to take care about "keep
binary" mode for both the Java and .NET services. I added comments in the pull
request.
was (Author: kukushal):
[~ptupitsyn], the fix looks almost OK, just need to take care about "keep
binary" mode for both the Java and .NET services.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117713#comment-17117713
]
Alexey Kukushkin commented on IGNITE-12823:
---
[~ptupitsyn], the fix look almost OK, just need to take case about "keep
binary" mode for both the Java and .NET services.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13082) Deadlock between topology update and CQ registration.
Andrey Mashenkov created IGNITE-13082:
-
Summary: Deadlock between topology update and CQ registration.
Key: IGNITE-13082
URL: https://issues.apache.org/jira/browse/IGNITE-13082
Project: Ignite
Issue Type: Task
Reporter: Andrey Mashenkov
Relevant stack traces:Relevant stack traces:
{code}"sys-stripe-0-#65483%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85739 prio=5 os_prio=0 tid=0x7fda80139800 nid=0x5618 waiting on condition
[0x7fdc018e8000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfc138298>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockListenerReadLock(GridCacheMapEntry.java:5032)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2262)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2574)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2034)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1854)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3239)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:139)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:273)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:268)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1626)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1246)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:142)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1137)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:50)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)\{code}
{code}"disco-notifier-worker-#65517%cache.BinaryMetadataRegistrationInsideEntryProcessorTest0%"
#85777 prio=5 os_prio=0 tid=0x7fda800a9800 nid=0x5639 waiting on condition
[0x7fdc006d9000] java.lang.Thread.State: WAITING (parking) at
sun.misc.Unsafe.park(Native Method) - parking to wait for <0xfbde5f30>
(a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
at
[jira] [Comment Edited] (IGNITE-12823) .NET: Service method with user type array parameter can't be found
[
https://issues.apache.org/jira/browse/IGNITE-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117713#comment-17117713
]
Alexey Kukushkin edited comment on IGNITE-12823 at 5/27/20, 12:12 PM:
--
[~ptupitsyn], the fix looks almost OK, just need to take care about "keep
binary" mode for both the Java and .NET services.
was (Author: kukushal):
[~ptupitsyn], the fix look almost OK, just need to take case about "keep
binary" mode for both the Java and .NET services.
> .NET: Service method with user type array parameter can't be found
> --
>
> Key: IGNITE-12823
> URL: https://issues.apache.org/jira/browse/IGNITE-12823
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-12823-vs-2.8.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *+Setup+*
> * Ignite Java service with a method having an array of user types as a
> parameters, for example, caclulate(Parameter[] params)
> *+Actions+*
> * .NET client calls the Ignite Java service, for example,
> ignite.GetServices().GetServiceProxy().calculate(new[] \{new
> Parameter()});
> *+Expected+*
> * The service method is called
> *+Actual+*
> * Exception "Could not find proxy method 'calculate' in class ICalculator"
> *+Workaround+*
> * Replace array of user types with array of objects in the service methods
> signatures, for example, caclulate(Object[] params)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117711#comment-17117711
]
Ilya Kasnacheev commented on IGNITE-12911:
--
However, we may now disallow putting keys (or values) into cache which have
non-zero offset. This will work while we are working on proper fixes. Are you
interested in preparing such fix?
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] 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.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:401)
> at
>
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117708#comment-17117708
]
Ilya Kasnacheev commented on IGNITE-12911:
--
[~akalashnikov] I think we should fix IGNITE-13080 first then merge this fix. I
don't think we should merge code that has known issues.
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] 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.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:401)
> at
>
[jira] [Updated] (IGNITE-13081) RestProcessor can hang during shutdown on start if discovery SPI failed
[ https://issues.apache.org/jira/browse/IGNITE-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-13081: Description: If rest processor receives CACHE_GET or CACHE_PUT operations during node startup and node failed to startup properly (for example, because Discovery SPI failed), node will hang forever on shutdown waiting for grid rest workers to finish GET/PUT operations > RestProcessor can hang during shutdown on start if discovery SPI failed > --- > > Key: IGNITE-13081 > URL: https://issues.apache.org/jira/browse/IGNITE-13081 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > > If rest processor receives CACHE_GET or CACHE_PUT operations during node > startup and node failed to startup properly (for example, because Discovery > SPI failed), node will hang forever on shutdown waiting for grid rest workers > to finish GET/PUT operations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13081) RestProcessor can hang during shutdown on start if discovery SPI failed
[ https://issues.apache.org/jira/browse/IGNITE-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-13081: Affects Version/s: 2.7.6 > RestProcessor can hang during shutdown on start if discovery SPI failed > --- > > Key: IGNITE-13081 > URL: https://issues.apache.org/jira/browse/IGNITE-13081 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13081) RestProcessor can hang during shutdown on start if discovery SPI failed
Semyon Danilov created IGNITE-13081: --- Summary: RestProcessor can hang during shutdown on start if discovery SPI failed Key: IGNITE-13081 URL: https://issues.apache.org/jira/browse/IGNITE-13081 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov Assignee: Semyon Danilov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability.
[ https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13014: -- Attachment: WorstCase_log.log > Remove double checking of node availability. > - > > Key: IGNITE-13014 > URL: https://issues.apache.org/jira/browse/IGNITE-13014 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Attachments: WorstCase_log.log, WostCase.txt > > > Proposal: > Do not check failed node second time. Double node checking prolongs node > failure detection and gives no additional benefits. There are mesh and > hardcoded values in this routine. > For the present, we have double checking of node availability. Let's imagine > node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks > Node 3 to establish permanent connection instead of node 2. Node 3 may try to > check node 2 too. Or may not. > Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL + > 2 * IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: WostCase.txt
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WorstCase_log.log, WostCase.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolongs node failure detection upto: ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’.
> Suggestions:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it not a constant.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 4) Remove hardcoded sleep of 200ms when marking previous node alive:
> {code:java}
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
>...
>try {
> Thread.sleep(200);
>}
>catch (InterruptedException e) {
> Thread.currentThread().interrupt();
>}
>...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Attachment: WorstCase_log.log
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WorstCase_log.log, WostCase.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolongs node failure detection upto: ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’.
> Suggestions:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it not a constant.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false; // Make any error mean lost connection.
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should rely on actual failure
> detection timeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
> timeout of failure detection.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 4) Remove hardcoded sleep of 200ms when marking previous node alive:
> {code:java}
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
>...
>try {
> Thread.sleep(200);
>}
>catch (InterruptedException e) {
> Thread.currentThread().interrupt();
>}
>...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix several drawbacks in the backward checking of failed node. They
prolongs node failure detection upto: ServerImpl.CON_CHECK_INTERVAL + 2 *
IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’.
Suggestions:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100); // Make it not a constant.
...
}
{code}
2) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; // Make any error mean lost connection.
}
return false;
}
{code}
3) Maximal interval to check previous node should rely on actual failure
detection timeout:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; // Here should be a
timeout of failure detection.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
4) Remove hardcoded sleep of 200ms when marking previous node alive:
{code:java}
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
...
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
...
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
3) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param like failureDetectionTimeout:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout?
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
4) Remove hardcoded thread sleep of 200ms when marking previous node alive:
{code:java}
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
...
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix several drawbacks in the backward checking of failed node. They
> prolongs node failure detection upto: ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’.
> Suggestions:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100); // Make it not a constant.
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress
[jira] [Updated] (IGNITE-13068) SQL: use cache.localSize instead of index scan to calculate row count statistic
[ https://issues.apache.org/jira/browse/IGNITE-13068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13068: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > SQL: use cache.localSize instead of index scan to calculate row count > statistic > > > Key: IGNITE-13068 > URL: https://issues.apache.org/jira/browse/IGNITE-13068 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > The scan of index is slow on big data set on setup where disc i/o requires > warm up. > This is the reason that restarting the node can take a long time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability.
[
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13014:
--
Description:
Proposal:
Do not check failed node second time. Double node checking prolongs node
failure detection and gives no additional benefits. There are mesh and
hardcoded values in this routine.
For the present, we have double checking of node availability. Let's imagine
node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks
Node 3 to establish permanent connection instead of node 2. Node 3 may try to
check node 2 too. Or may not.
Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL + 2
* IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
was:
For the present, we have double checking of node availability. This prolongs
node failure detection and gives no additional benefits. There are mesh and
hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Node 3 may try to check node 2 too. Or may not.
Proposal:
Do not check failed node second time. Keep failure detection within expected
timeouts (IgniteConfiguration.failureDetectionTimeout).
Drawbacks:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
{code}
If ‘ok == true’ node 3 checks node 2.
3) Several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}
Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
4) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
Summary: Remove double checking of node availability. (was: Remove
double checking of node availability. Fix hardcoded values.)
> Remove double checking of node availability.
> -
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WostCase.txt
>
>
> Proposal:
> Do not check failed node second time. Double node checking prolongs node
> failure detection and gives no additional benefits. There are mesh and
> hardcoded values in this routine.
> For the present, we have double checking of node availability. Let's imagine
> node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks
> Node 3 to establish permanent connection instead of node 2. Node 3 may try to
> check node 2 too. Or may not.
> Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL +
> 2 * IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
3) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param like failureDetectionTimeout:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout?
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
4) Remove hardcoded thread sleep of 200ms when marking previous node alive:
{code:java}
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive(){
...
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
3) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param like failureDetectionTimeout:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout?
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
> 3) Maximal interval to check previous node should be reconsidered. It should
> rely on configurable param like failureDetectionTimeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a
[jira] [Resolved] (IGNITE-13018) Get rid of duplicated checking of failed node.
[ https://issues.apache.org/jira/browse/IGNITE-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-13018. --- Resolution: Duplicate Duplicates IGNITE-13014. > Get rid of duplicated checking of failed node. > -- > > Key: IGNITE-13018 > URL: https://issues.apache.org/jira/browse/IGNITE-13018 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Failed node checking should be simplified to one step: ping node (send a > message) from previous one in the ring and wait for response within > IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we > should consider it failed. Extra steps of connection checking may seriously > delay failure detection, bring confusion and weird behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13012:
--
Description:
Node-to-next-node connection checking has several drawbacks which go together.
We should fix the following :
1) Make connection check interval half of actual failure detection timeout.
Current value is a constant:
{code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
2) Make connection check interval rely on common time of any last sent message.
Current ping is bound to own time:
{code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
This is weird because any discovery message check connection. And
TpcDiscoveryConnectionCheckMessage is just an addition when message queue is
empty for a long time.
3) Remove additional, randomly appearing and quickened connection checking.
Once we do #1, this will become even more useless.
Despite TCP discovery has a period of connection checking (see #1), it may send
ping before this period exhausts. This premature node ping relies on the time
of any sent or even received message. Imagine: if node 2 receives no message
from node 1 within some time, it decides to do extra ping node 3 not waiting
for regular ping. Such behavior makes confusion and gives no benefits.
See {code:java}ServerImpl.RingMessageWorker.failureThresholdReached{code}
4) Do not worry user with “Node disconnected” when everything is OK. Once we do
#1, this will become even more useless. Fixing #3 also fixes this issue.
If #3 happens, node writes in the log on INFO: “Local node seems to be
disconnected from topology …” whereas it is not actually disconnected at all.
User can see this unexpected and worrying message if he typed
IgniteConfiguration.failureDetectionTimeout < 500ms.
was:
Node-to-next-node connection checking has several drawbacks which go together.
We should fix the following :
1) First thing firts, make connection check interval predictable and dependable
on the failureDetectionTimeout or similar params. Current value is a constant:
{code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
2) Make connection check interval rely on common time of any last sent message.
Current ping is bound to own time:
{code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
This is weird because any discovery message does actually check connection. And
TpDiscoveryConnectionCheckMessage is just an addition when message queue is
empty for a long time.
3) Remove additional, randomly appearing quickened connection checking. Once
we do #1, this will become even more useless.
Despite we have a period of connection checking (see #1), we can also send ping
before the period exhausts. This premature node ping relies on the time of any
sent or even received message. Imagine: if node 2 receives no message from node
1 within some time, it decides to do extra ping node 3 not waiting for regular
ping. This happens quite randomly. Such behavior makes confusion and gives no
benefits.
4) Do not worry user with “Node disconnected” when everything is OK. Once we do
#1, this will become even more useless.
If #3 happens, node writes in the log on INFO: “Local node seems to be
disconnected from topology …” whereas it is not actually disconnected at all.
User can see this unexpected and worrying message if he typed
failureDetectionTimeout < 500ms.
> Make node connection checking rely on the configuration. Simplify node ping
> routine.
>
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Node-to-next-node connection checking has several drawbacks which go
> together. We should fix the following :
> 1) Make connection check interval half of actual failure detection timeout.
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 2) Make connection check interval rely on common time of any last sent
> message. Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection. And
> TpcDiscoveryConnectionCheckMessage is just an addition when message queue is
> empty for a long time.
> 3) Remove additional, randomly appearing and quickened connection checking.
> Once we do #1, this will become even more useless.
> Despite TCP discovery has a period of connection checking (see #1), it may
> send ping before this period exhausts. This premature node ping relies on
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117633#comment-17117633
]
Anton Kalashnikov commented on IGNITE-12911:
[~ilyak] thanks for your test. In fact, it showed us a big problem which I
described with details right here -
https://issues.apache.org/jira/browse/IGNITE-13080.
But as you can see it is different problems. So I suggest to ignore your test
with the link of new ticket and merge my changes as is.
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Anton Kalashnikov
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] 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.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2016)
> at
>
[jira] [Updated] (IGNITE-13080) Incorrect hash calculation for binaryObject in case of deduplication
[
https://issues.apache.org/jira/browse/IGNITE-13080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov updated IGNITE-13080:
---
Description:
Lets suppose we have two follows classes(Implimentation of SubKey doesn't
matter here):
{noformat}
public static class Key {
private SubKey subKey;
}
public static class Value {
private SubKey subKey;
private Key key;
}
{noformat}
If subKey would be same in Key and Value, and we try to do follows things:
{noformat}
SubKey subKey = new SubKey();
Key key = new Key(subKey);
Value value = new Value(subKey, key);
cache.put(key, value);
assert cache.size() == 1; //true
BinaryObject keyAsBinaryObject = cache.get(key).field("key");
cache.put(keyAsBinaryObject, value); // cache.size shuld be 1 but it would be 2
assert cache.size() == 1; //false because right now we have to different key
which is wrong
{noformat}
We get two different record instead of one.
Reason:
When we put raw class Key to cache ignite convert it to binary object(literally
to a byte array), and then calculate the hash over this byte array and store it
to this object.
When we put the raw class Value, the same thing happens, but since we have two
references to the same object (subKey) inside Value, deduplication occurs. This
means that the first time we meet an object, we save it as it is and remember
its location, and then if we meet the same object again instead of saving all
their bytes as is, we mark this place as HANDLE and record only the offset at
which we can find the saved object.
After that, we try to receive some object(Key) from BinaryObject of Value as a
result we don't have a new BinaryObject with a new byte array but instead, we
have BinaryObject with same byte array and with offset which shows us where we
can find the requested value(Key). And when we try to store this object to
cache, ignite does it incorrectly - first of all, byte array contains HANDLE
mark with offset instead of real bytes of the inner object what is already
wrong but more than it we also calculate hash incorrectly.
Problem:
Right now, Ignite isn't able to store BinaryObject with contains HANDLE. And as
I understand, it's not so easy to fix. Maybe it makes sense just explicitly
forbid to work with BinaryObject such described above but of course, it is
discussable.
Workaround:
we can change the order of field in Value, like this:
{noformat}
public static class Value {
private Key key;
private SubKey subKey;
}
{noformat}
After that subKey would be inlined inside of key and subKey inside of Value
would be represented as HANDLE.
Also we can rebuild the object such that:
{noformat}
keyAsBinaryObject.toBuilder().build();
{noformat}
During the this procedure all HANDLE would be restored to real objects.
Test which represents this case -
org.apache.ignite.internal.processors.cache.IgniteCachePutKeyAttachedBinaryObjectTest#testKeyRefersToSubkeyInValue(After
https://issues.apache.org/jira/browse/IGNITE-12911 would be resolved).
was:
Lets suppose we have two follows classes(Implimentation of SubKey doesn't
matter here):
{noformat}
public static class Key {
private SubKey subKey;
}
public static class Value {
private SubKey subKey;
private Key key;
}
{noformat}
If subKey would be same in Key and Value, and we try to do follows things:
{noformat}
SubKey subKey = new SubKey();
Key key = new Key(subKey);
Value value = new Value(subKey, key);
cache.put(key, value);
assert cache.size() == 1; //true
BinaryObject keyAsBinaryObject = cache.get(key).field("key");
cache.put(keyAsBinaryObject, value); // cache.size shuld be 1 but it would be 2
assert cache.size() == 1; //false because right now we have to different key
which is wrong
{noformat}
We get two different record instead of one.
Reason:
When we put raw class Key to cache ignite convert it to binary object(literally
to a byte array), and then calculate the hash over this byte array and store it
to this object.
When we put the raw class Value, the same thing happens, but since we have two
references to the same object (subKey) inside Value, deduplication occurs. This
means that the first time we meet an object, we save it as it is and remember
its location, and then if we meet the same object again instead of saving all
their bytes as is, we mark this place as HANDLE and record only the offset at
which we can find the saved object.
After that, we try to receive some object(Key) from BinaryObject of Value as a
result we don't have a new BinaryObject with a new byte array but instead, we
have BinaryObject with same byte array and with offset which shows us where we
can find the requested value(Key). And when we try to store this object to
cache, ignite does it incorrectly - first of all, byte array contains HANDLE
mark with offset instead of real bytes of the inner
[jira] [Created] (IGNITE-13080) Incorrect hash calculation for binaryObject in case of deduplication
Anton Kalashnikov created IGNITE-13080:
--
Summary: Incorrect hash calculation for binaryObject in case of
deduplication
Key: IGNITE-13080
URL: https://issues.apache.org/jira/browse/IGNITE-13080
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Anton Kalashnikov
Lets suppose we have two follows classes(Implimentation of SubKey doesn't
matter here):
{noformat}
public static class Key {
private SubKey subKey;
}
public static class Value {
private SubKey subKey;
private Key key;
}
{noformat}
If subKey would be same in Key and Value, and we try to do follows things:
{noformat}
SubKey subKey = new SubKey();
Key key = new Key(subKey);
Value value = new Value(subKey, key);
cache.put(key, value);
assert cache.size() == 1; //true
BinaryObject keyAsBinaryObject = cache.get(key).field("key");
cache.put(keyAsBinaryObject, value); // cache.size shuld be 1 but it would be 2
assert cache.size() == 1; //false because right now we have to different key
which is wrong
{noformat}
We get two different record instead of one.
Reason:
When we put raw class Key to cache ignite convert it to binary object(literally
to a byte array), and then calculate the hash over this byte array and store it
to this object.
When we put the raw class Value, the same thing happens, but since we have two
references to the same object (subKey) inside Value, deduplication occurs. This
means that the first time we meet an object, we save it as it is and remember
its location, and then if we meet the same object again instead of saving all
their bytes as is, we mark this place as HANDLE and record only the offset at
which we can find the saved object.
After that, we try to receive some object(Key) from BinaryObject of Value as a
result we don't have a new BinaryObject with a new byte array but instead, we
have BinaryObject with same byte array and with offset which shows us where we
can find the requested value(Key). And when we try to store this object to
cache, ignite does it incorrectly - first of all, byte array contains HANDLE
mark with offset instead of real bytes of the inner object what is already
wrong but more than it we also calculate hash incorrectly.
Problem:
Right now, Ignite isn't able to store BinaryObject with contains HANDLE. And as
I understand, it's not so easy to fix. Maybe it makes sense just explicitly
forbid to work with BinaryObject such described above but of course, it is
discussable.
Workaround:
we can change the order of field in Value, like this:
{noformat}
public static class Value {
private Key key;
private SubKey subKey;
}
{noformat}
After that subKey would be inlined inside of key and subKey inside of Value
would be represented as HANDLE.
Also we can rebuild the object such that:
{noformat}
keyAsBinaryObject.toBuilder().build();
{noformat}
During the this procedure all HANDLE would be restored to real objects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12978) Cancel snapshot command
[
https://issues.apache.org/jira/browse/IGNITE-12978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117612#comment-17117612
]
Ignite TC Bot commented on IGNITE-12978:
{panel:title=Branch: [pull/7827/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5341227buildTypeId=IgniteTests24Java8_RunAll]
> Cancel snapshot command
> ---
>
> Key: IGNITE-12978
> URL: https://issues.apache.org/jira/browse/IGNITE-12978
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add the ability to cancel snapshot operation through JMX and command line.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117534#comment-17117534 ] Maksim Timonin commented on IGNITE-13051: - Discussed with [~gvvinblade], additional checks are required. > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13068) SQL: use cache.localSize instead of index scan to calculate row count statistic
[ https://issues.apache.org/jira/browse/IGNITE-13068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117532#comment-17117532 ] Roman Kondakov commented on IGNITE-13068: - [~tledkov-gridgain] patch looks good to me. > SQL: use cache.localSize instead of index scan to calculate row count > statistic > > > Key: IGNITE-13068 > URL: https://issues.apache.org/jira/browse/IGNITE-13068 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > The scan of index is slow on big data set on setup where disc i/o requires > warm up. > This is the reason that restarting the node can take a long time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117499#comment-17117499 ] Maksim Timonin edited comment on IGNITE-13051 at 5/27/20, 8:26 AM: --- [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2] without applying AttributeNodeFilter; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## the cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## the cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while cache registration process? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] was (Author: timonin.maksim): [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## the cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## the cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while cache registration process? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117499#comment-17117499 ] Maksim Timonin edited comment on IGNITE-13051 at 5/27/20, 8:24 AM: --- [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## the cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## the cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while cache registration process? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] was (Author: timonin.maksim): [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## the cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## the cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority:
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117499#comment-17117499 ] Maksim Timonin edited comment on IGNITE-13051 at 5/27/20, 8:22 AM: --- [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] was (Author: timonin.maksim): [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in **CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For:
[jira] [Comment Edited] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117499#comment-17117499 ] Maksim Timonin edited comment on IGNITE-13051 at 5/27/20, 8:22 AM: --- [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## the cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## the cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] was (Author: timonin.maksim): [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix
[jira] [Commented] (IGNITE-13051) Optimized affinity switch on baseline node left is broken for client topology and MVCC
[ https://issues.apache.org/jira/browse/IGNITE-13051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117499#comment-17117499 ] Maksim Timonin commented on IGNITE-13051: - [~ascherbakov] ok, thanks for the clarification. [~gvvinblade] hi! could you please check my fix suggestion in PR [GitHub Pull Request #7852|https://github.com/apache/ignite/pull/7852]. Is it a right place to fix? My logic is: # By documentation [1] mvccEnabled is true whether at least one cache with mvcc *registered*; # Caches are *registered* in **CachesRegistry [2]; # MVCC flag set to true for new caches in next cases: ## preProcessCacheConfiguration: while dynamic starting cache; ## preProcessCacheConfiguration: adding cache from configuration; ## starting cache after triggering GlobalState to active. # This bug describes a case: ## the cache is started on other nodes in MVCC mode; ## cache would not be started on the node0 as it filtered by AttributeNodeFilter; ## cache is not added to configuration for the node0 IgniteConfiguration; ## so it leads that cache is registered on the node0, but not started and the MVCC flag is not set. It leads to inconsistency of cache mode on different nodes. So I found a place to handle those nodes ([PR fix|https://github.com/apache/ignite/pull/7852]), it already contains a handle _initQueryStructuresForNotStartedCache._ So it looks like a right place to add the MVCC handle there. But there are some questions: # Is it valid to use _validateCacheConfiguration_ because by docs [3] it validates caches before *start* but the cache won't be started? # If MVCC enabled for registered caches, maybe it's better to check the MVCC configuration while registration? [1] [MvccProcessorImpl#L216|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessorImpl.java#L216] [2] [CachesRegistry.java#L52|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CachesRegistry.java#L52] [3] [MvccProcessor.java#L211|https://github.com/apache/ignite/blob/ignite-2.8.1/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/mvcc/MvccProcessor.java#L211] > Optimized affinity switch on baseline node left is broken for client topology > and MVCC > -- > > Key: IGNITE-13051 > URL: https://issues.apache.org/jira/browse/IGNITE-13051 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Maksim Timonin >Priority: Critical > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > If a node contains only client cache topology with MVCC enabled, PME will > hang after changes introduced in IGNITE-12617. > Reproduced by > CachePartitionLossWithRestartsTest.testPartitionLossDetectionOnClientTopology[0 > false false -1] and enabled MVCC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13068) SQL: use cache.localSize instead of index scan to calculate row count statistic
[
https://issues.apache.org/jira/browse/IGNITE-13068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117479#comment-17117479
]
Ignite TC Bot commented on IGNITE-13068:
{panel:title=Branch: [pull/7842/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5339007buildTypeId=IgniteTests24Java8_RunAll]
> SQL: use cache.localSize instead of index scan to calculate row count
> statistic
>
>
> Key: IGNITE-13068
> URL: https://issues.apache.org/jira/browse/IGNITE-13068
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The scan of index is slow on big data set on setup where disc i/o requires
> warm up.
> This is the reason that restarting the node can take a long time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13032) Fix flacky OptimizedMarshallerPooledSelfTest.
[
https://issues.apache.org/jira/browse/IGNITE-13032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117477#comment-17117477
]
Konstantin Orlov commented on IGNITE-13032:
---
[~amashenkov], LGTM
> Fix flacky OptimizedMarshallerPooledSelfTest.
> -
>
> Key: IGNITE-13032
> URL: https://issues.apache.org/jira/browse/IGNITE-13032
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are two flaky tests in the test case:
> {{OptimizedMarshallerPooledSelfTest#testEvents}} and
> {{OptimizedMarshallerPooledSelfTest#testServices}}. The tests timeout, the
> reason is the following assertion:
> {noformat}
> [00:39:14]W: [org.gridgain:ignite-core] java.lang.AssertionError
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectStreamRegistry.closeOut(OptimizedObjectStreamRegistry.java:120)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:209)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10658)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10722)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsFullMessage.partitionSizes(GridDhtPartitionsFullMessage.java:360)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.createPartitionsFullMessage(GridCachePartitionExchangeManager.java:1543)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.createPartitionsFullMessage(GridCachePartitionExchangeManager.java:1442)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createPartitionsMessage(GridDhtPartitionsExchangeFuture.java:2116){noformat}
> Looks like the assertion fails because we attempt to return a stream to the
> pool which does not belong to it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13032) Fix flacky OptimizedMarshallerPooledSelfTest.
[
https://issues.apache.org/jira/browse/IGNITE-13032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117473#comment-17117473
]
Yury Gerzhedovich commented on IGNITE-13032:
[~amashenkov], LGTM
> Fix flacky OptimizedMarshallerPooledSelfTest.
> -
>
> Key: IGNITE-13032
> URL: https://issues.apache.org/jira/browse/IGNITE-13032
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.7
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are two flaky tests in the test case:
> {{OptimizedMarshallerPooledSelfTest#testEvents}} and
> {{OptimizedMarshallerPooledSelfTest#testServices}}. The tests timeout, the
> reason is the following assertion:
> {noformat}
> [00:39:14]W: [org.gridgain:ignite-core] java.lang.AssertionError
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectStreamRegistry.closeOut(OptimizedObjectStreamRegistry.java:120)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.marshal0(OptimizedMarshaller.java:209)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10658)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10722)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsFullMessage.partitionSizes(GridDhtPartitionsFullMessage.java:360)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.createPartitionsFullMessage(GridCachePartitionExchangeManager.java:1543)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.createPartitionsFullMessage(GridCachePartitionExchangeManager.java:1442)
> [00:39:14]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createPartitionsMessage(GridDhtPartitionsExchangeFuture.java:2116){noformat}
> Looks like the assertion fails because we attempt to return a stream to the
> pool which does not belong to it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
