[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12824:
--
Description:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to
keep the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to disable this conversion. This prevents
loosing the {{DateTime.Kind}} property of UTC dates. {{UtcDate}} set to true
implies the existing behavior: Ignite gets UTC dates and throws a "Date must be
in UTC" exception on an attempt to write a Local date. The {{UtcDate}} flag is
false by default.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite instead of having every Ignite.NET application
implementing it.
+*References*+
* [Dev-List
Discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Interoperable-Ignite-NET-Dates-td49946.html]
* IEP-TBD
was:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to
keep the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to disable this conversion. This prevents
loosing the {{DateTime.Kind}} property of UTC dates. {{UtcDate}} set to true
implies the existing behavior: Ignite gets UTC dates and throws a "Date must be
in UTC" exception on an attempt to write a Local date. The {{UtcDate}} flag is
false by default.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite
[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12824:
--
Description:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to
keep the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to disable this conversion. This prevents
loosing the {{DateTime.Kind}} property of UTC dates. {{UtcDate}} set to true
implies the existing behavior: Ignite gets UTC dates and throws a "Date must be
in UTC" exception on an attempt to write a Local date. The {{UtcDate}} flag is
false by default.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite instead of having every Ignite.NET application
implementing it.
was:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to
keep the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to control the deserialization behavior to
prevent loosing the {{DateTime.Kind}} property of UTC dates.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite instead of having every Ignite.NET application
implementing it.
> Interoperable Ignite.NET Dates
> --
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>
[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12824:
--
Description:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to
keep the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Solution+*
# Always write .NET dates as portable Ignite dates: get rid of the
{{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers this
behavior.
Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
seems a useful case.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
{{BinaryReflectiveSerializer}} to control the deserialization behavior to
prevent loosing the {{DateTime.Kind}} property of UTC dates.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truly portable.
*+The Benefits+*
# Portable dates is a more frequent use-case than storing time zone info for
every date in Ignite. This becomes default behavior and the developers do not
need to always explicitly configure it.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite instead of having every Ignite.NET application
implementing it.
was:
*+The Problem+*
Presently .NET API writes dates as composite Ignite objects. Only .NET clients
can read such dates: any other client (JDBC, Java, etc) does not understand it
without custom deserialization.
It is still possible to configure .NET serialization to write dates as Ignite
dates - see [DateTime Serialization
note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
But then Ignite accepts only UTC dates, requiring the application developers
to convert local dates to UTC dates and back. This task is not trivial:
[DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
uses calendars different from Java (and the .NET calendars are the invalid
ones - especially for pre-1990 dates).
The motivation for the current default behavior was probably the desire to keep
the Time Zone information: Ignite dates do not store time zones.
In our experience interoperability is more important than storing time zone
info.
*+The Proposal+*
# Always write .NET dates as portable Ignite dates: get rid of the
BinaryReflectiveSerializer.ForceTimestamp flag that currently triggers this
behavior.
* We could still keep the ForceTimestamp flag if saving .NET dates as
transparent objects seems a useful case. We do not think it is useful.
# Automatically convert Local dates to UTC and back *inside* Ignite.NET.
* In this case we lose the DateTime.Kind of UTC dates: we write a UTC date but
we would read a Local date since Ignite would always convert UTC to Local when
reading.
We could add a UtcDate date flag to QuerySqlFieldAttribute and
BinaryReflectiveSerializer to control the deserialization behavior if keeping
dates in UTC format use case seems important.
# Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time
uses Java calendars making the conversion truely portable.
*+The Benefits+*
# We think portable dates are much more important than storing time zone info.
Why do we store time zones for every date on the server anyway? Time zone is
client-side info.
# Simpler application code: no more manual configuration to trigger the
portable behavior.
# Non-trivial code to make the truly portable UTC<->Local conversion is
implemented once inside Ignite instead of having every Ignite.NET application
implementing it.
> Interoperable Ignite.NET Dates
> --
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project:
[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12824:
--
Attachment: (was: ignite-12824-vs-2.8.patch)
> Interoperable Ignite.NET Dates
> --
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: .NET, ignite-3, sbcf
> Fix For: 3.0
>
>
> *+The Problem+*
> Presently .NET API writes dates as composite Ignite objects. Only .NET
> clients can read such dates: any other client (JDBC, Java, etc) does not
> understand it without custom deserialization.
>
> It is still possible to configure .NET serialization to write dates as
> Ignite dates - see [DateTime Serialization
> note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
> But then Ignite accepts only UTC dates, requiring the application developers
> to convert local dates to UTC dates and back. This task is not trivial:
> [DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
> uses calendars different from Java (and the .NET calendars are the invalid
> ones - especially for pre-1990 dates).
>
> The motivation for the current default behavior was probably the desire to
> keep the Time Zone information: Ignite dates do not store time zones.
>
> In our experience interoperability is more important than storing time zone
> info.
>
> *+The Solution+*
> # Always write .NET dates as portable Ignite dates: get rid of the
> {{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers
> this behavior.
> Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
> seems a useful case.
> # Automatically convert Local dates to UTC and back *inside* Ignite.NET.
> Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
> {{BinaryReflectiveSerializer}} to control the deserialization behavior to
> prevent loosing the {{DateTime.Kind}} property of UTC dates.
> # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda
> time uses Java calendars making the conversion truly portable.
>
> *+The Benefits+*
> # Portable dates is a more frequent use-case than storing time zone info for
> every date in Ignite. This becomes default behavior and the developers do not
> need to always explicitly configure it.
> # Non-trivial code to make the truly portable UTC<->Local conversion is
> implemented once inside Ignite instead of having every Ignite.NET application
> implementing it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12824) Interoperable Ignite.NET Dates
[
https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225675#comment-17225675
]
Alexey Kukushkin commented on IGNITE-12824:
---
Extended the ticket scope. Removed the old patch, working on the new one.
> Interoperable Ignite.NET Dates
> --
>
> Key: IGNITE-12824
> URL: https://issues.apache.org/jira/browse/IGNITE-12824
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: .NET, ignite-3, sbcf
> Fix For: 3.0
>
>
> *+The Problem+*
> Presently .NET API writes dates as composite Ignite objects. Only .NET
> clients can read such dates: any other client (JDBC, Java, etc) does not
> understand it without custom deserialization.
>
> It is still possible to configure .NET serialization to write dates as
> Ignite dates - see [DateTime Serialization
> note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility].
> But then Ignite accepts only UTC dates, requiring the application developers
> to convert local dates to UTC dates and back. This task is not trivial:
> [DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1]
> uses calendars different from Java (and the .NET calendars are the invalid
> ones - especially for pre-1990 dates).
>
> The motivation for the current default behavior was probably the desire to
> keep the Time Zone information: Ignite dates do not store time zones.
>
> In our experience interoperability is more important than storing time zone
> info.
>
> *+The Solution+*
> # Always write .NET dates as portable Ignite dates: get rid of the
> {{BinaryReflectiveSerializer.ForceTimestamp}} flag that currently triggers
> this behavior.
> Keep the {{ForceTimestamp}} flag if saving .NET dates as transparent objects
> seems a useful case.
> # Automatically convert Local dates to UTC and back *inside* Ignite.NET.
> Add a {{UtcDate}} date flag to {{QuerySqlFieldAttribute}} and
> {{BinaryReflectiveSerializer}} to control the deserialization behavior to
> prevent loosing the {{DateTime.Kind}} property of UTC dates.
> # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda
> time uses Java calendars making the conversion truly portable.
>
> *+The Benefits+*
> # Portable dates is a more frequent use-case than storing time zone info for
> every date in Ignite. This becomes default behavior and the developers do not
> need to always explicitly configure it.
> # Non-trivial code to make the truly portable UTC<->Local conversion is
> implemented once inside Ignite instead of having every Ignite.NET application
> implementing it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[ https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12824: -- Description: *+The Problem+* Presently .NET API writes dates as composite Ignite objects. Only .NET clients can read such dates: any other client (JDBC, Java, etc) does not understand it without custom deserialization. It is still possible to configure .NET serialization to write dates as Ignite dates - see [DateTime Serialization note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility]. But then Ignite accepts only UTC dates, requiring the application developers to convert local dates to UTC dates and back. This task is not trivial: [DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1] uses calendars different from Java (and the .NET calendars are the invalid ones - especially for pre-1990 dates). The motivation for the current default behavior was probably the desire to keep the Time Zone information: Ignite dates do not store time zones. In our experience interoperability is more important than storing time zone info. *+The Proposal+* # Always write .NET dates as portable Ignite dates: get rid of the BinaryReflectiveSerializer.ForceTimestamp flag that currently triggers this behavior. * We could still keep the ForceTimestamp flag if saving .NET dates as transparent objects seems a useful case. We do not think it is useful. # Automatically convert Local dates to UTC and back *inside* Ignite.NET. * In this case we lose the DateTime.Kind of UTC dates: we write a UTC date but we would read a Local date since Ignite would always convert UTC to Local when reading. We could add a UtcDate date flag to QuerySqlFieldAttribute and BinaryReflectiveSerializer to control the deserialization behavior if keeping dates in UTC format use case seems important. # Use [NodaTime|https://nodatime.org/] for UTC<->Local conversions. Noda time uses Java calendars making the conversion truely portable. *+The Benefits+* # We think portable dates are much more important than storing time zone info. Why do we store time zones for every date on the server anyway? Time zone is client-side info. # Simpler application code: no more manual configuration to trigger the portable behavior. # Non-trivial code to make the truly portable UTC<->Local conversion is implemented once inside Ignite instead of having every Ignite.NET application implementing it. was:Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects by default. This could be changed by either setting BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding "QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain users using this functionality and all of them are confused with this default behavior. Let's see if we can change the default behavior to save .NET dates in interoperable Ignite TIMESTAMP format, converting them to UTC dates inside BinaryReflectiveSerializer so that the users do not have to do the ToUniversalDate conversion manually. > Interoperable Ignite.NET Dates > -- > > Key: IGNITE-12824 > URL: https://issues.apache.org/jira/browse/IGNITE-12824 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12824-vs-2.8.patch > > > *+The Problem+* > Presently .NET API writes dates as composite Ignite objects. Only .NET > clients can read such dates: any other client (JDBC, Java, etc) does not > understand it without custom deserialization. > > It is still possible to configure .NET serialization to write dates as Ignite > dates - see [DateTime Serialization > note|https://ignite.apache.org/docs/latest/net-specific/net-platform-interoperability#types-compatibility]. > But then Ignite accepts only UTC dates, requiring the application developers > to convert local dates to UTC dates and back. This task is not trivial: > [DateTime.ToUniversalTime|https://docs.microsoft.com/en-us/dotnet/api/system.datetime.touniversaltime?view=netcore-3.1] > uses calendars different from Java (and the .NET calendars are the invalid > ones - especially for pre-1990 dates). > > The motivation for the current default behavior was probably the desire to > keep the Time Zone information: Ignite dates do not store time zones. > > In our experience interoperability is more important than storing time zone > info. > > *+The Proposal+* > # Always write .NET dates as portable Ignite dates: get rid of the >
[jira] [Updated] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12825: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin closed IGNITE-12825. - > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin resolved IGNITE-12825. --- Release Note: Will be fixed by IGNITE-12824 Resolution: Duplicate Will be fixed by [IGNITE-12824 Interoperable Ignite.NET Dates|https://issues.apache.org/jira/browse/IGNITE-12824] > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin reassigned IGNITE-12825: - Assignee: Alexey Kukushkin (was: Pavel Tupitsyn) > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12824) Interoperable Ignite.NET Dates
[ https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-12824: -- Summary: Interoperable Ignite.NET Dates (was: .NET: Write DateTime in interoperable format by default) > Interoperable Ignite.NET Dates > -- > > Key: IGNITE-12824 > URL: https://issues.apache.org/jira/browse/IGNITE-12824 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12824-vs-2.8.patch > > > Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects by > default. This could be changed by either setting > BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding > "QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain > users using this functionality and all of them are confused with this default > behavior. Let's see if we can change the default behavior to save .NET dates > in interoperable Ignite TIMESTAMP format, converting them to UTC dates inside > BinaryReflectiveSerializer so that the users do not have to do the > ToUniversalDate conversion manually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12824) .NET: Write DateTime in interoperable format by default
[ https://issues.apache.org/jira/browse/IGNITE-12824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin reassigned IGNITE-12824: - Assignee: Alexey Kukushkin (was: Pavel Tupitsyn) > .NET: Write DateTime in interoperable format by default > --- > > Key: IGNITE-12824 > URL: https://issues.apache.org/jira/browse/IGNITE-12824 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Labels: .NET, ignite-3, sbcf > Fix For: 3.0 > > Attachments: ignite-12824-vs-2.8.patch > > > Presently BinaryReflectiveSerializer serialises .NET dates Ignite objects by > default. This could be changed by either setting > BinaryReflectiveSerializer.ForceTimestamp property to "true" or adding > "QuerySqlField" attribute to Date fields. I have multiple Ignite/GridGain > users using this functionality and all of them are confused with this default > behavior. Let's see if we can change the default behavior to save .NET dates > in interoperable Ignite TIMESTAMP format, converting them to UTC dates inside > BinaryReflectiveSerializer so that the users do not have to do the > ToUniversalDate conversion manually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13589) Ignite Docs: the docs root must open the latest version
[ https://issues.apache.org/jira/browse/IGNITE-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda reassigned IGNITE-13589: --- Assignee: Mauricio Stekl > Ignite Docs: the docs root must open the latest version > --- > > Key: IGNITE-13589 > URL: https://issues.apache.org/jira/browse/IGNITE-13589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Mauricio Stekl >Priority: Critical > Labels: new-docs > Fix For: 2.10 > > > If you open the default docs URL (https://ignite.apache.org/docs/), you'll > see a structure of a directory on the server. > That default URL needs to redirect to https://ignite.apache.org/docs/latest/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-13589) Ignite Docs: the docs root must open the latest version
[ https://issues.apache.org/jira/browse/IGNITE-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda closed IGNITE-13589. --- > Ignite Docs: the docs root must open the latest version > --- > > Key: IGNITE-13589 > URL: https://issues.apache.org/jira/browse/IGNITE-13589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Mauricio Stekl >Priority: Critical > Labels: new-docs > Fix For: 2.10 > > > If you open the default docs URL (https://ignite.apache.org/docs/), you'll > see a structure of a directory on the server. > That default URL needs to redirect to https://ignite.apache.org/docs/latest/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13589) Ignite Docs: the docs root must open the latest version
[ https://issues.apache.org/jira/browse/IGNITE-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda resolved IGNITE-13589. - Resolution: Fixed > Ignite Docs: the docs root must open the latest version > --- > > Key: IGNITE-13589 > URL: https://issues.apache.org/jira/browse/IGNITE-13589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Mauricio Stekl >Priority: Critical > Labels: new-docs > Fix For: 2.10 > > > If you open the default docs URL (https://ignite.apache.org/docs/), you'll > see a structure of a directory on the server. > That default URL needs to redirect to https://ignite.apache.org/docs/latest/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13589) Ignite Docs: the docs root must open the latest version
[ https://issues.apache.org/jira/browse/IGNITE-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225639#comment-17225639 ] Denis A. Magda commented on IGNITE-13589: - [~mstekl], thanks for looking into this! The change is live. > Ignite Docs: the docs root must open the latest version > --- > > Key: IGNITE-13589 > URL: https://issues.apache.org/jira/browse/IGNITE-13589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Priority: Critical > Labels: new-docs > Fix For: 2.10 > > > If you open the default docs URL (https://ignite.apache.org/docs/), you'll > see a structure of a directory on the server. > That default URL needs to redirect to https://ignite.apache.org/docs/latest/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
[ https://issues.apache.org/jira/browse/IGNITE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda closed IGNITE-13652. --- > Wrong GitHub link for Apache Ignite With Spring Data/Example > > > Key: IGNITE-13652 > URL: https://issues.apache.org/jira/browse/IGNITE-13652 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.9 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: docuentation > Time Spent: 40m > Remaining Estimate: 0h > > Wrong GihHub link in > https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
[ https://issues.apache.org/jira/browse/IGNITE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225638#comment-17225638 ] Denis A. Magda commented on IGNITE-13652: - [~garus.d.g], no worries, thanks for catching and fixing the issue! The changes are live on the website > Wrong GitHub link for Apache Ignite With Spring Data/Example > > > Key: IGNITE-13652 > URL: https://issues.apache.org/jira/browse/IGNITE-13652 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.9 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: docuentation > Time Spent: 40m > Remaining Estimate: 0h > > Wrong GihHub link in > https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13615) .NET: Fix failover-related documentation
[ https://issues.apache.org/jira/browse/IGNITE-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225637#comment-17225637 ] Denis A. Magda commented on IGNITE-13615: - [~ptupitsyn], thanks for taking over this task. I published the change to the website: https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients > .NET: Fix failover-related documentation > > > Key: IGNITE-13615 > URL: https://issues.apache.org/jira/browse/IGNITE-13615 > Project: Ignite > Issue Type: Improvement > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > The following page incorrectly mentions that failover is not supported in > .NET Thin Client > https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients > * Fix this and review the feature table - transactions are also not specified > correctly > * Make sure to update 2.9-docs branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13589) Ignite Docs: the docs root must open the latest version
[ https://issues.apache.org/jira/browse/IGNITE-13589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225634#comment-17225634 ] Mauricio Stekl commented on IGNITE-13589: - [~dmagda], I sent a PR to fix this one. Here: https://github.com/apache/ignite-website/pull/39 > Ignite Docs: the docs root must open the latest version > --- > > Key: IGNITE-13589 > URL: https://issues.apache.org/jira/browse/IGNITE-13589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Priority: Critical > Labels: new-docs > Fix For: 2.10 > > > If you open the default docs URL (https://ignite.apache.org/docs/), you'll > see a structure of a directory on the server. > That default URL needs to redirect to https://ignite.apache.org/docs/latest/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225362#comment-17225362 ] Vladimir Steshin edited comment on IGNITE-13206 at 11/3/20, 6:39 PM: - [~dmagda], wrong. It might be confusion with addresses to detect other nodes to connect the ring in the IP Finder. The ticket is exactly about Discovery SPI. The problem remains as described: several IP addresses node uses (not search) can prolog detection of node failure. We also should represent this issue in the documentation. Users often do not set IP address of node and allow automatically pick up all available addresses. This is lack of configuration I think. All node addresses of any node are saved and sent with node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. Better doc is about localAddress. was (Author: vladsz83): [~dmagda], wrong. It might be confusion with addresses to detect other nodes to connect the ring in the IP Finder. The ticket is exactly about Discovery SPI. The problem remains as described: several IP addresses node uses (not search) can prolog detection of node failure. Similar ticket is IGNITE-13205. But it warns in Javadoc and logs. We also should represent this issue in the documentation. Users often do not set IP address of node and allow automatically pick up all available addresses. This is lack of configuration I think. All node addresses of any node are saved and sent with node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. Better doc is about localAddress. > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225362#comment-17225362 ] Vladimir Steshin edited comment on IGNITE-13206 at 11/3/20, 6:28 PM: - [~dmagda], wrong. It might be confusion with addresses to detect other nodes to connect the ring in the IP Finder. The ticket is exactly about Discovery SPI. The problem remains as described: several IP addresses node uses (not search) can prolog detection of node failure. Similar ticket is IGNITE-13205. But it warns in Javadoc and logs. We also should represent this issue in the documentation. Users often do not set IP address of node and allow automatically pick up all available addresses. This is lack of configuration I think. All node addresses of any node are saved and sent with node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. Better doc is about localAddress. was (Author: vladsz83): [~dmagda], wrong. This ticket is about Discovery SPI. And the problem is exactly as described: several IP addresses node uses (not search) can prolog detection of node failure. Similar ticket is IGNITE-13205. But it warns in Javadoc and logs. We also should represent this issue in the documentation. Users often do not set IP address of node and allow automatically pick up all available addresses. This is lack of configuration I think. All node addresses of any node are saved sent with node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. But I got your idea. Better doc is about localAddress. > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225362#comment-17225362 ] Vladimir Steshin edited comment on IGNITE-13206 at 11/3/20, 6:21 PM: - [~dmagda], wrong. This ticket is about Discovery SPI. And the problem is exactly as described: several IP addresses node uses (not search) can prolog detection of node failure. Similar ticket is IGNITE-13205. But it warns in Javadoc and logs. We also should represent this issue in the documentation. Users often do not set IP address of node and allow automatically pick up all available addresses. This is lack of configuration I think. All node addresses of any node are saved sent with node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. But I got your idea. Better doc is about localAddress. was (Author: vladsz83): [~dmagda], no you are wrong. This ticket is about Discovery SPI. And the problem is exactly as described: several IP addresses can prolog detection of node failure. Similar ticket is IGNITE-13205. But it warns in Javadoc and logs. We also should represent this issue in the documentation. Users often do not set IP addresses and allow automatically pick up all available addresses. All node addresses of any node are saved sent as node info. If node doesn't respond, other node will try to connect to other provided address of not responding node. > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Description: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). was:The nullmap is currently always written to the tuple layout. However, it can be fully omitted for schemas where all columns are non-null - this saves both a little space and runtime for offsets folding. > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Summary: Upgrade nullmap to null-defaults map (was: Omit nullmap where possible) > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout. However, it can > be fully omitted for schemas where all columns are non-null - this saves both > a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Omit nullmap where possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Labels: iep-54 ignite-3 (was: ) > Omit nullmap where possible > --- > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout. However, it can > be fully omitted for schemas where all columns are non-null - this saves both > a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13669) Implement date native types
[ https://issues.apache.org/jira/browse/IGNITE-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13669: -- Labels: iep-54 ignite-3 (was: ) > Implement date native types > > > Key: IGNITE-13669 > URL: https://issues.apache.org/jira/browse/IGNITE-13669 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > Besides the types themselves, it may be beneficial to provide date/time field > extraction methods so that they can be read without object creation. The > layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13667) Add schema columns relocation table to map from user order to system order
[
https://issues.apache.org/jira/browse/IGNITE-13667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13667:
--
Labels: iep-54 ignite-3 (was: )
> Add schema columns relocation table to map from user order to system order
> --
>
> Key: IGNITE-13667
> URL: https://issues.apache.org/jira/browse/IGNITE-13667
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: iep-54, ignite-3
>
> When a schema is defined, the key chunk columns and value chunk columns are
> sorted so that fixlen columns go first and varlen columns go second, so the
> sorted column order differs from the order of the user-defined columns.
> We need to add a simple relocation table which is a permutation of indices
> {{[0..n)}}, so that an internal column order for user index {{n}} is
> {{relocationTbl[n]}}.
> NB: the tuple assembler will still need to access the internal sorted order
> for proper tuple assembly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13668:
--
Labels: iep-54 ignite-3 (was: )
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: iep-54, ignite-3
>
> Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
> the varlong style (so that Number(4) can be mapped to integer and Number(8)
> can be mapped to long during (de)serialization). Larger numbers can be
> represented as {{BigInteger}}. The Number( n ) is a varlen type, so it will
> take two additional bytes in the varlen table, so types smaller than
> Number(2) are better represented by {{byte}} and {{short}} types as their
> fixlen encoding takes exactly 1 and 2 bytes respectively.
> Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13670) Omit nullmap where possible
Alexey Goncharuk created IGNITE-13670: - Summary: Omit nullmap where possible Key: IGNITE-13670 URL: https://issues.apache.org/jira/browse/IGNITE-13670 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk The nullmap is currently always written to the tuple layout. However, it can be fully omitted for schemas where all columns are non-null - this saves both a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13669) Implement date native types
Alexey Goncharuk created IGNITE-13669: - Summary: Implement date native types Key: IGNITE-13669 URL: https://issues.apache.org/jira/browse/IGNITE-13669 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Besides the types themselves, it may be beneficial to provide date/time field extraction methods so that they can be read without object creation. The layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13668) Implement Number(n) and Decimal native types
Alexey Goncharuk created IGNITE-13668:
-
Summary: Implement Number(n) and Decimal native types
Key: IGNITE-13668
URL: https://issues.apache.org/jira/browse/IGNITE-13668
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Number(n) is an {{n}}-bytes two-complement integer signed value encoded in the
varlong style (so that Number(4) can be mapped to integer and Number(8) can be
mapped to long during (de)serialization). Larger numbers can be represented as
{{BigInteger}}. The Number(n) is a varlen type, so it will take two additional
bytes in the varlen table, so types smaller than Number(2) are better
represented by {{byte}} and {{short}} types as their fixlen encoding takes
exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13668:
--
Description:
Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
the varlong style (so that Number(4) can be mapped to integer and Number(8) can
be mapped to long during (de)serialization). Larger numbers can be represented
as {{BigInteger}}. The Number( n ) is a varlen type, so it will take two
additional bytes in the varlen table, so types smaller than Number(2) are
better represented by {{byte}} and {{short}} types as their fixlen encoding
takes exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
was:
Number(n) is an {{n}}-bytes two-complement integer signed value encoded in the
varlong style (so that Number(4) can be mapped to integer and Number(8) can be
mapped to long during (de)serialization). Larger numbers can be represented as
{{BigInteger}}. The Number(n) is a varlen type, so it will take two additional
bytes in the varlen table, so types smaller than Number(2) are better
represented by {{byte}} and {{short}} types as their fixlen encoding takes
exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
> the varlong style (so that Number(4) can be mapped to integer and Number(8)
> can be mapped to long during (de)serialization). Larger numbers can be
> represented as {{BigInteger}}. The Number( n ) is a varlen type, so it will
> take two additional bytes in the varlen table, so types smaller than
> Number(2) are better represented by {{byte}} and {{short}} types as their
> fixlen encoding takes exactly 1 and 2 bytes respectively.
> Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13667) Add schema columns relocation table to map from user order to system order
Alexey Goncharuk created IGNITE-13667:
-
Summary: Add schema columns relocation table to map from user
order to system order
Key: IGNITE-13667
URL: https://issues.apache.org/jira/browse/IGNITE-13667
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
When a schema is defined, the key chunk columns and value chunk columns are
sorted so that fixlen columns go first and varlen columns go second, so the
sorted column order differs from the order of the user-defined columns.
We need to add a simple relocation table which is a permutation of indices
{{[0..n)}}, so that an internal column order for user index {{n}} is
{{relocationTbl[n]}}.
NB: the tuple assembler will still need to access the internal sorted order for
proper tuple assembly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13618) Provide generated and reflection-based class (de)serializers
[ https://issues.apache.org/jira/browse/IGNITE-13618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13618: -- Issue Type: Improvement (was: Task) > Provide generated and reflection-based class (de)serializers > > > Key: IGNITE-13618 > URL: https://issues.apache.org/jira/browse/IGNITE-13618 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13617) Provide an initial implementation for assembling/reading tuples for a given schema
[ https://issues.apache.org/jira/browse/IGNITE-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13617: -- Parent: (was: IGNITE-13616) Issue Type: Improvement (was: Sub-task) > Provide an initial implementation for assembling/reading tuples for a given > schema > -- > > Key: IGNITE-13617 > URL: https://issues.apache.org/jira/browse/IGNITE-13617 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13666) Disable socket linger in discovery ducktape test.
[ https://issues.apache.org/jira/browse/IGNITE-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13666: -- Priority: Minor (was: Major) > Disable socket linger in discovery ducktape test. > - > > Key: IGNITE-13666 > URL: https://issues.apache.org/jira/browse/IGNITE-13666 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > soLinger might be disabled to fasten the discovery tests. Additionally, we > could reduce failureDetectionTimeout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem appear in ability of node to run with several addresses. By default, all available addresses are assigned to node. Connection to a node is established to one of its address (first non-loopback). But if lost, other addresses are attempted to reconnect to sequentially. was: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem appear in ability of node to run with several addresses. By default, all addresses are assigned to node. Connection to a node is established to one of its address (first non-loopback). But if lost, other addresses are attempted to reconnect to sequentially. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Minor > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem appear in ability of node to run with several addresses. By > default, all available addresses are assigned to node. Connection to a node is > established to one of its address (first non-loopback). But if lost, other > addresses are attempted to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13666) Disable socket linger in discovery ducktape test.
Vladimir Steshin created IGNITE-13666: - Summary: Disable socket linger in discovery ducktape test. Key: IGNITE-13666 URL: https://issues.apache.org/jira/browse/IGNITE-13666 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin soLinger might be disabled to fasten the discovery tests. Additionally, we could reduce failureDetectionTimeout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem appear in ability of node to run with several addresses. By default, all addresses are assigned to node. Connection to a node is established to one of its address (first non-loopback). But if lost, other addresses are attempted to reconnect to sequentially. was: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is ability of node to run on several addresses. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Minor > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem appear in ability of node to run with several addresses. By > default, all addresses are assigned to node. Connection to a node is > established to one of its address (first non-loopback). But if lost, other > addresses are attempted to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Priority: Minor (was: Major) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Minor > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem is ability of node to run on several addresses. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Affects Version/s: 2.6 2.7.6 2.8.1 > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem is ability of node to run on several addresses. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13663: - Assignee: Denis A. Magda (was: Vladimir Steshin) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem is ability of node to run on several addresses. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13564) Improve SYSTEM_WORKER_BLOCKED reporting.
[
https://issues.apache.org/jira/browse/IGNITE-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13564:
--
Description:
Currently, reporting of system thread blocking has major drawbacks.
1. As system worker blocking is detected by another thread, due to
implementation, failure handler receives not full information about problem. In
{{FailureContext}} we have only two fields -- {{type}} and {{err}}. Throwable
{{err}} is generated in thread-detector flow, so we lost a context of main
problem.
2. Currently, due to implementation, we print not full stacktrace of blocking
thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
This two drawbacks can lead to completely loss of information about blocking
system thread.
I suggests:
1. Add another parameter in {{FailureContext}}, namely {{worker}}
2. Fix threaddump printing.
was:
Currently, reporting of system thread blocking has major drawbacks.
1. As system worker blocking is detected by another thread, due to
implementation, failure handler receives not full information about problem. In
{{FailureContext}} we have only two fields -- {{type}} and {{err}}. Throwable
{{err}} is generated in thread-detector flow, so we lost a context of main
problem.
2. Currently, due to implementation, we print not full stacktrace of blocking
thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
3. Current approach doesn't work when there is one thread in registry, this
fact isn't checked and this can cause an infinite looping of single thread,
calling {{onIdle}} Fixed in
This two drawbacks can lead to completely loss of information about blocking
system thread.
I suggests:
1. Add another parameter in {{FailureContext}}, namely {{worker}}
2. Fix threaddump printing.
3. Add assertion when there is only one system thread in registry
> Improve SYSTEM_WORKER_BLOCKED reporting.
>
>
> Key: IGNITE-13564
> URL: https://issues.apache.org/jira/browse/IGNITE-13564
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9, 2.8.1
>Reporter: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, reporting of system thread blocking has major drawbacks.
> 1. As system worker blocking is detected by another thread, due to
> implementation, failure handler receives not full information about problem.
> In {{FailureContext}} we have only two fields -- {{type}} and {{err}}.
> Throwable {{err}} is generated in thread-detector flow, so we lost a context
> of main problem.
> 2. Currently, due to implementation, we print not full stacktrace of blocking
> thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
> This two drawbacks can lead to completely loss of information about blocking
> system thread.
> I suggests:
> 1. Add another parameter in {{FailureContext}}, namely {{worker}}
> 2. Fix threaddump printing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13564) Improve SYSTEM_WORKER_BLOCKED reporting.
[
https://issues.apache.org/jira/browse/IGNITE-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13564:
--
Description:
Currently, reporting of system thread blocking has major drawbacks.
1. As system worker blocking is detected by another thread, due to
implementation, failure handler receives not full information about problem. In
{{FailureContext}} we have only two fields -- {{type}} and {{err}}. Throwable
{{err}} is generated in thread-detector flow, so we lost a context of main
problem.
2. Currently, due to implementation, we print not full stacktrace of blocking
thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
3. Current approach doesn't work when there is one thread in registry, this
fact isn't checked and this can cause an infinite looping of single thread,
calling {{onIdle}} Fixed in
This two drawbacks can lead to completely loss of information about blocking
system thread.
I suggests:
1. Add another parameter in {{FailureContext}}, namely {{worker}}
2. Fix threaddump printing.
3. Add assertion when there is only one system thread in registry
was:
Currently, reporting of system thread blocking has major drawbacks.
1. As system worker blocking is detected by another thread, due to
implementation, failure handler receives not full information about problem. In
{{FailureContext}} we have only two fields -- {{type}} and {{err}}. Throwable
{{err}} is generated in thread-detector flow, so we lost a context of main
problem.
2. Currently, due to implementation, we print not full stacktrace of blocking
thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
3. Current approach doesn't work when there is one thread in registry, this
fact isn't checked and this can cause an infinite looping of single thread,
calling {{onIdle}}
This two drawbacks can lead to completely loss of information about blocking
system thread.
I suggests:
1. Add another parameter in {{FailureContext}}, namely {{worker}}
2. Fix threaddump printing.
3. Add assertion when there is only one system thread in registry
> Improve SYSTEM_WORKER_BLOCKED reporting.
>
>
> Key: IGNITE-13564
> URL: https://issues.apache.org/jira/browse/IGNITE-13564
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9, 2.8.1
>Reporter: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, reporting of system thread blocking has major drawbacks.
> 1. As system worker blocking is detected by another thread, due to
> implementation, failure handler receives not full information about problem.
> In {{FailureContext}} we have only two fields -- {{type}} and {{err}}.
> Throwable {{err}} is generated in thread-detector flow, so we lost a context
> of main problem.
> 2. Currently, due to implementation, we print not full stacktrace of blocking
> thread in {{org.apache.ignite.internal.worker.WorkersRegistry#onIdle}}.
> 3. Current approach doesn't work when there is one thread in registry, this
> fact isn't checked and this can cause an infinite looping of single thread,
> calling {{onIdle}} Fixed in
> This two drawbacks can lead to completely loss of information about blocking
> system thread.
> I suggests:
> 1. Add another parameter in {{FailureContext}}, namely {{worker}}
> 2. Fix threaddump printing.
> 3. Add assertion when there is only one system thread in registry
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is ability of node to run on several addresses. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. was: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is node can have many addresses to connect to. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem is ability of node to run on several addresses. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is node can have many addresses to connect to. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. was: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is node can have many addresses to connect to. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem is node can have many addresses to connect to. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem is node can have many addresses to connect to. By default, all non-loop back addresses are assigned to node. Connection to a node is established to one of its address. But if lost, other addresses are attempted to reconnect to sequentially. was: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber. "You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. If no address set, all available IP addresses are automaticall picked up. Several addresses prolong failure detection of current node. The timeouts and settings on network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt) work per address. The exception is connRecoveryTimeout. Example: if you have 3 ip addresses configured for a node, Tcp Discovery takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect failure of this node". > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > failureDetectionTimeout * addressesNumber + connRecoveryTimeout. > The problem is node can have many addresses to connect to. By default, all > non-loop back addresses are assigned to node. Connection to a node is > established to one of its address. But if lost, other addresses are attempted > to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13665) Useless failure trace "IgnitionEx$IgniteNamedInstance$2.apply"
[
https://issues.apache.org/jira/browse/IGNITE-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13665:
-
Description:
When failure handler catches an issue in striped pool, maybe in some other
cases, thread dump is as folows:
{code}
[2020-10-10T10:10:10,100][WARN ][grid-timeout-worker-#22%cluster%][] Possible
failure suppressed accordingly to a configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]]]
org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
[ignite-core.jar]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
[ignite-core.jar]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:296)
[ignite-core.jar]
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:265)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
[ignite-core.jar]
at java.lang.Thread.run(Thread.java:834) [?:?]
{code}
when the actual stack trace from the relevant thread is hidden somewhere deep
below. And may even be suppressed. This is a usability nightmare.
was:
When failure handler catches an issue in striped pool, maybe in some other
cases, thread dump is as folows:
{code}
[2020-10-10T10:10:10,100][WARN ][grid-timeout-worker-#22%cluster%][] Possible
failure suppressed accordingly to a configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=EPE_CLUSTER_PERF, finished=false,
heartbeatTs=1601234567890]]]
org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
[ignite-core.jar]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
[ignite-core.jar]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:296)
[ignite-core.jar]
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:265)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
[ignite-core.jar]
at java.lang.Thread.run(Thread.java:834) [?:?]
{code}
when the actual stack trace from the relevant thread is hidden somewhere deep
below. And may even be suppressed. This is a usability nightmare.
> Useless failure trace "IgnitionEx$IgniteNamedInstance$2.apply"
> --
>
> Key: IGNITE-13665
> URL: https://issues.apache.org/jira/browse/IGNITE-13665
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.9.1
>
>
> When failure handler catches an issue in striped pool, maybe in some other
> cases, thread dump is as folows:
> {code}
> [2020-10-10T10:10:10,100][WARN ][grid-timeout-worker-#22%cluster%][] Possible
> failure suppressed accordingly to a configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=sys-stripe-0,
> igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]]]
> org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-0,
> igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]
> at
>
[jira] [Created] (IGNITE-13665) Useless failure trace "IgnitionEx$IgniteNamedInstance$2.apply"
Ilya Kasnacheev created IGNITE-13665:
Summary: Useless failure trace
"IgnitionEx$IgniteNamedInstance$2.apply"
Key: IGNITE-13665
URL: https://issues.apache.org/jira/browse/IGNITE-13665
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
Fix For: 2.9.1
When failure handler catches an issue in striped pool, maybe in some other
cases, thread dump is as folows:
{code}
[2020-10-10T10:10:10,100][WARN ][grid-timeout-worker-#22%cluster%][] Possible
failure suppressed accordingly to a configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=EPE_CLUSTER_PERF, finished=false,
heartbeatTs=1601234567890]]]
org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-0,
igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
[ignite-core.jar]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
[ignite-core.jar]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:296)
[ignite-core.jar]
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:265)
[ignite-core.jar]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
[ignite-core.jar]
at java.lang.Thread.run(Thread.java:834) [?:?]
{code}
when the actual stack trace from the relevant thread is hidden somewhere deep
below. And may even be suppressed. This is a usability nightmare.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter
[ https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2890: --- Labels: .NET (was: .net) > .NET: Add CacheConfiguration.NodeFilter > --- > > Key: IGNITE-2890 > URL: https://issues.apache.org/jira/browse/IGNITE-2890 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > See ServiceConfiguration.NodeFilter > * Caches start earlier than platform => need to pass pointer for static > CacheConfigurations > * For dynamic cache start, no need for pointers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter
[ https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-2890: --- Release Note: .NET: Add CacheConfiguration.NodeFilter > .NET: Add CacheConfiguration.NodeFilter > --- > > Key: IGNITE-2890 > URL: https://issues.apache.org/jira/browse/IGNITE-2890 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .net > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > See ServiceConfiguration.NodeFilter > * Caches start earlier than platform => need to pass pointer for static > CacheConfigurations > * For dynamic cache start, no need for pointers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-2890) .NET: Add CacheConfiguration.NodeFilter
[ https://issues.apache.org/jira/browse/IGNITE-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225490#comment-17225490 ] Pavel Tupitsyn commented on IGNITE-2890: Merged to master: fcc76f65835b41cd952b5bfe23a897977e94b6f7 > .NET: Add CacheConfiguration.NodeFilter > --- > > Key: IGNITE-2890 > URL: https://issues.apache.org/jira/browse/IGNITE-2890 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .net > Time Spent: 20m > Remaining Estimate: 0h > > See ServiceConfiguration.NodeFilter > * Caches start earlier than platform => need to pass pointer for static > CacheConfigurations > * For dynamic cache start, no need for pointers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13664) GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov reassigned IGNITE-13664:
Assignee: Sergey Chugunov
> GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on
> Windows platform
> ---
>
> Key: IGNITE-13664
> URL: https://issues.apache.org/jira/browse/IGNITE-13664
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.10
>
>
> This test fails to start Ignite node due to the following exception:
> {noformat}
> [2020-11-03
> 18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
> Exception during start processors, node will be stopped and close connections
> java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
> \
> at java.util.regex.Pattern.error(Pattern.java:1969)
> at java.util.regex.Pattern.compile(Pattern.java:1708)
> at java.util.regex.Pattern.(Pattern.java:1352)
> at java.util.regex.Pattern.compile(Pattern.java:1028)
> at java.lang.String.split(String.java:2380)
> at java.lang.String.split(String.java:2422)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
> at
> org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2375)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The root cause of this failure is that {{File.separator}} on Windows platform
> is slash, which is interpreted as an erroneous regular expression by
> {{String.split()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13664) GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13664:
-
Description:
This test fails to start Ignite node due to the following exception:
{noformat}
[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close connections
java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
\
at java.util.regex.Pattern.error(Pattern.java:1969)
at java.util.regex.Pattern.compile(Pattern.java:1708)
at java.util.regex.Pattern.(Pattern.java:1352)
at java.util.regex.Pattern.compile(Pattern.java:1028)
at java.lang.String.split(String.java:2380)
at java.lang.String.split(String.java:2422)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
at
org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2375)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The root cause of this failure is that {{File.separator}} on Windows platform
is slash, which is interpreted as an erroneous regular expression by
{{String.split()}}.
was:
This test fails to start Ignite node due to the following exception:
{noformat}
[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close connections
java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
\
at java.util.regex.Pattern.error(Pattern.java:1969)
at java.util.regex.Pattern.compile(Pattern.java:1708)
at java.util.regex.Pattern.(Pattern.java:1352)
at java.util.regex.Pattern.compile(Pattern.java:1028)
at java.lang.String.split(String.java:2380)
at java.lang.String.split(String.java:2422)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
at
org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
at
[jira] [Updated] (IGNITE-13664) GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13664:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on
> Windows platform
> ---
>
> Key: IGNITE-13664
> URL: https://issues.apache.org/jira/browse/IGNITE-13664
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.10
>
>
> This test fails to start Ignite node due to the following exception:
> {noformat}
> [2020-11-03
> 18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
> Exception during start processors, node will be stopped and close connections
> java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
> \
> at java.util.regex.Pattern.error(Pattern.java:1969)
> at java.util.regex.Pattern.compile(Pattern.java:1708)
> at java.util.regex.Pattern.(Pattern.java:1352)
> at java.util.regex.Pattern.compile(Pattern.java:1028)
> at java.lang.String.split(String.java:2380)
> at java.lang.String.split(String.java:2422)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
> at
> org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2375)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The root cause of this failure is that {{File.separator}} on Windows platform
> is slash, which is interpreted as an erroneous regular expression by
> {{String.split()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13664) GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on Windows platform
[
https://issues.apache.org/jira/browse/IGNITE-13664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13664:
-
Description:
This test fails to start Ignite node due to the following exception:
{noformat}
[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close connections
java.util.regex.PatternSyntaxException: Unexpected internal error near index 1
\
at java.util.regex.Pattern.error(Pattern.java:1969)
at java.util.regex.Pattern.compile(Pattern.java:1708)
at java.util.regex.Pattern.(Pattern.java:1352)
at java.util.regex.Pattern.compile(Pattern.java:1028)
at java.lang.String.split(String.java:2380)
at java.lang.String.split(String.java:2422)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
at
org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2375)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The root cause of this failure is that {{File.separator}} on Windows platform
is slash, which is interpreted as an erroneous regular expression by
{{String.split()}}.
was:
This test fails to start Ignite node due to the following exception:
{noformat}
[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close
connections[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close
connectionsjava.util.regex.PatternSyntaxException: Unexpected internal error
near index 1\ at java.util.regex.Pattern.error(Pattern.java:1969) at
java.util.regex.Pattern.compile(Pattern.java:1708) at
java.util.regex.Pattern.(Pattern.java:1352) at
java.util.regex.Pattern.compile(Pattern.java:1028) at
java.lang.String.split(String.java:2380) at
java.lang.String.split(String.java:2422) at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641) at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
at
[jira] [Created] (IGNITE-13664) GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on Windows platform
Vyacheslav Koptilin created IGNITE-13664:
Summary:
GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand fails on
Windows platform
Key: IGNITE-13664
URL: https://issues.apache.org/jira/browse/IGNITE-13664
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Fix For: 2.10
This test fails to start Ignite node due to the following exception:
{noformat}
[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close
connections[2020-11-03
18:02:02,044][ERROR][test-runner-#1%gridCommandHandlerTest%][IgniteKernal%gridCommandHandlerTest1]
Exception during start processors, node will be stopped and close
connectionsjava.util.regex.PatternSyntaxException: Unexpected internal error
near index 1\ at java.util.regex.Pattern.error(Pattern.java:1969) at
java.util.regex.Pattern.compile(Pattern.java:1708) at
java.util.regex.Pattern.(Pattern.java:1352) at
java.util.regex.Pattern.compile(Pattern.java:1028) at
java.lang.String.split(String.java:2380) at
java.lang.String.split(String.java:2422) at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1601)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1282) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2096)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1748)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641) at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1231)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1152)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1128)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:997)
at
org.apache.ignite.util.GridCommandHandlerTest.testPersistenceCleanCorruptedCachesCommand(GridCommandHandlerTest.java:414)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2375)
at java.lang.Thread.run(Thread.java:748){noformat}
The root cause of this failure is that {{File.separator}} on Windows platform
is slash, which is interpreted as an erroneous regular expression by
{{String.split()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11312) JDBC: Thin driver reports incorrect property names
[ https://issues.apache.org/jira/browse/IGNITE-11312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-11312: Fix Version/s: 2.9.1 > JDBC: Thin driver reports incorrect property names > -- > > Key: IGNITE-11312 > URL: https://issues.apache.org/jira/browse/IGNITE-11312 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Stanislav Lukyanov >Assignee: Lev Agafonov >Priority: Major > Labels: 2.9.1-rc, newbie > Fix For: 2.10, 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JDBC driver reports the properties it supports via getPropertyInfo method. It > currently reports the property names as simple strings, like > "enforceJoinOrder". However, when the properties are processed on connect > they are looked up with prefix "ignite.jdbc", e.g. > "ignite.jdbc.enforceJoinOrder". > Because of this UI tools like DBeaver can't properly pass the properties to > Ignite. For example, when "enforceJoinOrder" is set to true in "Connection > settings" -> "Driver properties" menu of DBeaver it has no effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13265: Fix Version/s: 2.9.1 > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13373: Fix Version/s: 2.9.1 > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13072) Synchronization problems when different classloaders are used for deployment of same class
[
https://issues.apache.org/jira/browse/IGNITE-13072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13072:
Fix Version/s: 2.9.1
> Synchronization problems when different classloaders are used for deployment
> of same class
> --
>
> Key: IGNITE-13072
> URL: https://issues.apache.org/jira/browse/IGNITE-13072
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If you concurrently deploy one class using different classloaders you can get
> error:
> {noformat}
> 2020-04-28
> 14:36:42.523[ERROR][sys-stripe-45-#46%GRID%GridNodeName%][o.a.i.i.m.d.GridDeploymentLocalStore]
> Found more than one active deployment for the same resource [cls=class
> org.some.class.old.InvokeIndexRemover, depMode=SHARED, dep=GridDeployment
> [ts=1588067100125, depMode=SHARED,
> clsLdr=org.some.class.factory.NodeClassLoader@14035d21,
> clsLdrId=85ab310c171-a9fad11c-9f8c-4d2a-8146-6c87254303e7, userVer=0,
> loc=true, sampleClsName=org.some.class.predicates.CompositePredicate,
> pendingUndeploy=false, undeployed=false, usage=0]]
>
> 2020-04-28
> 14:36:42.544[ERROR][sys-stripe-45-#46%GRID%GridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=f104e069-9d80-4202-b50a-b3dc1804ac89,
> msg=GridNearAtomicSingleUpdateRequest [key=KeyCacheObject [hasValBytes=true],
> super=GridNearAtomicSingleUpdateRequest [key=KeyCacheObject
> [hasValBytes=true], parent=GridNearAtomicAbstractSingleUpdateRequest
> [nodeId=null, futId=1376257, topVer=AffinityTopologyVersion [topVer=35,
> minorTopVer=0], parent=GridNearAtomicAbstractUpdateRequest [res=null,
> flags=]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:203)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.findClass(GridCacheDeploymentManager.java:802)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.loadClass(GridCacheDeploymentManager.java:794)
> at org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8561)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:700)
> 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:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9959)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10017)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateInvokeRequest.finishUnmarshal(GridNearAtomicSingleUpdateInvokeRequest.java:200)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
>
[jira] [Updated] (IGNITE-13296) .NET: TransactionImpl finalizer can crash the process
[ https://issues.apache.org/jira/browse/IGNITE-13296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13296: Fix Version/s: 2.9.1 > .NET: TransactionImpl finalizer can crash the process > - > > Key: IGNITE-13296 > URL: https://issues.apache.org/jira/browse/IGNITE-13296 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > ~TransactionImpl potentially throws an exception (e.g. when grid is stopped), > causing the entire process to abort. > GetLocalActiveTransactions is especially problematic - the method is > informational, yet will result in all the returned transactions to be > finalized later. > * Finalizers should not throw exceptions > * Stopped grid is a valid use case > * GetLocalActiveTransactions should be fixed to return "read-only" > transactions that won't be finalized > Review all filalizers and make sure they are safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12509) CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified RebalanceDelay
[ https://issues.apache.org/jira/browse/IGNITE-12509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-12509: Fix Version/s: 2.9.1 > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified > RebalanceDelay > - > > Key: IGNITE-12509 > URL: https://issues.apache.org/jira/browse/IGNITE-12509 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: 2.9.1-rc, newbie > Fix For: 2.10, 2.9.1 > > Attachments: RebalanceDelayTest.java > > > Steps to reproduce: > 1. Start in-memory cluster with 2 server nodes > 2. Start 3 caches with different rebalance delays (e.g. 5, 10 and 15 seconds) > and upload some data > 3. Start localListener for EVT_CACHE_REBALANCE_STOPPED event on one of the > nodes. > 4. Start one more server node. > 5. Wait for 5 seconds, till rebalance delay is reached. > 6. EVT_CACHE_REBALANCE_STOPPED event received 3 times (1 for each cache), but > in fact only 1 cache was rebalanced. The same happens for the rest of the > caches. > As result on rebalance finish we're getting event for each cache > [CACHE_COUNT] times, instead of 1. > Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13363) GridDhtCacheEntry::toString locks
[
https://issues.apache.org/jira/browse/IGNITE-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13363:
Fix Version/s: 2.9.1
> GridDhtCacheEntry::toString locks
> -
>
> Key: IGNITE-13363
> URL: https://issues.apache.org/jira/browse/IGNITE-13363
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.8.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> `GridDhtCacheEntry::toString` locks the entry which may lead to dead locks
> and, I assume, even performance issues.
> We, naturally, call `toString` on everything all the time and it needs to be
> the safest and the lightest possible operation.
> Example of a hang with locking toString:
>
> {{Thread [name="grid-timeout-worker-#71%GRIDC1%", id=98, state=WAITING,
> blockCnt=2, waitCnt=14196]
> Lock
> [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@20c96143,
> ownerName=exchange-worker-#188%GRIDC1%, ownerId=265]
> at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
> at
> java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.2/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
> at
> app//o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:5051)
> at
> app//o.a.i.i.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:819)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at
> java.base@11.0.2/java.lang.StringBuilder.append(StringBuilder.java:168)
> at
> java.base@11.0.2/java.util.AbstractCollection.toString(AbstractCollection.java:473)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.distributed.GridDistributedTxMapping.toString(GridDistributedTxMapping.java:319)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:864)
> at
> app//o.a.i.i.processors.cache.distributed.near.IgniteTxMappingsSingleImpl.toString(IgniteTxMappingsSingleImpl.java:99)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
>
[jira] [Updated] (IGNITE-13388) apache-ignite deb package depends on a non-existent package and can't be installed on Debian 10
[
https://issues.apache.org/jira/browse/IGNITE-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13388:
Fix Version/s: 2.9.1
> apache-ignite deb package depends on a non-existent package and can't be
> installed on Debian 10
> ---
>
> Key: IGNITE-13388
> URL: https://issues.apache.org/jira/browse/IGNITE-13388
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Artem Budnikov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The apache-ignite deb package v. 2.8.1 depends on 'openjdk-8-jdk', which is
> only available in Debian stretch and isn't available in later Debian
> distributions. An attempt to install the package gives this error:
> {code:java}
> $ sudo apt-get install apache-ignite=2.8.1-1
> ...
> The following packages have unmet dependencies:
> apache-ignite : Depends: openjdk-8-jdk but it is not installable or
> oracle-java8-installer but it is not installable
> E: Unable to correct problems, you have held broken packages{code}
> Package information:
> {code:java}
> $ apt-cache show apache-ignite=2.8.1-1
> Package: apache-ignite
> Version: 2.8.1-1
> Architecture: all
> Maintainer: Petr Ivanov
> Installed-Size: 572071
> Depends: openjdk-8-jdk | oracle-java8-installer, systemd, passwd
> Section: misc
> Priority: optional
> Homepage: https://ignite.apache.org
> Description: Apache Ignite In-Memory Computing, Database and Caching Platform
> Ignite™ is a memory-centric distributed database, caching, and processing
> platform for transactional, analytical, and streaming workloads, delivering
> in-memory speeds at petabyte scale
> Description-md5: 6a59db03fa1e142387abef6ef6bb0d83
> Filename: pool/main/a/apache-ignite_2.8.1-1_all.deb
> SHA1: 67d197a5e582f6ea7c66da26a755f937f8e16fc9
> SHA256: fc9a274ecb82716905d4120a715e9c74441dfed67831874eb3c35c4953bfc90d
> Size: 399746094
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13380) Output IgniteSystemProperties via ignite.sh
[
https://issues.apache.org/jira/browse/IGNITE-13380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13380:
Fix Version/s: 2.9.1
> Output IgniteSystemProperties via ignite.sh
> ---
>
> Key: IGNITE-13380
> URL: https://issues.apache.org/jira/browse/IGNITE-13380
> Project: Ignite
> Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> Provide the ability output of all available Ignite properties
> ({{IgniteSystemProperties}}) with its descriptions in the {{ignite.sh}}
> command. For example,
> {noformat}
> ignite.sh -systemProps
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13382) DurableBackgroundTask can abandon incomplete task
[ https://issues.apache.org/jira/browse/IGNITE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13382: Fix Version/s: 2.9.1 > DurableBackgroundTask can abandon incomplete task > - > > Key: IGNITE-13382 > URL: https://issues.apache.org/jira/browse/IGNITE-13382 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > DurableBackgroundTasks are tracked using metastorage, there's a specific > marker for every task, and it is removed right after the task is complete. > But there's a race between checkpointer and metastorage. End-marker removal > is a logical operation, while task itself is mostly physical (at least the > existing one). So, following scenario is possible: > * Checkpoint occurs in the middle of the task; > * Task is completed before the next checkpoint; > * Metastorage record is deleted, this fact if written to WAL and synced to > the storage; > * Node failed; > * Recovery process applies deletion from metastorage, this means that > DurableBackgroundTasks info is lost; > * But part of the index is still present in the storage. > I think that we should remove markers from metastorage only after the next > checkpoint, this will 100% save us from such situation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13379) Exception occur on SQL caches when client reconnect
[
https://issues.apache.org/jira/browse/IGNITE-13379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13379:
Fix Version/s: 2.9.1
> Exception occur on SQL caches when client reconnect
> ---
>
> Key: IGNITE-13379
> URL: https://issues.apache.org/jira/browse/IGNITE-13379
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When client started only subset of all cluster caches, it can have issues on
> reconnect.
> If cache isn't started on client, it still registered some SQL structures:
> {{GridQueryProcessor#initQueryStructuresForNotStartedCache}}
> but these structures are not cleared on disconnect:
> {{GridCacheProcessor#onReconnected}}
> This leads to exception on reconnect:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Type with name 'Timestamp'
> already indexed in cache 'TEST_CACHE2'.
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1712)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:834)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:911)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.initQueryStructuresForNotStartedCache(GridQueryProcessor.java:889)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:968)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:857)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:1205)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:850)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3258)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3104)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13397) NPE in logSupplierDone(UUID nodeId)
[
https://issues.apache.org/jira/browse/IGNITE-13397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13397:
Fix Version/s: 2.9.1
> NPE in logSupplierDone(UUID nodeId)
> ---
>
> Key: IGNITE-13397
> URL: https://issues.apache.org/jira/browse/IGNITE-13397
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> NPE in logSupplierDone(UUID nodeId)
> {noformat}
> [2020-08-30 18:06:52,360][ERROR][rebalance-#5033%new-version-node%][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=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.logSupplierDone(GridDhtPartitionDemander.java:2009)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:1730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1200(GridDhtPartitionDemander.java:1142)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.ownPartition(GridDhtPartitionDemander.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:649)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleSupplyMessage$0(GridDhtPreloader.java:356)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13401) Unsupported protocol version exception when getting cache configuration from Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-13401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13401:
Fix Version/s: 2.9.1
> Unsupported protocol version exception when getting cache configuration from
> Java thin client
> -
>
> Key: IGNITE-13401
> URL: https://issues.apache.org/jira/browse/IGNITE-13401
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Marcus Lo
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We encounter BinaryObjectException: Unsupported protocol version: 8 in one of
> our tables in Ignite when querying cache configuration via Java thin client.
> To reproduce:
> # Setup Ignite with persistence disabled (single node)
> # Create the follow table:
> {code:java}
> CREATE TABLE IF NOT EXISTS LEOD_CONTEXT_STATUS
> (
> flashNode VARCHAR NOT NULL,
> legalEntity VARCHAR NOT NULL,
> account VARCHAR NOT NULL,
> userIdVARCHAR NOT NULL,
> eqtgContext VARCHAR NOT NULL,
> submissionDateINT NOT NULL,
> actionVARCHAR NOT NULL,
> actionTimeTIME NOT NULL,
> runNumber INT NOT NULL,
> segment VARCHAR NOT NULL,
> geography VARCHAR NOT NULL,
> priceVersion VARCHAR NOT NULL,
> statusVARCHAR NOT NULL,
> errorCountINT NOT NULL,
> comments VARCHAR,
> equityDeltaLowerBound DOUBLE,
> equityDeltaUpperBound DOUBLE,
> equityDeltaUtil DOUBLE,
> equityVegaLowerBound DOUBLE,
> equityVegaUpperBound DOUBLE,
> equityVegaUtilDOUBLE,
> lastUpdateTimeTIMESTAMP NOT NULL,
> PRIMARY KEY (flashNode, legalEntity, account, submissionDate)
> )
> WITH "template=REPLICATED, cache_name=LeodContextStatusCache";{code}
> # Run the following test (in Kotlin):
> {code:java}
> @Test
> fun `moo`() {
> val config = ClientConfiguration()
> .setAddresses("localhost:10800")
> val ignite = Ignition.startClient(config)
> ignite.cache("LeodContextStatusCache")
> .configuration
> }
> {code}
> # It fails in the following exception:
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 8
> at
> org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:796)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:221)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:165)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.cacheConfiguration(ClientUtils.java:381)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.lambda$getConfiguration$2(TcpClientCache.java:160)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:247)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:180)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.getConfiguration(TcpClientCache.java:155)
> {code}
> I notice that if any one of the columns is removed, the issue disappears.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13418) Deadlock on multiple cache delete
[
https://issues.apache.org/jira/browse/IGNITE-13418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13418:
Fix Version/s: 2.9.1
> Deadlock on multiple cache delete
> -
>
> Key: IGNITE-13418
> URL: https://issues.apache.org/jira/browse/IGNITE-13418
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Thread 1:
> - acquires checkpoint read lock in
> GridCacheProcessor#processCacheStopRequestOnExchangeDone
> - acquires GridQueryProcessor#stateMux in GridQueryProcessor.onCacheStop
> - enters H2TreeIndex.destroy
> - releases checkpoint read lock in H2Tree.temporaryReleaseLock, can't take
> it again because of db-checkpoint-thread
> Thread 2:
> - acquires checkpoint read lock in
> GridCacheProcessor#processCacheStopRequestOnExchangeDone
> - trying to acquire GridQueryProcessor#stateMux in
> GridQueryProcessor.onCacheStop which is held by thread 1
> db-checkpoint-thread:
> - trying to acquire checkpoint write lock, can't do it because of Thread 2
> Decision: H2Tree.temporaryReleaseLock should release lock only in case when
> tree deletion is asynchronous (H2TreeIndex.destroy is called with
> async=true), i.e. it happens inside of DurableBackgroundTask. Such tasks are
> executed in separate threads, which don't hold any other locks.
> Thread dump:
> {code:java}
> Thread [name="sys-#1220%DPL_GRID%DplGridNodeName%", id=3200, state=BLOCKED,
> blockCnt=1, waitCnt=0]
> Lock [object=java.lang.Object@6a9a92ba,
> ownerName=sys-#1215%DPL_GRID%DplGridNodeName%, ownerId=3195]
> at
> o.a.i.i.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1695)
> at
> o.a.i.i.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:902)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1169)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2644)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.lambda$processCacheStopRequestOnExchangeDone$629e8679$1(GridCacheProcessor.java:2803)
> at
> o.a.i.i.processors.cache.GridCacheProcessor$$Lambda$620/1418386924.apply(Unknown
> Source)
> at o.a.i.i.util.IgniteUtils.lambda$null$1(IgniteUtils.java:10879)
> at o.a.i.i.util.IgniteUtils$$Lambda$436/321848940.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Locked synchronizers:
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2582f93c
> java.util.concurrent.ThreadPoolExecutor$Worker@4da1cafe
> Thread [name="sys-#1215%DPL_GRID%DplGridNodeName%", id=3195, state=BLOCKED,
> blockCnt=4, waitCnt=437520]
> Lock [object=o.a.i.i.processors.failure.FailureProcessor@78edb1e9,
> ownerName=async-durable-background-task-executor-1-#1222%DPL_GRID%DplGridNodeName%,
> ownerId=3202]
> at
> o.a.i.i.processors.failure.FailureProcessor.process(FailureProcessor.java:162)
> at
> o.a.i.i.processors.failure.FailureProcessor.process(FailureProcessor.java:151)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.failCheckpointReadLock(GridCacheDatabaseSharedManager.java:1787)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1722)
> at
> o.a.i.i.processors.query.h2.database.H2Tree.temporaryReleaseLock(H2Tree.java:690)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.temporaryReleaseLock(BPlusTree.java:2367)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2548)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2522)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2522)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2522)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroy(BPlusTree.java:2441)
> at
> o.a.i.i.processors.cache.persistence.tree.BPlusTree.destroy(BPlusTree.java:2392)
> at
> o.a.i.i.processors.query.h2.database.H2TreeIndex.destroy0(H2TreeIndex.java:671)
> at
> o.a.i.i.processors.query.h2.database.H2TreeIndex.destroy(H2TreeIndex.java:639)
> at o.a.i.i.processors.query.h2.opt.GridH2Table.destroy(GridH2Table.java:567)
> at
> o.a.i.i.processors.query.h2.H2TableDescriptor.onDrop(H2TableDescriptor.java:347)
>
[jira] [Updated] (IGNITE-13408) System view for binary metadata
[
https://issues.apache.org/jira/browse/IGNITE-13408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13408:
Fix Version/s: 2.9.1
> System view for binary metadata
> ---
>
> Key: IGNITE-13408
> URL: https://issues.apache.org/jira/browse/IGNITE-13408
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: 2.9.1-rc, IEP-35
> Fix For: 2.10, 2.9.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, list of binary metadata available via experimental {{control.sh}}
> command.
> We need to provide a corresponding System view for this information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13398) NPE in IgniteServiceProcessor when destroying a cache
[
https://issues.apache.org/jira/browse/IGNITE-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13398:
Fix Version/s: 2.9.1
> NPE in IgniteServiceProcessor when destroying a cache
> --
>
> Key: IGNITE-13398
> URL: https://issues.apache.org/jira/browse/IGNITE-13398
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Denis Mekhanikov
>Assignee: Ilya Kazakov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Attachments: Main.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Try running the attached reproducer: [^Main.java]. The following exception is
> printed to the logs:
> {noformat}
> Sep 03, 2020 12:13:58 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to notify direct custom event listener:
> DynamicCacheChangeBatch [id=c1d6e335471-6bafb375-9d3e-487a-974d-35927ae02c04,
> reqs=ArrayList [DynamicCacheChangeRequest [cacheName=foo, hasCfg=false,
> nodeId=5e41fda8-e749-432c-9832-7b1c6ee3d0c8, clientStartOnly=false,
> stop=true, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=null, stopCaches=[foo],
> startGrps=[], stopGrps=[foo, destroy=true], resetParts=null,
> stateChangeRequest=null], startCaches=false]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.lambda$processDynamicCacheChangeRequest$6(IgniteServiceProcessor.java:1694)
> at java.util.Collection.removeIf(Collection.java:414)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.processDynamicCacheChangeRequest(IgniteServiceProcessor.java:1691)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.access$200(IgniteServiceProcessor.java:108)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:229)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:665)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13417) Cache Interceptors deserialization on client nodes
[ https://issues.apache.org/jira/browse/IGNITE-13417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13417: Fix Version/s: 2.9.1 > Cache Interceptors deserialization on client nodes > -- > > Key: IGNITE-13417 > URL: https://issues.apache.org/jira/browse/IGNITE-13417 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > After fix https://issues.apache.org/jira/browse/IGNITE-1903, Cache > Interceptors still don't work > Looks like we need to add @SerializeSeparately to this field too -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13409) System view for metastorage items
[ https://issues.apache.org/jira/browse/IGNITE-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13409: Fix Version/s: 2.9.1 > System view for metastorage items > - > > Key: IGNITE-13409 > URL: https://issues.apache.org/jira/browse/IGNITE-13409 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: 2.9.1-rc, IEP-35 > Fix For: 2.10, 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to provide a System view to show metastorage and distributed > metastorage properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13422) Explicit command.sh option to enable experimental commands
[ https://issues.apache.org/jira/browse/IGNITE-13422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13422: Fix Version/s: 2.9.1 > Explicit command.sh option to enable experimental commands > -- > > Key: IGNITE-13422 > URL: https://issues.apache.org/jira/browse/IGNITE-13422 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Right now experimental commands can be enabled only via an environment > variable(IGNITE_ENABLE_EXPERIMENTAL_COMMAND). > We need to add an explicit option to command.sh "--enable-experimental" which > will turn on experimental commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13403) Update JDBC metadata to match actual capabilities
[
https://issues.apache.org/jira/browse/IGNITE-13403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13403:
Fix Version/s: 2.9.1
> Update JDBC metadata to match actual capabilities
> -
>
> Key: IGNITE-13403
> URL: https://issues.apache.org/jira/browse/IGNITE-13403
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In our JDBC metadata some capabilities are reported not to be supported,
> while in fact they are. E.g. I see
> {code}
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithAddColumn() throws
> SQLException {
> return false;
> }
> /** {@inheritDoc} */
> @Override public boolean supportsAlterTableWithDropColumn() throws
> SQLException {
> return false;
> }
> {code}
> while in fact `ALTER TABLE ADD/DROP COLUMN` are supported.
> Need to go through the list of capabilities and correct them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13435) Fixing some unrecorded issues command warm-up control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13435: Fix Version/s: 2.9.1 > Fixing some unrecorded issues command warm-up control.sh > > > Key: IGNITE-13435 > URL: https://issues.apache.org/jira/browse/IGNITE-13435 > Project: Ignite > Issue Type: Bug > Components: control.sh >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: 2.9.1-rc, IEP-40 > Fix For: 2.10, 2.9.1 > > Time Spent: 50m > Remaining Estimate: 0h > > Unrecorded problems: > * When parsing arguments for the warm-up command, subsequent arguments may be > skipped, such as auto-confirmation "--yes"; > * Processing requests for jetty; > * Authorization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13431) NPE during Cassandra Store initialization with PRIMITIVE strategy
[
https://issues.apache.org/jira/browse/IGNITE-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13431:
Fix Version/s: 2.9.1
> NPE during Cassandra Store initialization with PRIMITIVE strategy
> -
>
> Key: IGNITE-13431
> URL: https://issues.apache.org/jira/browse/IGNITE-13431
> Project: Ignite
> Issue Type: Bug
> Components: integrations
>Affects Versions: 2.8.1
>Reporter: Igor Belyakov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Attachments: IgnitePersistentStoreTest.java
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When trying to create a simple cache with Cassandra store and have value
> persistence strategy PRIMITIVE, the following exception occurs:
> {code:java}
> 17:29:20,059 ERROR [main] - Exception during start processors, node will be
> stopped and close connections17:29:20,059 ERROR [main] - Exception during
> start processors, node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter [] at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2045)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> org.apache.ignite.tests.IgnitePersistentStoreTest.directPersistenceConfigTest(IgnitePersistentStoreTest.java:807)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:160) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name: cache1 at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4906)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:4937)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.addCacheFromConfiguration(GridLocalConfigManager.java:269)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:167)
> at
>
[jira] [Updated] (IGNITE-13439) Printing detailed classpath slowdowns node initialization
[ https://issues.apache.org/jira/browse/IGNITE-13439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13439: Fix Version/s: 2.9.1 > Printing detailed classpath slowdowns node initialization > - > > Key: IGNITE-13439 > URL: https://issues.apache.org/jira/browse/IGNITE-13439 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.8.1 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Minor > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If IGNITE_LOG_CLASSPATH_CONTENT_ON_STARTUP is enabled, > IgniteKernel#ackClassPathContent parses the classpath and recursively > traverses the file system printing all jars and class files. > Traversing the files system could take much time in case of many class files > or having a root folder in the classpath. > The reasonable behavior is to print only root classpath folders. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13426) Add command to control.(sh|bin) to get an arbitrary SystemView
[ https://issues.apache.org/jira/browse/IGNITE-13426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13426: Fix Version/s: 2.9.1 > Add command to control.(sh|bin) to get an arbitrary SystemView > -- > > Key: IGNITE-13426 > URL: https://issues.apache.org/jira/browse/IGNITE-13426 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > It's needed to add the ability to get an arbitrary SystemView via > control.(sh|bin) script. > Proposed command structure: > control.(sh|bin) --system-view [–node-id node_id] system_view_name > Parameters: > system_view_name - Name of the system view which value is requested. > Both "SQL" and "common" styles > of system view name are supported > (e.g. SQL_TABLES and sql.tables > will be handled similarly). > node_id - ID of the node to get the system view > from. > If not set, random node will be > chosen. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13479) Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set
[ https://issues.apache.org/jira/browse/IGNITE-13479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13479: Fix Version/s: 2.9.1 > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start > if JMX port was set > - > > Key: IGNITE-13479 > URL: https://issues.apache.org/jira/browse/IGNITE-13479 > Project: Ignite > Issue Type: Bug > Components: control.sh >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is no other way to set parameters for docker images, so, when you set > JMX port to JVM_OPTS, you can't start control.sh: > > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) > sun.management.AgentConfigurationError: java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13462) .NET: Thin client Dispose hangs when continuous query is active on .NET Core 3.x
[
https://issues.apache.org/jira/browse/IGNITE-13462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13462:
Fix Version/s: 2.9.1
> .NET: Thin client Dispose hangs when continuous query is active on .NET Core
> 3.x
>
>
> Key: IGNITE-13462
> URL: https://issues.apache.org/jira/browse/IGNITE-13462
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Switch all projects to netcoreapp3.0 (or 3.1)
> * Run Apache.Ignite.Core.Tests.Client.Cache.ContinuousQueryTest - it hangs on
> ClientSocket.Dispose
> Looks like Socket.Shutdown call is missing, or we can use Socket.Close with a
> timeout.
> Also see https://github.com/dotnet/runtime/issues/23990:
> {code:java}
> The native behavior of closing a socket file descriptor while it's being used
> in a synchronous/blocking accept/connect/send/recv/etc. call is undefined on
> Linux, and often results in a hang
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13458) RebalancingPartitionsTotal metrics
[ https://issues.apache.org/jira/browse/IGNITE-13458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13458: Fix Version/s: 2.9.1 > RebalancingPartitionsTotal metrics > -- > > Key: IGNITE-13458 > URL: https://issues.apache.org/jira/browse/IGNITE-13458 > Project: Ignite > Issue Type: Bug >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Labels: 2.9.1-rc, IEP-35 > Fix For: 2.10, 2.9.1 > > Time Spent: 1h > Remaining Estimate: 0h > > We need the total number of partitions to calculate the progress bar. It was > implemented in CacheMetrics, but the new metrics don't support it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13484) C++ odbc-example losing some values if run with 1 additional node
[
https://issues.apache.org/jira/browse/IGNITE-13484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13484:
Fix Version/s: 2.9.1
> C++ odbc-example losing some values if run with 1 additional node
> -
>
> Key: IGNITE-13484
> URL: https://issues.apache.org/jira/browse/IGNITE-13484
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.8.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Case:
> - run 1 additional node
> - run odbc-example
> Actual:
> {code}
> >>> Cache ODBC example started.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Smith Master Degree. 2500
> >>> John Roe Bachelor Degree. 1500
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 900
> >>> Jane Doe Bachelor Degree. 1300
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1280
> >>> Master Degree. 2366.67
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Richard Miles Microsoft
> >>> Adjusted salary for Mary Major. Querying again.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Smith Master Degree. 2500
> >>> John Roe Bachelor Degree. 1500
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 1200
> >>> Jane Doe Bachelor Degree. 1300
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1340
> >>> Master Degree. 2366.67
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Richard Miles Microsoft
> >>> Removing several employees. Querying again.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 1200
> >>> Jane Doe Bachelor Degree. 1300
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1300
> >>> Master Degree. 2300
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Richard Miles Microsoft
> [12:10:00] Ignite node stopped OK [uptime=00:00:00.876]
> >>> Example finished, press 'Enter' to exit ...
> {code}
> Output with 0 addition nodes
> {code}
> >>> Cache ODBC example started.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> Jane Doe Bachelor Degree. 1300
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Smith Master Degree. 2500
> >>> John Roe Bachelor Degree. 1500
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 900
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1280
> >>> Master Degree. 2366.67
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Jane Doe Microsoft
> >>> John Smith Red Cross
> >>> Jane Smith Red Cross
> >>> John Roe Red Cross
> >>> Jane Roe Red Cross
> >>> Richard Miles Microsoft
> >>> Mary Major Red Cross
> >>> Adjusted salary for Mary Major. Querying again.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> Jane Doe Bachelor Degree. 1300
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Smith Master Degree. 2500
> >>> John Roe Bachelor Degree. 1500
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 1200
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1340
> >>> Master Degree. 2366.67
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Jane Doe Microsoft
> >>> John Smith Red Cross
> >>> Jane Smith Red Cross
> >>> John Roe Red Cross
> >>> Jane Roe Red Cross
> >>> Richard Miles Microsoft
> >>> Mary Major Red Cross
> >>> Removing several employees. Querying again.
> >>> Getting list of persons:
> >>> John Doe Master Degree. 2200
> >>> Jane Doe Bachelor Degree. 1300
> >>> John Smith Bachelor Degree. 1700
> >>> Jane Roe Bachelor Degree. 1000
> >>> Richard Miles Master Degree. 2400
> >>> Mary Major Bachelor Degree. 1200
> >>> Getting average salary by degree:
> >>> Bachelor Degree. 1300
> >>> Master Degree. 2300
> >>> Getting people with organizations:
> >>> John Doe Microsoft
> >>> Jane Doe Microsoft
> >>> John Smith Red Cross
> >>> Jane Roe Red Cross
> >>> Richard Miles Microsoft
> >>> Mary Major Red Cross
> [12:08:42] Ignite node stopped OK [uptime=00:00:00.687]
> >>> Example finished, press 'Enter' to exit ...
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13491) Fix incorrect topology snapshot logger output about coordinator change.
[
https://issues.apache.org/jira/browse/IGNITE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13491:
Fix Version/s: 2.9.1
> Fix incorrect topology snapshot logger output about coordinator change.
> ---
>
> Key: IGNITE-13491
> URL: https://issues.apache.org/jira/browse/IGNITE-13491
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Surkov Aleksandr
>Priority: Minor
> Labels: 2.9.1-rc, newbie
> Fix For: 2.10, 2.9.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, logic in
> {{org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#topologySnapshotMessage}}
> has major drawback, in condition we don't check that failed node with order
> less than oldest server node, is actually server node. So we can see invalid
> message about coordinator change, even though previous node was a client.
> Reproducer:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #2 and client
> We will see in logs of server #2 something like this:
> {{[2020-09-29 10:41:25,909][INFO
> ][disco-event-worker-#150%tcp.TcpDiscoverySpiMBeanTest2%|#150%tcp.TcpDiscoverySpiMBeanTest2%][GridDiscoveryManager]
> Coordinator changed [prev=TcpDiscoveryNode
> [id=371896fb-f612-4640-bfcd-cef6d281,
> consistentId=371896fb-f612-4640-bfcd-cef6d281, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=2,
> intOrder=2, lastExchangeTime=1601365285287, loc=false,
> ver=2.10.0#20200929-sha1:, *isClient=true*], cur=TcpDiscoveryNode
> [id=9d90f4b0-1374-4147-b7a7-d821f002, consistentId=127.0.0.1:47501,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501],
> discPort=47501, order=3, intOrder=3, lastExchangeTime=1601365285900,
> loc=true, ver=2.10.0#20200929-sha1:, isClient=false]]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13495) ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as coordinator
[
https://issues.apache.org/jira/browse/IGNITE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13495:
Fix Version/s: 2.9.1
> ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return invalid node as
> coordinator
>
>
> Key: IGNITE-13495
> URL: https://issues.apache.org/jira/browse/IGNITE-13495
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: 2.9.1-rc, newbie, zookeeper
> Fix For: 2.10, 2.9.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Due to invalid algorithm in
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> sometimes invalid coordinator could be returned
> Consider scenarion:
> 1. Start server #1
> 2. Start client
> 3. Start server #2
> 4. Stop server #1
> After this, {{ZookeeperDiscoverySpiMBeanImpl#getCoordinator}} returns as
> coordinator a client, because it is the oldest node in topology.
> We should fix
> {{org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl#getCoordinator}}
> to return *oldest server*, not any node.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13488) Add command to control.(sh|bin) to get an arbitrary Metric
[
https://issues.apache.org/jira/browse/IGNITE-13488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13488:
Fix Version/s: 2.9.1
> Add command to control.(sh|bin) to get an arbitrary Metric
> --
>
> Key: IGNITE-13488
> URL: https://issues.apache.org/jira/browse/IGNITE-13488
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> It's needed to add the ability to get an arbitrary Metric via
> control.(sh|bin) script.
> If name of the metric registry is passed, value of all its metrics should be
> printed.
> Proposed command structure:
> {code:java}
> control.(sh|bat) --metric [--node-id node_id] name
> Parameters:
> name - Name of the metric which value should be printed. If name of
> the metric registry is specified, value of all its metrics will be printed.
> node_id - ID of the node to get the metric value from. If not set,
> random node will be chosen.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13536) .NET: Child processes become zombies when persistence is used with direct-io on Linux
[ https://issues.apache.org/jira/browse/IGNITE-13536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13536: Fix Version/s: 2.9.1 > .NET: Child processes become zombies when persistence is used with direct-io > on Linux > - > > Key: IGNITE-13536 > URL: https://issues.apache.org/jira/browse/IGNITE-13536 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Attachments: IgnitePersistenceProcessHangTest.csproj, Program.cs, > Runner.java, pom.xml > > Original Estimate: 6h > Time Spent: 4h 20m > Remaining Estimate: 0h > > After using Ignite with direct-io optional module and persistence enabled, > user code hangs when trying to kill a child process and wait for it to exit > using base class library classes (Process). > See attached reproducer: > * Copy .cs and .csproj files to a folder > * dotnet run > The program hangs forever on the last line (process.WaitForExit()), and the > child process becomes a zombie (defunct). > * Similar Java program (see attachments) does not reproduce the issue -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13534) Using a Deprecated method and uninformative message in console
[
https://issues.apache.org/jira/browse/IGNITE-13534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13534:
Fix Version/s: 2.9.1
> Using a Deprecated method and uninformative message in console
> --
>
> Key: IGNITE-13534
> URL: https://issues.apache.org/jira/browse/IGNITE-13534
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Ilya Kazakov
>Assignee: Ilya Kazakov
>Priority: Minor
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When cluster started in INACTIVE status in console writes uninformative
> message:
> {code:java}
> >>> Ignite cluster is not active (limited functionality available). Use
> >>> control.(sh|bat) script or IgniteCluster interface to activate.{code}
> This message contains two words "active" and not contain word "state".
> From this message, users try use deprecated IgniteCluster.active(boolean
> active), but need to use IgniteCluster.state(ClusterState newState)
> Also there are 3 calls of this deprecated method IgniteCluster.active in
> IgniteKernal.class
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13500) Checkpoint read lock fail if it is taking under write lock during the stopping node
[
https://issues.apache.org/jira/browse/IGNITE-13500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13500:
Fix Version/s: 2.9.1
> Checkpoint read lock fail if it is taking under write lock during the
> stopping node
> ---
>
> Key: IGNITE-13500
> URL: https://issues.apache.org/jira/browse/IGNITE-13500
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.ignite.internal.processors.cache.index.BasicIndexTest#testDynamicIndexesDropWithPersistence
> {noformat}
> [2020-09-30
> 15:09:26,085][ERROR][db-checkpoint-thread-#371%index.BasicIndexTest0%][Checkpointer]
> Runtime error caught during grid runnable execution: GridWorker
> [name=db-checkpoint-thread, igniteInstanceName=index.BasicIndexTest0,
> finished=false, heartbeatTs=1601467766063, hashCode=963964001,
> interrupted=false, runner=db-checkpoint-thread-#371%index.BasicIndexTest0%]
> class org.apache.ignite.IgniteException: Failed to perform cache update: node
> is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:396)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:263)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to perform cache
> update: node is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointTimeoutLock.checkpointReadLock(CheckpointTimeoutLock.java:128)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1298)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.removeDurableBackgroundTask(DurableBackgroundTasksProcessor.java:245)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.onMarkCheckpointBegin(DurableBackgroundTasksProcessor.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:274)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:387)
> ... 3 more
> Caused by: class org.apache.ignite.internal.NodeStoppingException: Failed to
> perform cache update: node is stopping.
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13575) Invalid blocking section in GridNioWorker and GridNioClientWorker leads to false positive blocking thread detection
[
https://issues.apache.org/jira/browse/IGNITE-13575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13575:
Fix Version/s: 2.9.1
> Invalid blocking section in GridNioWorker and GridNioClientWorker leads to
> false positive blocking thread detection
> ---
>
> Key: IGNITE-13575
> URL: https://issues.apache.org/jira/browse/IGNITE-13575
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If {{IGNITE_SYSTEM_WORKER_BLOCKED_TIMEOUT}} less than 2000 ms, then simple
> {{epoll_wait}} for 2000 on idle cluster is considered as critical failure.
> We should surround {{selector.select}} with {{blockingSectionBegin}} and
> {{blockingSectionEnd}} instead of {{updateHeartbeat}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13601) Ignite-rest-http and ignite-kubernetes include vulnerable dependencies
[ https://issues.apache.org/jira/browse/IGNITE-13601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13601: Fix Version/s: 2.9.1 > Ignite-rest-http and ignite-kubernetes include vulnerable dependencies > -- > > Key: IGNITE-13601 > URL: https://issues.apache.org/jira/browse/IGNITE-13601 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.8.1 >Reporter: Andrew Story >Priority: Blocker > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > > The ignite-rest-http and ignite-kubernetes modules include a vulnerable > version of the jackson-databind library. This was spotted in 2.8.1. > This component jackson-databind-2.9.6.jar is flagged as having numerous > critical, high and medium security vulnerabilities, one of which is > described here: > [https://nvd.nist.gov/vuln/detail/CVE-2019-14540] > More here: > [http://apache-ignite-users.70518.x6.nabble.com/Critical-security-vulnerability-for-opt-ignite-apache-ignite-libs-optional-ignite-rest-http-jackson-r-td34032.html] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13540) Exchange worker, waiting for new task from queue, considered as blocked.
[
https://issues.apache.org/jira/browse/IGNITE-13540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13540:
Fix Version/s: 2.9.1
> Exchange worker, waiting for new task from queue, considered as blocked.
>
>
> Key: IGNITE-13540
> URL: https://issues.apache.org/jira/browse/IGNITE-13540
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Waiting for new task in ExchangeWorker#body now is not marking as blocking
> section.
> So if network timeout (timeout for polling task from queue) is greater than
> system worker blocked timeout, exchange worker thread is considered as
> blocking. Sometimes this is reported in logs after few seconds when actually
> PME has been finished
> {noformat}
> [2020-10-06 16:55:45,939][INFO
> ][exchange-worker-#50][org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager1]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=6, minorTopVer=1], force=false, evt=DISCOVERY_CUSTOM_EVT,
> node=163fd0f0-b9a4-4317-a28f-f7dbdb776076]
> [2020-10-06 16:55:48,822][ERROR][tcp-disco-msg-worker-[9e18957a
> 172.18.0.5:47500]-#2-#44][org.apache.ignite.internal.util.typedef.G1] Blocked
> system-critical thread has been detected. This can lead to cluster-wide
> undefined behaviour [workerName=partition-exchanger,
> threadName=exchange-worker-#50, blockedFor=2s]
> [2020-10-06 16:55:48,824][WARN ][tcp-disco-msg-worker-[9e18957a
> 172.18.0.5:47500]-#2-#44][org.apache.ignite.internal.util.typedef.G1] Thread
> [name="exchange-worker-#50", id=90, state=TIMED_WAITING, blockCnt=20,
> waitCnt=48]
> Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@14f29e0e,
> ownerName=null, ownerId=-1]
> [2020-10-06 16:55:48,827][WARN ][tcp-disco-msg-worker-[9e18957a
> 172.18.0.5:47500]-#2-#44][root1] Possible failure suppressed accordingly to a
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=partition-exchanger,
> igniteInstanceName=null, finished=false, heartbeatTs=1601992545941]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=partition-exchanger, igniteInstanceName=null, finished=false,
> heartbeatTs=1601992545941]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$3.apply(IgnitionEx.java:1860)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$3.apply(IgnitionEx.java:1855)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:234)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:299)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13563) Deserializing IBinaryObject containing an IBinaryObject field fails
[
https://issues.apache.org/jira/browse/IGNITE-13563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13563:
Fix Version/s: 2.9.1
> Deserializing IBinaryObject containing an IBinaryObject field fails
> ---
>
> Key: IGNITE-13563
> URL: https://issues.apache.org/jira/browse/IGNITE-13563
> Project: Ignite
> Issue Type: Bug
> Components: binary, platforms
>Affects Versions: 2.8.1
> Environment: Arch Linux (updated Oct 5): Linux 5.8.12, DotNet
> 3.1.108, OpenJDK 1.8.0_265.
>Reporter: Bojidar Marinov
>Assignee: Bojidar Marinov
>Priority: Major
> Labels: .NET, 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Attachments: 0001-Fix-IBinaryObject-Deserialize.patch, Program.cs
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When one has a data object which has an IBinaryObject property, like so:
> {code:c#}
> class Model {
> public IBinaryObject Value { get; set; }
> }
> {code}
> .. and proceeds to fill that property with an IBinaryObject of an unknown
> type (e.g. a binary object from a cache that has WithKeepBinary on):
> {code:c#}
> var binary = ignite.GetBinary();
> var model = new Model { Value = binary.GetBuilder("nonexistent").Build() };
> {code}
> Then, the resulting object is savable/loadable from caches, as expected:
> {code:c#}
> var cache = ignite.GetOrCreateCache("models");
> cache.Put("model", model);
> var modelFromCache = cache.Get("model"); // Equivalent to model
> {code}
> However, trying to convert the object to IBinaryObject (using ToBinary) and
> then deserializing that manually fails:
> {code:c#}
> var binaryObject = binary.ToBinary(model);
> var modelFromBinary = binaryObject.Deserialize(); // Unknown pair
> [platformId=1, typeId=486454369]
> {code}
> I have attached a program which reproduces the issue.
>
> After investigating the issue, it seems to occur because
> {{BinaryObject.Deserialize()}} uses {{BinaryMode.Deserialize}}. This, in
> turn, causes {{BinaryReader.ReadBinaryObject()}} to call
> {{BinaryReader.Deserialize()}} for the first {{BinaryTypeId.Binary}} object
> found (while switching to {{BinaryMode.KeepBinary}} for nested objects).
> Then, {{BinaryReader.ReadFullObject()}} gets called, and not knowing better,
> tries to deserialize the object of a nonexistent type.
> Now, {{BinaryMode.Deserialize}} is also used by {{CacheClient}}. However,
> upon further investigation of the values passed to {{Marshaller.Unmarshall}},
> {{CacheClient}} unmarshalls values starting with {{BinaryTypeId.Binary}},
> while {{BinaryObject}} unmarshalls values starting directly with
> {{BinaryUtils.HdrFull}}; thus, {{BinaryReader}} functions correctly for
> caches but fails with binary objects.
> Due to the this, I think the proper fix would be to change
> {{BinaryObject.Deserialize()}} to use {{BinaryMode.KeepBinary}}. I have
> attached a patch file containing that fix and an accompanying test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13569) disable archiving + walCompactionEnabled probably broke reading from wal on server restart
[
https://issues.apache.org/jira/browse/IGNITE-13569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13569:
Fix Version/s: 2.9.1
> disable archiving + walCompactionEnabled probably broke reading from wal on
> server restart
> --
>
> Key: IGNITE-13569
> URL: https://issues.apache.org/jira/browse/IGNITE-13569
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> * Start cluster with 4 server node
> * Preload
> * Start 4 clients
> * Start transactional loading
> * Wait 10 sec
> While loading:
> For node in server nodes:
>Kill -9 node
>Wait 20 sec
>Return node back
>Wait 20 sec
> Looks like node can't read all wal files that was generated before start node
> back
> {noformat}
> [12:50:27,001][SEVERE][wal-file-compressor-%null%-1-#71][FileWriteAheadLogManager]
> Compression of WAL segment [idx=0] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: WAL archive segment is
> missing:
> /storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/.wal
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [12:50:27,001][SEVERE][wal-file-compressor-%null%-0-#69][FileWriteAheadLogManager]
> Compression of WAL segment [idx=2] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: WAL archive segment is
> missing:
> /storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0002.wal
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.access$4800(FileWriteAheadLogManager.java:2019)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.body(FileWriteAheadLogManager.java:1995)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [12:50:27,001][SEVERE][wal-file-compressor-%null%-3-#73][FileWriteAheadLogManager]
> Compression of WAL segment [idx=3] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: WAL archive segment is
> missing:
> /storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0003.wal
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [12:50:27,001][SEVERE][wal-file-compressor-%null%-2-#72][FileWriteAheadLogManager]
> Compression of WAL segment [idx=1] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: WAL archive segment is
> missing:
> /storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0001.wal
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:2076)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:2054)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [12:50:27,002][SEVERE][wal-file-compressor-%null%-1-#71][FileWriteAheadLogManager]
> Compression of WAL segment [idx=4] was skipped due to unexpected error
> class org.apache.ignite.IgniteCheckedException: WAL archive segment is
> missing:
> /storage/ssd/aromantsov/tiden/snapshots-190514-121520/test_pitr/node_1_1/0004.wal
> at
>
[jira] [Commented] (IGNITE-13627) Critical system error when unregister a JMX bean
[
https://issues.apache.org/jira/browse/IGNITE-13627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225457#comment-17225457
]
Ignite TC Bot commented on IGNITE-13627:
{panel:title=Branch: [pull/8410/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8410/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5712587]]
* {color:#013220}IgniteCacheMvccTestSuite9:
MetricsSelfTest.testAddBeforeRemoveCompletes - PASSED{color}
{color:#8b}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5712255]]
* {color:#013220}IgniteCacheTestSuite9:
MetricsSelfTest.testAddBeforeRemoveCompletes - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5712304buildTypeId=IgniteTests24Java8_RunAll]
> Critical system error when unregister a JMX bean
>
>
> Key: IGNITE-13627
> URL: https://issues.apache.org/jira/browse/IGNITE-13627
> Project: Ignite
> Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: 2.9.1-rc
> Fix For: 2.10, 2.9.1
>
> Attachments: logs.zip
>
>
> Critical system error when unregister a JMX bean
> {noformat}
> [2020-10-26T14:10:55,411][ERROR][disco-event-worker-#71][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.AssertionError]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.spi.metric.jmx.JmxMetricExporterSpi.unregister(JmxMetricExporterSpi.java:110)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.notifyListeners(IgniteUtils.java:11740)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:418)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.removeMetricRegistry(GridManagerAdapter.java:615)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationMetricsListener.onNodeLeft(TcpCommunicationMetricsListener.java:399)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationDiscoveryEventListener.onNodeLeft(CommunicationDiscoveryEventListener.java:77)
> ~[classes/:?]
> at
> org.apache.ignite.spi.communication.tcp.internal.CommunicationDiscoveryEventListener.onEvent(CommunicationDiscoveryEventListener.java:62)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1399)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:894)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:877)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:350)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:313)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:2889)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3105)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2909)
> [classes/:?]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [classes/:?]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_202]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber. "You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. If no address set, all available IP addresses are automaticall picked up. Several addresses prolong failure detection of current node. The timeouts and settings on network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt) work per address. The exception is connRecoveryTimeout. Example: if you have 3 ip addresses configured for a node, Tcp Discovery takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect failure of this node". was: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber. "You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. Several addresses prolong failure detection of current node. The timeouts and settings on network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt) work per connection/address. The exception is connRecoveryTimeout. Example: if you have 3 ip addresses configured for a node, Tcp Discovery takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect failure of this node". > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > failureDetectionTimeout * addressesNumber. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. If no address set, > all available IP addresses are automaticall picked up. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt) work per address. The exception is > connRecoveryTimeout. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber. "You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. Several addresses prolong failure detection of current node. The timeouts and settings on network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt) work per connection/address. The exception is connRecoveryTimeout. Example: if you have 3 ip addresses configured for a node, Tcp Discovery takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect failure of this node". > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > failureDetectionTimeout * addressesNumber. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt) work per connection/address. The exception is > connRecoveryTimeout. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to 'failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node". -- This message was sent by Atlassian Jira (v8.3.4#803005)
