[jira] [Created] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
Taras Ledkov created IGNITE-14441: - Summary: Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy Key: IGNITE-14441 URL: https://issues.apache.org/jira/browse/IGNITE-14441 Project: Ignite Issue Type: Bug Components: sql Reporter: Taras Ledkov Assignee: Taras Ledkov Fix For: 2.11 Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. Now query parameters may be printed in the query plan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14440) Run external tests in ducktape
[
https://issues.apache.org/jira/browse/IGNITE-14440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311214#comment-17311214
]
Anton Vinogradov commented on IGNITE-14440:
---
[~timonin.maksim],
{{# /opt/ignite-* - all distributives.}}
Can we just keep this as docker image content?
> Run external tests in ducktape
> --
>
> Key: IGNITE-14440
> URL: https://issues.apache.org/jira/browse/IGNITE-14440
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Priority: Major
> Labels: IEP-56
>
> Docker with ducktape should have following volumes:
> # ignite-dev -> Ignite current branch
> # ignite-lib -> python lib + java deps in modules/ducktests/tests/ignitetest
> # ignite-tests -> python tests, default - modules/ducktests/ignitetest/tests
> # ignite-specs -> specs for tests, structure of directories contain specs
> (incl. jinja2 templates) should be redefined. Set default value for new
> directory within ignitetest.
> # /opt/ignite-* - all distributives.
> Mount with python libs (lib, tests, specs) must be installed in docker as
> develop lib (see, python setup.py develop). Notes:
> # Ordering of installing matters - lib, specs, tests
> # ignitetest - Manifest.in should skip directories: ./tests, with specs.
> There should be an util that responsible for uploading ignite dists. Note:
> # Provide a migration mode for the util. Try copy distributives from
> existing docker image to local fs to skip downloading them from Internet.
> # Download new versions by running .sh command.
>
> *Nice to have:* replace runtests.sh and ducker-ignite with:
> # docker-compose.yml describes num of containers, mounts, ports, etc.
> # entrypoint for docker is a ducktape command.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14442) IgniteRunner fails with NPE after REST module was broken by incompatible changes.
Ivan Bessonov created IGNITE-14442: -- Summary: IgniteRunner fails with NPE after REST module was broken by incompatible changes. Key: IGNITE-14442 URL: https://issues.apache.org/jira/browse/IGNITE-14442 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14435) Refactor PdsConsistentIdProcessor for reusage
[
https://issues.apache.org/jira/browse/IGNITE-14435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-14435:
Assignee: Nikolay Izhikov
> Refactor PdsConsistentIdProcessor for reusage
> -
>
> Key: IGNITE-14435
> URL: https://issues.apache.org/jira/browse/IGNITE-14435
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> Logic to resolve PDS folders should be reused inside {{IgniteCDC}} to lock
> specific Ignite node CDC folder.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14437) Adjust test params: exclude input net failures with disabled connRecovery
[ https://issues.apache.org/jira/browse/IGNITE-14437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-14437. --- Resolution: Fixed > Adjust test params: exclude input net failures with disabled connRecovery > - > > Key: IGNITE-14437 > URL: https://issues.apache.org/jira/browse/IGNITE-14437 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > INPUT network failures are incosistent with disabled connection recovery in > the ducktests. Alive node can be thrown out the ring. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14437) Adjust test params: exclude input net failures with disabled connRecovery
[ https://issues.apache.org/jira/browse/IGNITE-14437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311239#comment-17311239 ] Anton Vinogradov commented on IGNITE-14437: --- Merged into ignite-ducktape. Thanks for your contribution. > Adjust test params: exclude input net failures with disabled connRecovery > - > > Key: IGNITE-14437 > URL: https://issues.apache.org/jira/browse/IGNITE-14437 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > INPUT network failures are incosistent with disabled connection recovery in > the ducktests. Alive node can be thrown out the ring. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14441: -- Release Note: Write sensitive SQL information (queries and plans) to log according with the IGNITE_TO_STRING_INCLUDE_SENSITIVE system property. (was: Write sensitive SQL information (queries and plans) to log according with the IGNITE_SENSITIVE_DATA_LOGGING system property. ) > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. > Now query parameters may be printed in the query plan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-2399) Add asynchronous acquire to IgniteSemaphore
[ https://issues.apache.org/jira/browse/IGNITE-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311290#comment-17311290 ] Dmitry Pavlov commented on IGNITE-2399: --- [~atri] [~vkulichenko], it seems that the test https://ci.ignite.apache.org/test/-3059424454524523197?currentProjectId=IgniteTests24Java8&orderBy=buildStartDate&order=desc&branch=%3Cdefault%3E is started to fail after this PR merge. Could you please check if it is related? > Add asynchronous acquire to IgniteSemaphore > --- > > Key: IGNITE-2399 > URL: https://issues.apache.org/jira/browse/IGNITE-2399 > Project: Ignite > Issue Type: Improvement > Components: data structures >Reporter: Vladisav Jelisavcic >Assignee: Atri Sharma >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > > Usually a permit acquisition is followed by an action, followed by a release > of the permit. A simple enhancement to the existing Semaphore API can be made > that enables asynchronous acquire: > IgniteFuture acquireAndExecute(Callable action, int numPermits); > The method would immediately return a future to be later completed by the > action's result. Permits are to be released after the future is completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14385) Add checkpoit information to performance statistics.
[
https://issues.apache.org/jira/browse/IGNITE-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311293#comment-17311293
]
Ignite TC Bot commented on IGNITE-14385:
{panel:title=Branch: [pull/8928/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8928/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5939710]]
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
CheckpointTest.testCheckpoint - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5940492&buildTypeId=IgniteTests24Java8_RunAll]
> Add checkpoit information to performance statistics.
>
>
> Key: IGNITE-14385
> URL: https://issues.apache.org/jira/browse/IGNITE-14385
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Labels: IEP-35
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add start/end time and other parameters of checkpoint to performance
> statistics.
> Add information about throttling if necessary
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311298#comment-17311298
]
Denis Garus edited comment on IGNITE-14335 at 3/30/21, 9:05 AM:
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
was (Author: garus.d.g):
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
apply a security policy, so authorization does not make sense
authenticate clients, except SQL clients
get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthent
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311298#comment-17311298
]
Denis Garus commented on IGNITE-14335:
--
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
apply a security policy, so authorization does not make sense
authenticate clients, except SQL clients
get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311298#comment-17311298
]
Denis Garus edited comment on IGNITE-14335 at 3/30/21, 9:05 AM:
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
was (Author: garus.d.g):
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> Ignite
[jira] [Commented] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311305#comment-17311305 ] Nikolay Izhikov commented on IGNITE-14441: -- Hello, [~tledkov-gridgain] Can you, please, clarify, why you treat query plan as a sensitive info? Also, please, take a look at the IGNITE-14221 Is this patch you are looking for? > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. > Now query parameters may be printed in the query plan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[ https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311307#comment-17311307 ] Nikolay Izhikov commented on IGNITE-14441: -- I think we should hide only actual values of the query parameters in hiding sensitive mode. The query plan itself is not sensitive info. So I suggest reusing logic implemented in `IgniteH2Indexing#sqlWithoutConst` in `H2QueryInfo#printLogMessage`. > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy > > > Key: IGNITE-14441 > URL: https://issues.apache.org/jira/browse/IGNITE-14441 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Query plan printed for long running query must use > IGNITE_TO_STRING_INCLUDE_SENSITIVE policy. > Now query parameters may be printed in the query plan. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13769) Add examples of using thin client with Ignite Spring Data integration.
[ https://issues.apache.org/jira/browse/IGNITE-13769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311318#comment-17311318 ] Mikhail Petrov commented on IGNITE-13769: - [~NSAmelchev], Thanks a lot for the review. > Add examples of using thin client with Ignite Spring Data integration. > --- > > Key: IGNITE-13769 > URL: https://issues.apache.org/jira/browse/IGNITE-13769 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > It's needed to add examples of using thin client with the Ignite Spring Data > integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14434) Add examples of using thin client with spring-tx-ext
[ https://issues.apache.org/jira/browse/IGNITE-14434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311319#comment-17311319 ] Mikhail Petrov commented on IGNITE-14434: - [~NSAmelchev], Thanks a lot for the review. > Add examples of using thin client with spring-tx-ext > > > Key: IGNITE-14434 > URL: https://issues.apache.org/jira/browse/IGNITE-14434 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > > It's needed to add examples of thin client using with spring-tx-ext > integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311326#comment-17311326 ] Ivan Daschinskiy commented on IGNITE-13405: --- [~iamnotaprogrammer] Ivan, there are some other issues with CacheConfiguration. I fixed all of them (and your also) and add additional tests. Thanks for highlighting this! I realy appreciate your effort. > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14443) Calcite integration. SqlFirstLastValueAggFunction support
Pavel Vinokurov created IGNITE-14443: Summary: Calcite integration. SqlFirstLastValueAggFunction support Key: IGNITE-14443 URL: https://issues.apache.org/jira/browse/IGNITE-14443 Project: Ignite Issue Type: New Feature Components: sql Affects Versions: 3.0.0-alpha1 Reporter: Pavel Vinokurov We need to support aggregation functions, especially SqlFirstLastValueAggFunction that allows simplify and optimize the wide range of sql queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14443) Calcite integration. SqlFirstLastValueAggFunction support
[ https://issues.apache.org/jira/browse/IGNITE-14443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Vinokurov updated IGNITE-14443: - Priority: Major (was: Minor) > Calcite integration. SqlFirstLastValueAggFunction support > - > > Key: IGNITE-14443 > URL: https://issues.apache.org/jira/browse/IGNITE-14443 > Project: Ignite > Issue Type: New Feature > Components: sql >Affects Versions: 3.0.0-alpha1 >Reporter: Pavel Vinokurov >Priority: Major > > We need to support aggregation functions, especially > SqlFirstLastValueAggFunction that allows simplify and optimize the wide range > of sql queries. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13405: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Fix For: python-0.4.0 > > Original Estimate: 1h > Time Spent: 0.5h > Remaining Estimate: 0.5h > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13405) [Pyignite] Invalid cache configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-13405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13405: -- Fix Version/s: python-0.4.0 > [Pyignite] Invalid cache configuration parameters > - > > Key: IGNITE-13405 > URL: https://issues.apache.org/jira/browse/IGNITE-13405 > Project: Ignite > Issue Type: Bug > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Smirnov >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python > Fix For: python-0.4.0 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > Invalid argument for prop_partition_loss_policy in python thin client that > affects the cache creation > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14444) Move affinity calculation and storage to client
Ivan Daschinskiy created IGNITE-1: - Summary: Move affinity calculation and storage to client Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Improvement Components: python Reporter: Ivan Daschinskiy In current implementation, affinity storage and affinity calculation are located in cache. It is not optimal: 1. affinity is not shared between Cache instance with same name 2. affinity mapping requests per cache and add additional loads. 3. if we start implementing transactions or expiry policy, this can be an issue. I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-1: - Assignee: Ivan Daschinskiy > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-1: -- Affects Version/s: python-0.4.0 > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14441) Query plan printed for long running query must use IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
[
https://issues.apache.org/jira/browse/IGNITE-14441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311351#comment-17311351
]
Taras Ledkov commented on IGNITE-14441:
---
[~nizhikov]
Please take a look on the usage of the {{S#includeSensitive}}. The class names
and field names are hidden in log messages.
SQL queries and plans also contains names of the tables & fields and must be
hidden in log messages.
I guess the behavior of hiding sensitive info must be consistent.
I don't see any reason to hide SQL constants at the system views because user
may use parameters for sensitive info and access to system views must check
security permission.
> Query plan printed for long running query must use
> IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
>
>
> Key: IGNITE-14441
> URL: https://issues.apache.org/jira/browse/IGNITE-14441
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Query plan printed for long running query must use
> IGNITE_TO_STRING_INCLUDE_SENSITIVE policy.
> Now query parameters may be printed in the query plan.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311363#comment-17311363 ] Mikhail Petrov commented on IGNITE-14397: - [~nsafonov], could you please take a look? > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14417) Document performance-statistics-ext module
[ https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311364#comment-17311364 ] Amelchev Nikita commented on IGNITE-14417: -- [~dmagda] [~nsafonov] [~PetrovMikhail], Hi. Could you take a look at PR, please? > Document performance-statistics-ext module > -- > > Key: IGNITE-14417 > URL: https://issues.apache.org/jira/browse/IGNITE-14417 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.10 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to document performance-statistics-ext module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14417) Document performance-statistics-ext module
[ https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311380#comment-17311380 ] Nikita Safonov commented on IGNITE-14417: - [~NSAmelchev] Sure! > Document performance-statistics-ext module > -- > > Key: IGNITE-14417 > URL: https://issues.apache.org/jira/browse/IGNITE-14417 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.10 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to document performance-statistics-ext module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311381#comment-17311381 ] Nikita Safonov commented on IGNITE-14397: - [~PetrovMikhail] Sure! > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-14331:
Assignee: Vyacheslav Koptilin
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311410#comment-17311410
]
Ignite TC Bot commented on IGNITE-14394:
{panel:title=Branch: [pull/8934/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8934/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5935653]]
* {color:#013220}IgniteBasicTestSuite:
BaselineAutoAdjustInMemoryTest.testExchangeMerge - PASSED{color}
* {color:#013220}IgniteBasicTestSuite: BaselineAutoAdjustTest.testExchangeMerge
- PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5935715&buildTypeId=IgniteTests24Java8_RunAll]
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311414#comment-17311414
]
Vyacheslav Koptilin commented on IGNITE-14394:
--
Hello [~maliev],
Could you please take a look?
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14394:
-
Reviewer: Mirza Aliev
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311427#comment-17311427
]
Mirza Aliev commented on IGNITE-14394:
--
Hi [~slava.koptilin], changes look good to me, please proceed with merging.
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
Ilya Kasnacheev created IGNITE-14445:
Summary: "Remote node does not observe current" after failure by
not receiving metrics from client
Key: IGNITE-14445
URL: https://issues.apache.org/jira/browse/IGNITE-14445
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Ilya Kasnacheev
A server node might fail a client node due to pauses in the network connection:
[15:07:16,330][WARNING][tcp-disco-msg-worker-[11cf0c06 10.212.120.71:57500
crd]-#2%hh_DynamicGrid_v2%][TcpDiscoverySpi] Failing client node due to not
receiving metrics updates from client node within
'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
configuration property) [timeout=12, node=TcpDiscoveryNode
[id=9dbcfb86-a60e-4382-904f-57bffbe18c5c,consistentId=73B5811B-9644-48FD-A533-B4609FDAD591,
addrs=ArrayList [10.212.120.190], sockAddrs=HashSet
[VWNV02AX07080.HH.com/10.212.120.190:0], discPort=0, order=488, intOrder=248,
lastExchangeTime=1612397142960, loc=false, ver=2.8.1#20200521-sha1:86422096,
isClient=true]]
Then, the client node will never understand that it is dropped by cluster and
will be endlessly trying to connect. I'm not sure what does discovery do on the
client node:
{code}
[15:07:42,689][SEVERE][Thread-219][TcpCommunicationSpi] Failed to send message
to remote node [node=TcpDiscoveryNode [id=83fd7c70-839d-46ca-969f-bbb9661d6ab2,
consistentId=127.1.1.1:57500, addrs=ArrayList [127.1.1.1], sockAddrs=HashSet
[test.com/127.1.1.1:57500], discPort=57500, order=1, intOrder=1,
lastExchangeTime=1612397256785, loc=false, ver=2.8.1#20200521-sha1:86422096,
isClient=false], msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8,
ordered=false, timeout=0, skipOnTimeout=false,
msg=GridNearAtomicFullUpdateRequest [keys=ArrayList [UserKeyCacheObjectImpl
[part=292, val=TestModel:TEST|bbf4da4d-c3d7-4b46-98b6-0de70c30f668,
hasValBytes=true]], conflictTtls=null, conflictExpireTimes=null,
expiryPlc=org.apache.ignite.internal.processors.platform.cache.expiry.PlatformExpiryPolicy@3fb1b76e,
initSize=1, filter=null, parent=GridNearAtomicAbstractUpdateRequest [res=null,
flags=keepBinary
class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
Remote node does not observe current node in topology :
83fd7c70-839d-46ca-969f-bbb9661d6ab2
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioSession(TcpCommunicationSpi.java:3622)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3458)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createCommunicationClient(TcpCommunicationSpi.java:3198)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:3078)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2918)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2877)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:312)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
[
https://issues.apache.org/jira/browse/IGNITE-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14445:
-
Attachment: ignite-server-impl.patch
> "Remote node does not observe current" after failure by not receiving metrics
> from client
> -
>
> Key: IGNITE-14445
> URL: https://issues.apache.org/jira/browse/IGNITE-14445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Ilya Kasnacheev
>Priority: Major
> Attachments: ignite-server-impl.patch
>
>
> A server node might fail a client node due to pauses in the network
> connection:
> [15:07:16,330][WARNING][tcp-disco-msg-worker-[11cf0c06 10.212.120.71:57500
> crd]-#2%hh_DynamicGrid_v2%][TcpDiscoverySpi] Failing client node due to not
> receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=12, node=TcpDiscoveryNode
> [id=9dbcfb86-a60e-4382-904f-57bffbe18c5c,consistentId=73B5811B-9644-48FD-A533-B4609FDAD591,
> addrs=ArrayList [10.212.120.190], sockAddrs=HashSet
> [VWNV02AX07080.HH.com/10.212.120.190:0], discPort=0, order=488, intOrder=248,
> lastExchangeTime=1612397142960, loc=false, ver=2.8.1#20200521-sha1:86422096,
> isClient=true]]
> Then, the client node will never understand that it is dropped by cluster and
> will be endlessly trying to connect. I'm not sure what does discovery do on
> the client node:
> {code}
> [15:07:42,689][SEVERE][Thread-219][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=83fd7c70-839d-46ca-969f-bbb9661d6ab2, consistentId=127.1.1.1:57500,
> addrs=ArrayList [127.1.1.1], sockAddrs=HashSet [test.com/127.1.1.1:57500],
> discPort=57500, order=1, intOrder=1, lastExchangeTime=1612397256785,
> loc=false, ver=2.8.1#20200521-sha1:86422096, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridNearAtomicFullUpdateRequest
> [keys=ArrayList [UserKeyCacheObjectImpl [part=292,
> val=TestModel:TEST|bbf4da4d-c3d7-4b46-98b6-0de70c30f668, hasValBytes=true]],
> conflictTtls=null, conflictExpireTimes=null,
> expiryPlc=org.apache.ignite.internal.processors.platform.cache.expiry.PlatformExpiryPolicy@3fb1b76e,
> initSize=1, filter=null, parent=GridNearAtomicAbstractUpdateRequest
> [res=null, flags=keepBinary
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Remote node does not observe current node in topology :
> 83fd7c70-839d-46ca-969f-bbb9661d6ab2
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioSession(TcpCommunicationSpi.java:3622)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3458)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createCommunicationClient(TcpCommunicationSpi.java:3198)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:3078)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2918)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2877)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
[
https://issues.apache.org/jira/browse/IGNITE-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311465#comment-17311465
]
Ilya Kasnacheev commented on IGNITE-14445:
--
I have created a reproducer for this behavior which will simulate client
segmentation due to metrics update. Apply the patch (attached) and run some
client-using test, such as:
mvn surefire:test -DIGNITE_STOP_NODE=100
-Dtest=IgniteCacheManyClientsTest\#testManyClientsClientDiscovery -pl
:ignite-core
You can use different values with IGNITE_STOP_NODE, such as 0, 20, 50, 100 - to
segment a client node on various stages of life cycle.
> "Remote node does not observe current" after failure by not receiving metrics
> from client
> -
>
> Key: IGNITE-14445
> URL: https://issues.apache.org/jira/browse/IGNITE-14445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Ilya Kasnacheev
>Priority: Major
> Attachments: ignite-server-impl.patch
>
>
> A server node might fail a client node due to pauses in the network
> connection:
> [15:07:16,330][WARNING][tcp-disco-msg-worker-[11cf0c06 10.212.120.71:57500
> crd]-#2%hh_DynamicGrid_v2%][TcpDiscoverySpi] Failing client node due to not
> receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=12, node=TcpDiscoveryNode
> [id=9dbcfb86-a60e-4382-904f-57bffbe18c5c,consistentId=73B5811B-9644-48FD-A533-B4609FDAD591,
> addrs=ArrayList [10.212.120.190], sockAddrs=HashSet
> [VWNV02AX07080.HH.com/10.212.120.190:0], discPort=0, order=488, intOrder=248,
> lastExchangeTime=1612397142960, loc=false, ver=2.8.1#20200521-sha1:86422096,
> isClient=true]]
> Then, the client node will never understand that it is dropped by cluster and
> will be endlessly trying to connect. I'm not sure what does discovery do on
> the client node:
> {code}
> [15:07:42,689][SEVERE][Thread-219][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=83fd7c70-839d-46ca-969f-bbb9661d6ab2, consistentId=127.1.1.1:57500,
> addrs=ArrayList [127.1.1.1], sockAddrs=HashSet [test.com/127.1.1.1:57500],
> discPort=57500, order=1, intOrder=1, lastExchangeTime=1612397256785,
> loc=false, ver=2.8.1#20200521-sha1:86422096, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridNearAtomicFullUpdateRequest
> [keys=ArrayList [UserKeyCacheObjectImpl [part=292,
> val=TestModel:TEST|bbf4da4d-c3d7-4b46-98b6-0de70c30f668, hasValBytes=true]],
> conflictTtls=null, conflictExpireTimes=null,
> expiryPlc=org.apache.ignite.internal.processors.platform.cache.expiry.PlatformExpiryPolicy@3fb1b76e,
> initSize=1, filter=null, parent=GridNearAtomicAbstractUpdateRequest
> [res=null, flags=keepBinary
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Remote node does not observe current node in topology :
> 83fd7c70-839d-46ca-969f-bbb9661d6ab2
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioSession(TcpCommunicationSpi.java:3622)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3458)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createCommunicationClient(TcpCommunicationSpi.java:3198)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:3078)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2918)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2877)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
[
https://issues.apache.org/jira/browse/IGNITE-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311467#comment-17311467
]
Ilya Kasnacheev commented on IGNITE-14445:
--
It will also show different errors, such as assertion error in client:
{code}
[2021-03-30
13:46:05,338][ERROR][tcp-client-disco-msg-worker-#216%distributed.IgniteCacheManyClientsTest8%-#2083%distributed.IgniteCacheManyClientsTest8%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.AssertionError: lastVer=4, newVer=6,
locNode=TcpDiscoveryNode [id=009a68fa-161f-4eef-b7ed-bfb115d8,
consistentId=009a68fa-161f-4eef-b7ed-bfb115d8, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=0, intOrder=0,
lastExchangeTime=1617101161213, loc=true, ver=2.9.1#20210115-sha1:de970af4,
isClient=true], msg=TcpDiscoveryNodeAddFinishedMessage
[nodeId=c4c43b12-3293-4fbd-948d-acd211b4, super=TcpDiscoveryAbstractMessage
[sndNodeId=e278b5eb-2faf-4602-844f-d7046720,
id=b0a5db28871-e278b5eb-2faf-4602-844f-d7046720,
verifierNodeId=e278b5eb-2faf-4602-844f-d7046720, topVer=6, pendingIdx=0,
failedNodes=null, isClient=false
java.lang.AssertionError: lastVer=4, newVer=6, locNode=TcpDiscoveryNode
[id=009a68fa-161f-4eef-b7ed-bfb115d8,
consistentId=009a68fa-161f-4eef-b7ed-bfb115d8, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:0], discPort=0, order=0, intOrder=0,
lastExchangeTime=1617101161213, loc=true, ver=2.9.1#20210115-sha1:de970af4,
isClient=true], msg=TcpDiscoveryNodeAddFinishedMessage
[nodeId=c4c43b12-3293-4fbd-948d-acd211b4, super=TcpDiscoveryAbstractMessage
[sndNodeId=e278b5eb-2faf-4602-844f-d7046720,
id=b0a5db28871-e278b5eb-2faf-4602-844f-d7046720,
verifierNodeId=e278b5eb-2faf-4602-844f-d7046720, topVer=6, pendingIdx=0,
failedNodes=null, isClient=false]]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.updateTopologyHistory(ClientImpl.java:912)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.access$3700(ClientImpl.java:146)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:2366)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:2149)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1988)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$1.body(ClientImpl.java:307)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
{code}
Or, more important, NPE in server node:
{code}
[2021-03-30
14:07:05,133][ERROR][sys-#161%distributed.IgniteCacheManyClientsTest2%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class o.a.i.IgniteCheckedException: null]]
class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7563)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:837)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
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)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.IgniteFeatures.nodeSupports(IgniteFeatures.java:160)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$TxRecoveryInitRunnable.isMvccRecoveryMessageRequired(IgniteTxManager.java:3335)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$TxRecoveryInitRunnable.run(IgniteTxManager.java:3246)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7117)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
... 4 more
{code}
Maybe we should make a crazy monkey test out of it.
> "Remote node does not observe current" after failure by not receiving metrics
> from client
> -
>
>
[jira] [Updated] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
[
https://issues.apache.org/jira/browse/IGNITE-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14445:
-
Attachment: simulated-log.txt.gz
> "Remote node does not observe current" after failure by not receiving metrics
> from client
> -
>
> Key: IGNITE-14445
> URL: https://issues.apache.org/jira/browse/IGNITE-14445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Ilya Kasnacheev
>Priority: Major
> Attachments: ignite-server-impl.patch, simulated-log.txt.gz
>
>
> A server node might fail a client node due to pauses in the network
> connection:
> [15:07:16,330][WARNING][tcp-disco-msg-worker-[11cf0c06 10.212.120.71:57500
> crd]-#2%hh_DynamicGrid_v2%][TcpDiscoverySpi] Failing client node due to not
> receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=12, node=TcpDiscoveryNode
> [id=9dbcfb86-a60e-4382-904f-57bffbe18c5c,consistentId=73B5811B-9644-48FD-A533-B4609FDAD591,
> addrs=ArrayList [10.212.120.190], sockAddrs=HashSet
> [VWNV02AX07080.HH.com/10.212.120.190:0], discPort=0, order=488, intOrder=248,
> lastExchangeTime=1612397142960, loc=false, ver=2.8.1#20200521-sha1:86422096,
> isClient=true]]
> Then, the client node will never understand that it is dropped by cluster and
> will be endlessly trying to connect. I'm not sure what does discovery do on
> the client node:
> {code}
> [15:07:42,689][SEVERE][Thread-219][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=83fd7c70-839d-46ca-969f-bbb9661d6ab2, consistentId=127.1.1.1:57500,
> addrs=ArrayList [127.1.1.1], sockAddrs=HashSet [test.com/127.1.1.1:57500],
> discPort=57500, order=1, intOrder=1, lastExchangeTime=1612397256785,
> loc=false, ver=2.8.1#20200521-sha1:86422096, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridNearAtomicFullUpdateRequest
> [keys=ArrayList [UserKeyCacheObjectImpl [part=292,
> val=TestModel:TEST|bbf4da4d-c3d7-4b46-98b6-0de70c30f668, hasValBytes=true]],
> conflictTtls=null, conflictExpireTimes=null,
> expiryPlc=org.apache.ignite.internal.processors.platform.cache.expiry.PlatformExpiryPolicy@3fb1b76e,
> initSize=1, filter=null, parent=GridNearAtomicAbstractUpdateRequest
> [res=null, flags=keepBinary
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Remote node does not observe current node in topology :
> 83fd7c70-839d-46ca-969f-bbb9661d6ab2
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioSession(TcpCommunicationSpi.java:3622)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3458)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createCommunicationClient(TcpCommunicationSpi.java:3198)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:3078)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2918)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2877)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14445) "Remote node does not observe current" after failure by not receiving metrics from client
[
https://issues.apache.org/jira/browse/IGNITE-14445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14445:
-
Affects Version/s: 2.8.1
> "Remote node does not observe current" after failure by not receiving metrics
> from client
> -
>
> Key: IGNITE-14445
> URL: https://issues.apache.org/jira/browse/IGNITE-14445
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1, 2.9.1
>Reporter: Ilya Kasnacheev
>Priority: Major
> Attachments: ignite-server-impl.patch, simulated-log.txt.gz
>
>
> A server node might fail a client node due to pauses in the network
> connection:
> [15:07:16,330][WARNING][tcp-disco-msg-worker-[11cf0c06 10.212.120.71:57500
> crd]-#2%hh_DynamicGrid_v2%][TcpDiscoverySpi] Failing client node due to not
> receiving metrics updates from client node within
> 'IgniteConfiguration.clientFailureDetectionTimeout' (consider increasing
> configuration property) [timeout=12, node=TcpDiscoveryNode
> [id=9dbcfb86-a60e-4382-904f-57bffbe18c5c,consistentId=73B5811B-9644-48FD-A533-B4609FDAD591,
> addrs=ArrayList [10.212.120.190], sockAddrs=HashSet
> [VWNV02AX07080.HH.com/10.212.120.190:0], discPort=0, order=488, intOrder=248,
> lastExchangeTime=1612397142960, loc=false, ver=2.8.1#20200521-sha1:86422096,
> isClient=true]]
> Then, the client node will never understand that it is dropped by cluster and
> will be endlessly trying to connect. I'm not sure what does discovery do on
> the client node:
> {code}
> [15:07:42,689][SEVERE][Thread-219][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=83fd7c70-839d-46ca-969f-bbb9661d6ab2, consistentId=127.1.1.1:57500,
> addrs=ArrayList [127.1.1.1], sockAddrs=HashSet [test.com/127.1.1.1:57500],
> discPort=57500, order=1, intOrder=1, lastExchangeTime=1612397256785,
> loc=false, ver=2.8.1#20200521-sha1:86422096, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridNearAtomicFullUpdateRequest
> [keys=ArrayList [UserKeyCacheObjectImpl [part=292,
> val=TestModel:TEST|bbf4da4d-c3d7-4b46-98b6-0de70c30f668, hasValBytes=true]],
> conflictTtls=null, conflictExpireTimes=null,
> expiryPlc=org.apache.ignite.internal.processors.platform.cache.expiry.PlatformExpiryPolicy@3fb1b76e,
> initSize=1, filter=null, parent=GridNearAtomicAbstractUpdateRequest
> [res=null, flags=keepBinary
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Remote node does not observe current node in topology :
> 83fd7c70-839d-46ca-969f-bbb9661d6ab2
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioSession(TcpCommunicationSpi.java:3622)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3458)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createCommunicationClient(TcpCommunicationSpi.java:3198)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:3078)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2918)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2877)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2035)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2132)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:312)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-14347:
--
Assignee: Atri Sharma
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
> nodeConfiguration().setClien
[jira] [Created] (IGNITE-14446) Implement simple version of watching mechanism
Kirill Gusakov created IGNITE-14446: --- Summary: Implement simple version of watching mechanism Key: IGNITE-14446 URL: https://issues.apache.org/jira/browse/IGNITE-14446 Project: Ignite Issue Type: Sub-task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14417) Document performance-statistics-ext module
[
https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311533#comment-17311533
]
Ignite TC Bot commented on IGNITE-14417:
{panel:title=Branch: [pull/8940/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8940/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5940988&buildTypeId=IgniteTests24Java8_RunAll]
> Document performance-statistics-ext module
> --
>
> Key: IGNITE-14417
> URL: https://issues.apache.org/jira/browse/IGNITE-14417
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.10
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> It's needed to document performance-statistics-ext module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14433) Update README file for the performance statistics extension
[
https://issues.apache.org/jira/browse/IGNITE-14433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311534#comment-17311534
]
Amelchev Nikita commented on IGNITE-14433:
--
[~PetrovMikhail], thanks for the review.
Merged to the master.
> Update README file for the performance statistics extension
> ---
>
> Key: IGNITE-14433
> URL: https://issues.apache.org/jira/browse/IGNITE-14433
> Project: Ignite
> Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
>
> Document the {{print-statistics.sh}} script.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14417) Document performance-statistics-ext module
[ https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311536#comment-17311536 ] Amelchev Nikita commented on IGNITE-14417: -- [~nsafonov], [~PetrovMikhail], thanks for the review. Merged to the master. > Document performance-statistics-ext module > -- > > Key: IGNITE-14417 > URL: https://issues.apache.org/jira/browse/IGNITE-14417 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.10 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Time Spent: 4h > Remaining Estimate: 0h > > It's needed to document performance-statistics-ext module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14417) Document performance-statistics-ext module
[ https://issues.apache.org/jira/browse/IGNITE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14417: - Fix Version/s: 2.10 > Document performance-statistics-ext module > -- > > Key: IGNITE-14417 > URL: https://issues.apache.org/jira/browse/IGNITE-14417 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.10 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.10 > > Time Spent: 4h > Remaining Estimate: 0h > > It's needed to document performance-statistics-ext module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14446) Implement DMS manager with watch registry
[ https://issues.apache.org/jira/browse/IGNITE-14446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-14446: Summary: Implement DMS manager with watch registry (was: Implement simple version of watching mechanism) > Implement DMS manager with watch registry > - > > Key: IGNITE-14446 > URL: https://issues.apache.org/jira/browse/IGNITE-14446 > Project: Ignite > Issue Type: Sub-task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14444) Move affinity calculation and storage to client
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311680#comment-17311680 ] Ivan Daschinskiy commented on IGNITE-1: --- [~isapego] Hi, patch is ready for review > Move affinity calculation and storage to client > --- > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Improvement > Components: python >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Labels: python > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In current implementation, affinity storage and affinity calculation are > located in cache. > It is not optimal: > 1. affinity is not shared between Cache instance with same name > 2. affinity mapping requests per cache and add additional loads. > 3. if we start implementing transactions or expiry policy, this can be an > issue. > I propose to move affinity storage to Client and AioClient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312062#comment-17312062
]
Atri Sharma commented on IGNITE-14347:
--
[~sdanilov] Can we merge this, please?
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> Ign
[jira] [Commented] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[
https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312070#comment-17312070
]
Atri Sharma commented on IGNITE-14346:
--
[~ilyak] Updated. I also started an Ignite node after building a release with
the Azure module included.
I did {{mvn clean install -DskipTests}} and then {{mvn initialize -Prelease and
then started the node.}}
> Implement Azure Blob Storage Based IP Finder
>
>
> Key: IGNITE-14346
> URL: https://issues.apache.org/jira/browse/IGNITE-14346
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Labels: ReviewNeeded
> Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot
> 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png,
> Screenshot 2021-03-23 at 8.45.05 PM.png
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14346) Implement Azure Blob Storage Based IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-14346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312071#comment-17312071 ] Atri Sharma commented on IGNITE-14346: -- [~ilyak] Tried with a build after including the Azure directory and the Ignite node started up fine (after the latest iteration). Please see and let me know. > Implement Azure Blob Storage Based IP Finder > > > Key: IGNITE-14346 > URL: https://issues.apache.org/jira/browse/IGNITE-14346 > Project: Ignite > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Labels: ReviewNeeded > Attachments: Screenshot 2021-03-23 at 8.42.31 PM.png, Screenshot > 2021-03-23 at 8.43.31 PM.png, Screenshot 2021-03-23 at 8.44.11 PM.png, > Screenshot 2021-03-23 at 8.45.05 PM.png > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14383) No need to update metastorage if cache statistics disabled.
[ https://issues.apache.org/jira/browse/IGNITE-14383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny resolved IGNITE-14383. - Resolution: Not A Problem > No need to update metastorage if cache statistics disabled. > --- > > Key: IGNITE-14383 > URL: https://issues.apache.org/jira/browse/IGNITE-14383 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Id cache statistics disabled there is no need to update metastorage and send > numerous DistributedMetaStorageUpdateMessage as a result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14447) Invalid meta page can be used after index re-creation
Ivan Bessonov created IGNITE-14447: -- Summary: Invalid meta page can be used after index re-creation Key: IGNITE-14447 URL: https://issues.apache.org/jira/browse/IGNITE-14447 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 2.11 Consider the following scenario: * A user creates index "A" * Ignite allocates page 0x1234 as the index meta page and writes it to the index roots tree * Index is populated, query entity is written on disk * Checkpoint is triggered and the index pages (including root) are written to disk * User drops the index * The tree is deallocated, the meta page is removed from the roots tree, query entity without the index is written to disk. No logical record is written for the roots tree. * Node crashes without checkpoint being marked * Node restarts. Since the query entity does not contain the index "A", the index tree is not created * User deletes some entries, then attempts to create the index "A" again * Since the node did not trigger checkpoint before the crash and no logical record was written, the root tree contains obsolete tree with links pointing to non-existing data (namely, index "A" still refers to page 0x1234) * Depending on allocation pattern and enabled assertions flag, the node will either fail with an assertion, or will crash the JVM Fundamentally, the issue is caused by inconsistency between index roots tree and query entity. Ideally, we should move cache configuration to page memory subsystem, but this may be a big change. We should check whether writing a logical record on index drop that will run the index cleanup on recovery mitigates the issue (in other words, the index cleanup persistent task should be triggered even if no checkpoint was marked after query entity is persisted). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312116#comment-17312116
]
Ivan Bessonov commented on IGNITE-14347:
[~atri] I'll merge it, thank you for the contribution!
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedExcep
[jira] [Updated] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14347:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> I
[jira] [Commented] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312119#comment-17312119
]
Ivan Bessonov commented on IGNITE-14347:
[~atri] by the way, I see that you completely copied
https://issues.apache.org/jira/browse/IGNITE-13642 instead of assigning it to
yourself, what was your motivation?
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Improvement
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The f
[jira] [Resolved] (IGNITE-13642) Nodes fail when they meet objects of unknown type in metastorage
[
https://issues.apache.org/jira/browse/IGNITE-13642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov resolved IGNITE-13642.
Resolution: Duplicate
> Nodes fail when they meet objects of unknown type in metastorage
>
>
> Key: IGNITE-13642
> URL: https://issues.apache.org/jira/browse/IGNITE-13642
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Denis Mekhanikov
>Priority: Blocker
> Labels: 2.9.1-rc
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
> nodeConfiguration().setClientMode(true);
> IgniteKernal ignite = (IgniteKernal) Ignition
[jira] [Updated] (IGNITE-14347) Fix Node failure on Receiving Data of Unknown class via Distributed Metastorage
[
https://issues.apache.org/jira/browse/IGNITE-14347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14347:
---
Issue Type: Bug (was: Improvement)
> Fix Node failure on Receiving Data of Unknown class via Distributed
> Metastorage
> ---
>
> Key: IGNITE-14347
> URL: https://issues.apache.org/jira/browse/IGNITE-14347
> Project: Ignite
> Issue Type: Bug
>Reporter: Atri Sharma
>Assignee: Atri Sharma
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
