[jira] [Assigned] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[
https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-11302:
Assignee: (was: Dmitriy Sorokin)
> idleConnectionTimeout TcpComm different on server and client (client default
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Critical
>
> Server config:
> {code:xml}
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
> Client config
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
> {code}
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to
> config
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[
https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-11302:
Assignee: (was: Dmitriy Sorokin)
> idleConnectionTimeout TcpComm different on server and client (client default
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Priority: Critical
>
> Server config:
> {code:xml}
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
> Client config
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
> {code}
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to
> config
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[
https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-11302:
Assignee: Dmitriy Sorokin
> idleConnectionTimeout TcpComm different on server and client (client default
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Dmitriy Sorokin
>Priority: Critical
>
> Server config:
> {code:xml}
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
> Client config
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
> {code}
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to
> config
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-6300) BinaryObject's set size estimator
[ https://issues.apache.org/jira/browse/IGNITE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-6300: --- Assignee: (was: Dmitriy Sorokin) > BinaryObject's set size estimator > - > > Key: IGNITE-6300 > URL: https://issues.apache.org/jira/browse/IGNITE-6300 > Project: Ignite > Issue Type: New Feature >Reporter: Anton Vinogradov (Obsolete, actual is "av") >Priority: Major > > Need to provide some API to estimate requirements for any data model. > For example: > 1) You have classes A,B and C with known fields and data distribution over > this fields. > 2) You know that you have to keep 1M of A, 2M of B and 45K of C. > 3) BinarySizeEstimator should return you expected memory consumption on > actual Ignite version without starting a node. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-6894) Hanged Tx monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-6894: --- Assignee: (was: Dmitriy Sorokin) > Hanged Tx monitoring > > > Key: IGNITE-6894 > URL: https://issues.apache.org/jira/browse/IGNITE-6894 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov (Obsolete, actual is "av") >Priority: Major > Labels: iep-7 > > Hanging Transactions not Related to Deadlock > Description > This situation can occur if user explicitly markups the transaction (esp > Pessimistic Repeatable Read) and, for example, calls remote service (which > may be unresponsive) after acquiring some locks. All other transactions > depending on the same keys will hang. > Detection and Solution > This most likely cannot be resolved automatically other than rollback TX by > timeout and release all the locks acquired so far. Also such TXs can be > rolled back from Web Console as described above. > If transaction has been rolled back on timeout or via UI then any further > action in the transaction, e.g. lock acquisition or commit attempt should > throw exception. > Report > Management tools (eg. Web Console) should provide ability to rollback any > transaction via UI. > Long running transaction should be reported to logs. Log record should > contain: near nodes, transaction IDs, cache names, keys (limited to several > tens of), etc ( ?). > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the info as above. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-6895: --- Assignee: (was: Dmitriy Sorokin) > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov (Obsolete, actual is "av") >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14477) Ducktape test of rebalance for persistent mode
[
https://issues.apache.org/jira/browse/IGNITE-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14477:
-
Description:
This test should check the rebalance on persistent caches in two scenarios:
# Full rebalance which triggered by two event types: node join and node left
the topology (need to enable baseline auto-adjust and setting the small
baseline auto-adjust timeout).
# Historical rebalance which triggered by joining to cluster of missed node
with existing PDS:
** Build the cluster with persistence enabled and preload data to it.
** Stop one node without baseline change.
** Make new data updates.
** Return leaved node to the cluster.
The both tests should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: rebalance statistics.
was:
This test should check the rebalance on persistent caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology
(need to enable baseline auto-adjust and setting the small baseline auto-adjust
timeout).
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
# WAL rebalance - using WAL (historical) rebalance instead of full rebalance.
Test result: rebalance statistics.
> Ducktape test of rebalance for persistent mode
> --
>
> Key: IGNITE-14477
> URL: https://issues.apache.org/jira/browse/IGNITE-14477
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This test should check the rebalance on persistent caches in two scenarios:
> # Full rebalance which triggered by two event types: node join and node left
> the topology (need to enable baseline auto-adjust and setting the small
> baseline auto-adjust timeout).
> # Historical rebalance which triggered by joining to cluster of missed node
> with existing PDS:
> ** Build the cluster with persistence enabled and preload data to it.
> ** Stop one node without baseline change.
> ** Make new data
[jira] [Updated] (IGNITE-14477) Ducktape test of rebalance for persistent mode
[
https://issues.apache.org/jira/browse/IGNITE-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14477:
-
Description:
This test should check the rebalance on persistent caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology
(need to enable baseline auto-adjust and setting the small baseline auto-adjust
timeout).
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
# WAL rebalance - using WAL (historical) rebalance instead of full rebalance.
Test result: rebalance statistics.
> Ducktape test of rebalance for persistent mode
> --
>
> Key: IGNITE-14477
> URL: https://issues.apache.org/jira/browse/IGNITE-14477
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
>
> This test should check the rebalance on persistent caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology
> (need to enable baseline auto-adjust and setting the small baseline
> auto-adjust timeout).
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> # WAL rebalance - using WAL (historical) rebalance instead of full rebalance.
> Test result: rebalance statistics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14477) Ducktape test of rebalance for persistent mode
Dmitriy Sorokin created IGNITE-14477: Summary: Ducktape test of rebalance for persistent mode Key: IGNITE-14477 URL: https://issues.apache.org/jira/browse/IGNITE-14477 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14319) Multithreaded data generation for rebalance tests
[
https://issues.apache.org/jira/browse/IGNITE-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin resolved IGNITE-14319.
--
Resolution: Won't Fix
> Multithreaded data generation for rebalance tests
> -
>
> Key: IGNITE-14319
> URL: https://issues.apache.org/jira/browse/IGNITE-14319
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
>
> At the moment, {{DataGenerationApplication}} generates data in the single
> thread. We should make that routine multithreaded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14395) Shorter test results directory name
[
https://issues.apache.org/jira/browse/IGNITE-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14395:
-
Description: The large number of parameters and their long names cause the
too long test results directory name, so it is reason to split the test into
two methods (it removes the {{trigger_event}} parameter), and cut off the
prefix {{rebalance_}} from rebalance parameters. (was: The large number of
parameters and their long names cause the too long test results directory name,
so it is reason to split the test into two methods (it removes the
{{trigger_event}} parameter), and cut the prefix of rebalance parameters from
{{rebalance_}} to {{rb_}}.)
> Shorter test results directory name
> ---
>
> Key: IGNITE-14395
> URL: https://issues.apache.org/jira/browse/IGNITE-14395
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The large number of parameters and their long names cause the too long test
> results directory name, so it is reason to split the test into two methods
> (it removes the {{trigger_event}} parameter), and cut off the prefix
> {{rebalance_}} from rebalance parameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14395) Shorter test results directory name
[
https://issues.apache.org/jira/browse/IGNITE-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-14395:
Assignee: Dmitriy Sorokin
> Shorter test results directory name
> ---
>
> Key: IGNITE-14395
> URL: https://issues.apache.org/jira/browse/IGNITE-14395
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> The large number of parameters and their long names cause the too long test
> results directory name, so it is reason to split the test into two methods
> (it removes the {{trigger_event}} parameter), and cut the prefix of rebalance
> parameters from {{rebalance_}} to {{rb_}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14395) Shorter test results directory name
Dmitriy Sorokin created IGNITE-14395:
Summary: Shorter test results directory name
Key: IGNITE-14395
URL: https://issues.apache.org/jira/browse/IGNITE-14395
Project: Ignite
Issue Type: Sub-task
Reporter: Dmitriy Sorokin
The large number of parameters and their long names cause the too long test
results directory name, so it is reason to split the test into two methods (it
removes the {{trigger_event}} parameter), and cut the prefix of rebalance
parameters from {{rebalance_}} to {{rb_}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14391) Multi-node cache data preloading
[
https://issues.apache.org/jira/browse/IGNITE-14391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14391:
-
Description:
Need to add the test parameter {{preloaders}} and use it as {{num_nodes}}
parameter on creation {{IgniteApplicationService}} instance used for data
preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
was:
Need to add the test parameter {{client_node_count}} and use it as
{{num_nodes}} parameter on creation {{IgniteApplicationService}} instance used
for data preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
> Multi-node cache data preloading
>
>
> Key: IGNITE-14391
> URL: https://issues.apache.org/jira/browse/IGNITE-14391
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Need to add the test parameter {{preloaders}} and use it as {{num_nodes}}
> parameter on creation {{IgniteApplicationService}} instance used for data
> preloading.
> The keys of preloading data entries should be distributed between client
> nodes as equal sized ranges.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14391) Multi-node cache data preloading
Dmitriy Sorokin created IGNITE-14391:
Summary: Multi-node cache data preloading
Key: IGNITE-14391
URL: https://issues.apache.org/jira/browse/IGNITE-14391
Project: Ignite
Issue Type: Sub-task
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin
Need to add the test parameter {{client_node_count}} and use it as
{{num_nodes}} parameter on creation {{IgniteApplicationService}} instance used
for data preloading.
The keys of preloading data entries should be distributed between client nodes
as equal sized ranges.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14390) Add rebalance statistic to test result data
Dmitriy Sorokin created IGNITE-14390: Summary: Add rebalance statistic to test result data Key: IGNITE-14390 URL: https://issues.apache.org/jira/browse/IGNITE-14390 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Need to add to test result data the rebalance statistic data derived from node rebalance metrics: start_time [min, max] end_time [min, max] duration [min, max, sum] received_bytes [min, max, sum] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14319) Multithreaded data generation for rebalance tests
Dmitriy Sorokin created IGNITE-14319:
Summary: Multithreaded data generation for rebalance tests
Key: IGNITE-14319
URL: https://issues.apache.org/jira/browse/IGNITE-14319
Project: Ignite
Issue Type: Sub-task
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin
At the moment, {{DataGenerationApplication}} generates data in the single
thread. We should make that routine multithreaded.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14300) Rebalance speed as part of test result data
[
https://issues.apache.org/jira/browse/IGNITE-14300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14300:
-
Description:
Need to add properly calculated rebalance speed value to the test result data.
To do that, we need to reset the metrics before rebalance start, and get the
values of cache group metrics {{RebalancingReceivedBytes}},
{{RebalancingStartTime}} and {{RebalancingEndTime}} for each test cache on each
node where rebalancing routine has been started, after rebalance end. We should
sum all {{RebalancingReceivedBytes}} values, and divide that by sum of all
differences between {{RebalancingEndTime}} and {{RebalancingStartTime}} for
getting the real rebalance speed.
was:
Need to add properly calculated rebalance speed value to the test result data.
To do that, we need to get the values of cache group metrics
{{RebalancingReceivedBytes}}, {{RebalancingStartTime}} and
{{RebalancingEndTime}} for each test cache on each node where rebalancing
routine has been started. We should sum all {{RebalancingReceivedBytes}}
values, and divide that by sum all differences between {{RebalancingEndTime}}
and {{RebalancingStartTime}} for getting the real rebalance speed.
> Rebalance speed as part of test result data
> ---
>
> Key: IGNITE-14300
> URL: https://issues.apache.org/jira/browse/IGNITE-14300
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Need to add properly calculated rebalance speed value to the test result data.
> To do that, we need to reset the metrics before rebalance start, and get the
> values of cache group metrics {{RebalancingReceivedBytes}},
> {{RebalancingStartTime}} and {{RebalancingEndTime}} for each test cache on
> each node where rebalancing routine has been started, after rebalance end. We
> should sum all {{RebalancingReceivedBytes}} values, and divide that by sum of
> all differences between {{RebalancingEndTime}} and {{RebalancingStartTime}}
> for getting the real rebalance speed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14300) Rebalance speed as part of test result data
[
https://issues.apache.org/jira/browse/IGNITE-14300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14300:
-
Description:
Need to add properly calculated rebalance speed value to the test result data.
To do that, we need to get the values of cache group metrics
{{RebalancingReceivedBytes}}, {{RebalancingStartTime}} and
{{RebalancingEndTime}} for each test cache on each node where rebalancing
routine has been started. We should sum all {{RebalancingReceivedBytes}}
values, and divide that by sum all differences between {{RebalancingEndTime}}
and {{RebalancingStartTime}} for getting the real rebalance speed.
was:Need to add properly calculated rebalance speed value to the test result
data. To do that, need to get the total rebalanced data size using jmx metrics
or control.sh utility.
> Rebalance speed as part of test result data
> ---
>
> Key: IGNITE-14300
> URL: https://issues.apache.org/jira/browse/IGNITE-14300
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Need to add properly calculated rebalance speed value to the test result data.
> To do that, we need to get the values of cache group metrics
> {{RebalancingReceivedBytes}}, {{RebalancingStartTime}} and
> {{RebalancingEndTime}} for each test cache on each node where rebalancing
> routine has been started. We should sum all {{RebalancingReceivedBytes}}
> values, and divide that by sum all differences between {{RebalancingEndTime}}
> and {{RebalancingStartTime}} for getting the real rebalance speed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300142#comment-17300142
]
Dmitriy Sorokin commented on IGNITE-14228:
--
[~nizhikov], please review my changes.
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> Test result: time taken to rebalance process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[
https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14226:
-
Description:
There should be tests of rebalance for both in-memory caches and persistent
caches.
In case of persistent caches, the tests also should check both modes of
rebalance: full and historical (asserts is needed that the proper mode of
rebalance was worked).
Basic scenario:
Testing of rebalance triggered by two event types: node join and node left the
topology (baseline change in persistent mode).
Extended scenario:
Node join or left during rebalance process.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
was:
There should be tests of rebalance for both in-memory caches and persistent
caches.
In case of persistent caches, the tests also should check both modes of
rebalance: full and historical (asserts is needed that the proper mode of
rebalance was worked).
Basic scenario:
Testing of rebalance triggered by two event types: node join and node left the
topology (baseline change in persistent mode).
Extended scenario:
Node join or left during rebalance process.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize
property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
> Ducktape tests of rebalance
> ---
>
> Key: IGNITE-14226
> URL: https://issues.apache.org/jira/browse/IGNITE-14226
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> There should be tests of rebalance for both in-memory caches and persistent
> caches.
> In case of persistent caches, the tests also should check both modes of
> rebalance: full and historical (asserts is needed that the proper mode of
> rebalance was worked).
> Basic scenario:
> Testing of rebalance triggered by two event types: node join and node left
> the topology (baseline change in persistent mode).
> Extended scenario:
> Node join or left during rebalance process.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[
https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14228:
-
Description:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
was:
This test should check the rebalance on in-memory caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology.
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration.rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: time taken to rebalance process.
> Ducktape test of rebalance for in-memory mode
> -
>
> Key: IGNITE-14228
> URL: https://issues.apache.org/jira/browse/IGNITE-14228
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This test should check the rebalance on in-memory caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology.
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
>
[jira] [Created] (IGNITE-14300) Rebalance speed as part of test result data
Dmitriy Sorokin created IGNITE-14300: Summary: Rebalance speed as part of test result data Key: IGNITE-14300 URL: https://issues.apache.org/jira/browse/IGNITE-14300 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Need to add properly calculated rebalance speed value to the test result data. To do that, need to get the total rebalanced data size using jmx metrics or control.sh utility. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[ https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14228: - Description: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: # Initial node count (derived from test context); # Cache count - the count of caches to create and data preload; # Cache entry count - the count of entries per cache to preload; # Cache entry size - the size of each cache entry in bytes; # Rebalance thread pool size - the value for IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring rebalance thread pool title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), expected that greater value makes rebalance faster. # Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize property (see [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), expected that greater value makes rebalance faster on large data or [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] enabled (rebalanceThrottling > 0). # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle property (see [rebalance message throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), 0 - throttling disabled, greater value makes rebalance slower. Test result: time taken to rebalance process. was: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: see IGNITE-14226 description. Test result: time taken to rebalance process. > Ducktape test of rebalance for in-memory mode > - > > Key: IGNITE-14228 > URL: https://issues.apache.org/jira/browse/IGNITE-14228 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > This test should check the rebalance on in-memory caches in basic scenario: > rebalance triggered by two event types: node join and node left the topology. > The test should be able to run on large amounts of data enough to ensure > rebalancing time about of several minutes. > Test parameters: > # Initial node count (derived from test context); > # Cache count - the count of caches to create and data preload; > # Cache entry count - the count of entries per cache to preload; > # Cache entry size - the size of each cache entry in bytes; > # Rebalance thread pool size - the value for > IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring > rebalance thread pool > title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), > expected that greater value makes rebalance faster. > # Rebalance batch size - the value for > IgniteConfiguration.rebalanceBatchSize property (see [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > expected that greater value makes rebalance faster on large data or > [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] > enabled (rebalanceThrottling > 0). > # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle > property (see [rebalance message > throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], > [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > 0 - throttling disabled, greater value makes rebalance slower. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[ https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14228: - Description: This test should check the rebalance on in-memory caches in basic scenario: rebalance triggered by two event types: node join and node left the topology. The test should be able to run on large amounts of data enough to ensure rebalancing time about of several minutes. Test parameters: see IGNITE-14226 description. Test result: time taken to rebalance process. was: This test should check the rebalance on in-memory caches in basic scenario. Preloaded data size should be at least 30GB. The runs should be made for different entry sizes: 1, 2, 10, 25 and 50KB. Also, different values of rebalance thread pool size and rebalance batch size should be tested: 2, 4, 8 and 512KiB, 1MiB, 2MiB accordingly. > Ducktape test of rebalance for in-memory mode > - > > Key: IGNITE-14228 > URL: https://issues.apache.org/jira/browse/IGNITE-14228 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > This test should check the rebalance on in-memory caches in basic scenario: > rebalance triggered by two event types: node join and node left the topology. > The test should be able to run on large amounts of data enough to ensure > rebalancing time about of several minutes. > Test parameters: see IGNITE-14226 description. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the tests also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node join and node left the topology (baseline change in persistent mode). Extended scenario: Node join or left during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count - the count of caches to create and data preload; # Cache entry count - the count of entries per cache to preload; # Cache entry size - the size of each cache entry in bytes; # Rebalance thread pool size - the value for IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring rebalance thread pool title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), expected that greater value makes rebalance faster. # Rebalance batch size - the value for IgniteConfiguration.rebalanceBatchSize property (see [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), expected that greater value makes rebalance faster on large data or [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] enabled (rebalanceThrottling > 0). # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle property (see [rebalance message throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], [other rebalance properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), 0 - throttling disabled, greater value makes rebalance slower. Test result: time taken to rebalance process. was: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the tests also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count; # Cache entry count; # Cache entry size; # Rebalance thread pool size # Rebalance batch size # Rebalance throttle Test result: time taken to rebalance process. > Ducktape tests of rebalance > --- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > There should be tests of rebalance for both in-memory caches and persistent > caches. > In case of persistent caches, the tests also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node join and node left > the topology (baseline change in persistent mode). > Extended scenario: > Node join or left during rebalance process. > Test parameters: > # Initial node count (derived from test context); > # Cache count - the count of caches to create and data preload; > # Cache entry count - the count of entries per cache to preload; > # Cache entry size - the size of each cache entry in bytes; > # Rebalance thread pool size - the value for > IgniteConfiguration.rebalanceThreadPoolSize property (see [configuring > rebalance thread pool > title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]), > expected that greater value makes rebalance faster. > # Rebalance batch size - the value for > IgniteConfiguration.rebalanceBatchSize property (see [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > expected that greater value makes rebalance faster on large data or > [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling] > enabled (rebalanceThrottling > 0). > # Rebalance throttle - the value for IgniteConfiguration.rebalanceThrottle > property (see [rebalance message > throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling], > [other rebalance > properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]), > 0 - throttling disabled, greater value makes rebalance slower. > Test result: time taken to rebalance process. -- This message was sent by
[jira] [Closed] (IGNITE-14288) Ability to define the JVM settings by globals for server and client (app) nodes separately
[ https://issues.apache.org/jira/browse/IGNITE-14288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin closed IGNITE-14288. > Ability to define the JVM settings by globals for server and client (app) > nodes separately > -- > > Key: IGNITE-14288 > URL: https://issues.apache.org/jira/browse/IGNITE-14288 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes it becomes necessary to define the JVM options only for server > nodes or only for application nodes globally, so new global parameters, > _node_jvm_opts_ and _app_jvm_opts_ should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the tests also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count; # Cache entry count; # Cache entry size; # Rebalance thread pool size # Rebalance batch size # Rebalance throttle Test result: time taken to rebalance process. was: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count; # Cache entry count; # Cache entry size; # Rebalance thread pool size # Rebalance batch size # Rebalance throttle Test result: time taken to rebalance process. > Ducktape tests of rebalance > --- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > There should be tests of rebalance for both in-memory caches and persistent > caches. > In case of persistent caches, the tests also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change in persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count (derived from test context); > # Cache count; > # Cache entry count; > # Cache entry size; > # Rebalance thread pool size > # Rebalance batch size > # Rebalance throttle > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
[ https://issues.apache.org/jira/browse/IGNITE-14228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14228: - Description: This test should check the rebalance on in-memory caches in basic scenario. Preloaded data size should be at least 30GB. The runs should be made for different entry sizes: 1, 2, 10, 25 and 50KB. Also, different values of rebalance thread pool size and rebalance batch size should be tested: 2, 4, 8 and 512KiB, 1MiB, 2MiB accordingly. was:This test should check the rebalance on in-memory caches in basic scenario. > Ducktape test of rebalance for in-memory mode > - > > Key: IGNITE-14228 > URL: https://issues.apache.org/jira/browse/IGNITE-14228 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > This test should check the rebalance on in-memory caches in basic scenario. > Preloaded data size should be at least 30GB. > The runs should be made for different entry sizes: 1, 2, 10, 25 and 50KB. > Also, different values of rebalance thread pool size and rebalance batch size > should be tested: 2, 4, 8 and 512KiB, 1MiB, 2MiB accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: There should be tests of rebalance for both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count (derived from test context); # Cache count; # Cache entry count; # Cache entry size; # Rebalance thread pool size # Rebalance batch size # Rebalance throttle Test result: time taken to rebalance process. was: The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. > Ducktape tests of rebalance > --- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > There should be tests of rebalance for both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change in persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count (derived from test context); > # Cache count; > # Cache entry count; > # Cache entry size; > # Rebalance thread pool size > # Rebalance batch size > # Rebalance throttle > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape tests of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Summary: Ducktape tests of rebalance (was: Ducktape test of rebalance) > Ducktape tests of rebalance > --- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > The test should check the rebalance on both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change in persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count; > # Cache count; > # Cache entry count; > # Cache entry size; > # Mode: in-memory or persistence; > # Rebalance trigger event: node enter or node leave. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14288) Ability to define the JVM settings by globals for server and client (app) nodes separately
Dmitriy Sorokin created IGNITE-14288: Summary: Ability to define the JVM settings by globals for server and client (app) nodes separately Key: IGNITE-14288 URL: https://issues.apache.org/jira/browse/IGNITE-14288 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Sometimes it becomes necessary to define the JVM options only for server nodes or only for application nodes globally, so new global parameters, _node_jvm_opts_ and _app_jvm_opts_ should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
Dmitriy Sorokin created IGNITE-14228: Summary: Ducktape test of rebalance for in-memory mode Key: IGNITE-14228 URL: https://issues.apache.org/jira/browse/IGNITE-14228 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin This test should check the rebalance on in-memory caches in basic scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape test of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. was: The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and the historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change if persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. > Ducktape test of rebalance > -- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > The test should check the rebalance on both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change in persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count; > # Cache count; > # Cache entry count; > # Cache entry size; > # Mode: in-memory or persistence; > # Rebalance trigger event: node enter or node leave. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13994) Rebalance huge cache in the case of in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-13994: Assignee: (was: Dmitriy Sorokin) > Rebalance huge cache in the case of in-memory cluster > - > > Key: IGNITE-13994 > URL: https://issues.apache.org/jira/browse/IGNITE-13994 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Priority: Major > > There are some evidence, that rebalancing huge cache without rebalance > throttling can cause OOM on supplier. We need to cover this scenario. > Scenario: > 1. Start two nodes and 1 replicated cache with data region much more than > heap. > 2. Stop one of the node. > 3. Load data to cache almost equal to size of data region. > 4. Start node. > Goal is to run experiments with parameters > 1. Heap size > 2. Cache size > 3. Rebalance batch size. > 4. Rebalance throttle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape test of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Sprint: Ducktape Sprint 4 > Ducktape test of rebalance > -- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > The test should check the rebalance on both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and the historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change if persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count; > # Cache count; > # Cache entry count; > # Cache entry size; > # Mode: in-memory or persistence; > # Rebalance trigger event: node enter or node leave. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14226) Ducktape test of rebalance
Dmitriy Sorokin created IGNITE-14226: Summary: Ducktape test of rebalance Key: IGNITE-14226 URL: https://issues.apache.org/jira/browse/IGNITE-14226 Project: Ignite Issue Type: Test Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and the historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change if persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091425#comment-17091425
]
Dmitriy Sorokin commented on IGNITE-12905:
--
[~bleedah], so far seems no, just stay tuned.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090592#comment-17090592
]
Dmitriy Sorokin commented on IGNITE-12905:
--
[~bleedah], LGTM, thanks for contribution!
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17088548#comment-17088548
]
Dmitriy Sorokin commented on IGNITE-12905:
--
[~bleedah],
You have to make the new PR to master branch instead ignite-2.8.1, based on
newest upstream/master, and get an approval from TC Bot for that.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087662#comment-17087662
]
Dmitriy Sorokin commented on IGNITE-12905:
--
Hello, [~bleedah]!
Thanks for your contribution!
I made several review comments on your test class at github, it needs some
fixes.
Also, you have to register at [https://ci.ignite.apache.org/] and get an
approval for your PR from [TC Bot|https://mtcga.gridgain.com/prs.html], see
[howto|https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot]
page.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[ https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-11302: Assignee: Dmitriy Sorokin > idleConnectionTimeout TcpComm different on server and client (client default > > server custom) lead to wait until client timeout on server side > -- > > Key: IGNITE-11302 > URL: https://issues.apache.org/jira/browse/IGNITE-11302 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.9, 2.8.1 > > > Server config: > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > > Client config > > class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi"> > > > Server wait until default idleConnectionTimeout (10 m) for client fail. > If both config with idleConnectionTimeout=1 s - ignite worked according to > config -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin resolved IGNITE-11862.
--
Resolution: Cannot Reproduce
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reopened IGNITE-11862:
--
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin resolved IGNITE-8625. - Resolution: Cannot Reproduce > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Dmitriy Sorokin >Priority: Critical > Labels: MakeTeamcityGreenAgain, sql-stability > Fix For: 2.9, 2.8.1 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > P.S. Please note that with IGNITE-4958 fix old invalid links may refer to > non-data page - it might have been recycled into page with any other type. > Such case will cause AssertionError on page read lock attempt. Rolling back > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[
https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082738#comment-17082738
]
Dmitriy Sorokin commented on IGNITE-8625:
-
I investigated this issue using the attached reproducer and ready to list
several facts:
1. Before the fix IGNITE-4958 (change {{0bdfa20c}}) the test failed with AE on
code line
{code:java}
assert len >= 0;
{code}
of method {{PageUtils#getBytes(long, int, int)}}, sometimes causing the JVM
crash on further execution;
2. After the fix IGNITE-4958 till the IGNITE-12061 (change {{dde81742}}) the
test failed with AE on code line
{code:java}
assert pageAddr != 0L : nextLink;
{code}
of method {{CacheDataRowAdapter#initFromLink(CacheGroupContext,
GridCacheSharedContext, PageMemory, RowData)}}
({{CacheDataRowAdapter#doInitFromLink(...)}} since the fix IGNITE-10798, change
{{bc209d08}});
3. Finally, since the fix IGNITE-12061 till the current master branch the test
stopped falling, so I think that this issue was fixed too.
> Dynamic SQL index recreate after cache clear may result in AssertionError or
> JVM crash
> --
>
> Key: IGNITE-8625
> URL: https://issues.apache.org/jira/browse/IGNITE-8625
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, sql-stability
> Fix For: 2.9, 2.8.1
>
> Attachments: dyn_idx_reproducer.patch
>
>
> After recreation of previously dropped SQL index (in persistent mode), root
> page of new index B+ tree may contain links to data entries from previous
> index tree. If these entries were removed or relocated to another data page,
> attempt to dereference these links may throw AssertionError or even cause JVM
> crash.
> Patch with reproducer is attached.
> P.S. Please note that with IGNITE-4958 fix old invalid links may refer to
> non-data page - it might have been recycled into page with any other type.
> Such case will cause AssertionError on page read lock attempt. Rolling back
> IGNITE-4958 may help with debugging.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-8625: --- Assignee: Dmitriy Sorokin (was: Alexey Stelmak) > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Dmitriy Sorokin >Priority: Critical > Labels: MakeTeamcityGreenAgain, sql-stability > Fix For: 2.9, 2.8.1 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > P.S. Please note that with IGNITE-4958 fix old invalid links may refer to > non-data page - it might have been recycled into page with any other type. > Such case will cause AssertionError on page read lock attempt. Rolling back > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin resolved IGNITE-11862.
--
Resolution: Fixed
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082391#comment-17082391
]
Dmitriy Sorokin commented on IGNITE-11862:
--
I investigated this issue and found that NPE was happening on code line
{code:java}
if (!cctx.config().isEventsDisabled())
{code}
because a {{null}} config value was returned by {{cctx.config()}} call due to
race between calling {{GridCacheContext#cleanup()}} method.
The reproduction of this issue was disappeared after the change {{79553ada}}
made at PR [#6688|https://github.com/apache/ignite/pull/6688] of ticket
IGNITE-3195.
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080464#comment-17080464 ] Dmitriy Sorokin commented on IGNITE-12764: -- [~nizhikov], thank you for hinting to me about more suitable test class, please review my changes! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080328#comment-17080328 ] Dmitriy Sorokin commented on IGNITE-12764: -- Hello, [~tledkov-gridgain]! Thanks for reviewing of my patch! I think I fixed the code style flaws that you meant, please review my changes! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[
https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079478#comment-17079478
]
Dmitriy Sorokin commented on IGNITE-12764:
--
[~tledkov-gridgain], I don't mind fixing the code style at the
{{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}, but I don’t quite understand
what you mean? Can you assist to me by marking the wrong code points on last
commit
[5c9db78|https://github.com/apache/ignite/pull/7615/commits/5c9db786a46e783f22eefc4b93952de5dfcdf725]?
> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly
> here. Column type does not matter between UUID and VARCHAR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077988#comment-17077988 ] Dmitriy Sorokin commented on IGNITE-12764: -- [~nizhikov], thanks for your review of my patch! I fixed the code according to your comments and answered to your question, please look at new changes! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 20m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12835) Thin client: compute support
[ https://issues.apache.org/jira/browse/IGNITE-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076925#comment-17076925 ] Dmitriy Sorokin commented on IGNITE-12835: -- [~alex_pl], I reviewed your patch, LGTM, thanks for contribution! > Thin client: compute support > > > Key: IGNITE-12835 > URL: https://issues.apache.org/jira/browse/IGNITE-12835 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-42 > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add compute grid functionality to thin clients. > As a first step execution of task by task name should be added. > Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076113#comment-17076113 ] Dmitriy Sorokin commented on IGNITE-12764: -- [~nizhikov], [~ilyak], review my patch, please! > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 10m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-11862:
Assignee: Dmitriy Sorokin
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[
https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071296#comment-17071296
]
Dmitriy Sorokin commented on IGNITE-12764:
--
The stacktrace of error caused in 2.8.0 is below. See that it happens on call
of extractArgsValues method, which was not called in 2.7.6 in same case.
{noformat}
[2020-03-31
00:28:06,973][ERROR][client-connector-#69%sqltests.Ignite12764Test0%][JdbcRequestHandler]
Failed to execute batch query [qry=SqlFieldsQuery [sql=insert INTO
city1(id,name,name1) VALUES(?,?,RANDOM_UUID()), args=null, collocated=false,
timeout=0, enforceJoinOrder=false, distributedJoins=false,
replicatedOnly=false, lazy=false, schema=PUBLIC, updateBatchSize=1]]
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.streamBatchedUpdateQuery(GridQueryProcessor.java:2525)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeBatchedQuery(JdbcRequestHandler.java:994)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeBatch(JdbcRequestHandler.java:927)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeBatchOrdered(JdbcRequestHandler.java:413)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.dispatchBatchOrdered(JdbcRequestHandler.java:392)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:330)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:247)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:195)
at
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:49)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
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: class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2942)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.streamBatchedUpdateQuery(GridQueryProcessor.java:2518)
... 16 more
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.extractArgsValues(UpdatePlan.java:465)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.createRows(UpdatePlan.java:412)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.streamQuery0(IgniteH2Indexing.java:702)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.streamBatchedUpdateQuery(IgniteH2Indexing.java:673)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:2520)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:2518)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2919)
... 17 more
{noformat}
> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
>
> insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: null
> at
>
[jira] [Assigned] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-12764: Assignee: Dmitriy Sorokin > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023166#comment-17023166 ] Dmitriy Sorokin commented on IGNITE-9184: - [~mcherkasov] It would be great if you can attach your initial reproducer, if possible. But while, at the moment I decided to close this issue as non-reproducable. > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, StressTest3.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin resolved IGNITE-9184. - Resolution: Cannot Reproduce > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, StressTest3.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023160#comment-17023160
]
Dmitriy Sorokin commented on IGNITE-9184:
-
[~mmuzaf]
I wrote the new version of reproducer (see the StressTest3.java attachment)
which provides true concurrent nodes restart, but subject problem with cluster
hanging never met, neither on version 2.6 nor current master branch. However,
short-time hangings with logs similar to ones published at comment above still
appearing at the current master:
{noformat}
[2019-12-06 13:10:21,381][INFO
][exchange-worker-#1448818%hang.StressTest325879%][time] Started exchange init
[topVer=AffinityTopologyVersion [topVer=51762, minorTopVer=0], crd=false,
evt=NODE_JOINED, evtNode=92f30d54-e3ec-4292-84fa-e1f399325881, customEvt=null,
allowMerge=true]
[2019-12-06 13:10:21,381][INFO
][exchange-worker-#1448818%hang.StressTest325879%][GridDhtPartitionsExchangeFuture]
Finished waiting for partition release future [topVer=AffinityTopologyVersion
[topVer=51762, minorTopVer=0], waitTime=0ms, futInfo=NA, mode=DISTRIBUTED]
[2019-12-06 13:10:21,381][INFO
][exchange-worker-#1448936%hang.StressTest325881%][time] Started exchange init
[topVer=AffinityTopologyVersion [topVer=51762, minorTopVer=0], crd=false,
evt=NODE_JOINED, evtNode=92f30d54-e3ec-4292-84fa-e1f399325881, customEvt=null,
allowMerge=true]
[2019-12-06 13:10:21,382][INFO
][exchange-worker-#1448936%hang.StressTest325881%][IgniteCacheDatabaseSharedManager]
Configured data regions started successfully [total=3]
[2019-12-06 13:10:21,382][INFO
][exchange-worker-#1448936%hang.StressTest325881%][msg] Components activation
performed in 1 ms.
[2019-12-06 13:10:21,383][INFO
][sys-#1448940%hang.StressTest325881%][GridCacheProcessor] Started cache
[name=ignite-sys-cache, id=-2100569601, dataRegionName=sysMemPlc,
mode=REPLICATED, atomicity=TRANSACTIONAL, backups=2147483647, mvcc=false]
[2019-12-06 13:10:21,383][INFO
][exchange-worker-#1448936%hang.StressTest325881%][GridCacheProcessor] Started
cache [name=default, id=1544803905, dataRegionName=default, mode=PARTITIONED,
atomicity=ATOMIC, backups=1, mvcc=false]
[2019-12-06 13:10:21,383][INFO
][exchange-worker-#1448936%hang.StressTest325881%][GridCacheProcessor] Starting
caches on local join performed in 10 ms.
[2019-12-06 13:10:21,381][WARN ][Thread-9][StressTest325881] Nodes started on
local machine require more than 80% of physical RAM what can lead to
significant slowdown due to swapping (please decrease JVM heap size, data
region size or checkpoint buffer size) [required=35144MB, available=16280MB]
[2019-12-06 13:10:21,384][INFO
][exchange-worker-#1448936%hang.StressTest325881%][GridDhtPartitionsExchangeFuture]
Skipped waiting for partitions release future (local node is joining)
[topVer=AffinityTopologyVersion [topVer=51762, minorTopVer=0]]
[2019-12-06 13:10:21,385][INFO
][grid-nio-worker-tcp-comm-2-#1448576%hang.StressTest325875%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45014,
rmtAddr=/127.0.0.1:55957]
[2019-12-06 13:10:21,386][INFO
][grid-nio-worker-tcp-comm-0-#1448902%hang.StressTest325881%][TcpCommunicationSpi]
Established outgoing communication connection [locAddr=/127.0.0.1:55957,
rmtAddr=/127.0.0.1:45014]
[2019-12-06 13:10:21,386][INFO
][exchange-worker-#1448936%hang.StressTest325881%][time] Finished exchange init
[topVer=AffinityTopologyVersion [topVer=51762, minorTopVer=0], crd=false]
[2019-12-06 13:10:21,413][INFO
][grid-nio-worker-tcp-comm-2-#1448910%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45013,
rmtAddr=/127.0.0.1:55958]
[2019-12-06 13:10:21,463][INFO
][grid-nio-worker-tcp-comm-3-#1448911%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45013,
rmtAddr=/127.0.0.1:55959]
[2019-12-06 13:10:21,514][INFO
][grid-nio-worker-tcp-comm-0-#1448908%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45013,
rmtAddr=/127.0.0.1:55960]
[2019-12-06 13:10:21,565][INFO
][grid-nio-worker-tcp-comm-1-#1448909%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45013,
rmtAddr=/127.0.0.1:55961]
[2019-12-06 13:10:21,569][INFO
][sys-#1448612%hang.StressTest325875%][GridCachePartitionExchangeManager]
Ignore single message without exchange id (there is exchange in progress)
[nodeId=4422f968-e654-4376-bef6-262125325879]
[2019-12-06 13:10:21,617][INFO
][grid-nio-worker-tcp-comm-2-#1448910%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:45013,
rmtAddr=/127.0.0.1:55962]
[2019-12-06 13:10:21,667][INFO
][grid-nio-worker-tcp-comm-3-#1448911%hang.StressTest325882%][TcpCommunicationSpi]
Accepted incoming
[jira] [Updated] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-9184: Attachment: StressTest3.java > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, StressTest3.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16992705#comment-16992705 ] Dmitriy Sorokin commented on IGNITE-9184: - [~mmuzaf] Hi Maxim! Yes, I still working on this. I found that attached StressTest2.java doesn't reproduce this issue at least locally, neither on version 2.6 nor current master branch. At the moment I writing the proper reproducer of described issue, which should to fail at least on version 2.6, then run on current master for understanding wheter issue is still present or not. > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12207) Inclusion of super.toString() info into some descenders of GridCacheMessage
[
https://issues.apache.org/jira/browse/IGNITE-12207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988972#comment-16988972
]
Dmitriy Sorokin commented on IGNITE-12207:
--
[~nizhikov], [~mmuzaf], could you please review the code?
> Inclusion of super.toString() info into some descenders of GridCacheMessage
> ---
>
> Key: IGNITE-12207
> URL: https://issues.apache.org/jira/browse/IGNITE-12207
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7, 2.7.6
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes when errors related to processing of descenders of GridCacheMessage
> happens, we could need information which contained at the GridCacheMessage
> class, in particular deployment information, contained if depInfo field. In
> the some message classes which extends GridCacheMessage, toString() method
> doesn't include the 'super' part, so we haven't that information at log error
> messages, as at example below:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The assertion condition which produced error above includes the value which
> obtained from GridCacheMessage.depInfo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
[
https://issues.apache.org/jira/browse/IGNITE-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988971#comment-16988971
]
Dmitriy Sorokin commented on IGNITE-12200:
--
[~nizhikov], [~mmuzaf], could you please review the code?
> More informative assertion message at constructor of CachedDeploymentInfo
> (GridCacheDeploymentManager class)
>
>
> Key: IGNITE-12200
> URL: https://issues.apache.org/jira/browse/IGNITE-12200
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5, 2.7.5
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * @param sndId Sender.
> * @param ldrId Loader ID.
> * @param userVer User version.
> * @param depMode Deployment mode.
> * @param participants Participants.
> */
> private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
> DeploymentMode depMode,
> Map participants) {
> assert sndId.equals(ldrId.globalId()) || participants != null;
> this.sndId = sndId;
> this.ldrId = ldrId;
> this.userVer = userVer;
> this.depMode = depMode;
> this.participants = participants == null || participants.isEmpty() ? null
> :
> new ConcurrentLinkedHashMap<>(participants);
> }
> {code}
> The code above may produce the following stacktrace, where AssertionError
> should contain more informative message for better root cause analysis:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> 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)
> 2019-09-17
> 18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
> Critical
[jira] [Assigned] (IGNITE-9184) Cluster hangs during concurrent node client and server nodes restart
[ https://issues.apache.org/jira/browse/IGNITE-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-9184: --- Assignee: Dmitriy Sorokin > Cluster hangs during concurrent node client and server nodes restart > > > Key: IGNITE-9184 > URL: https://issues.apache.org/jira/browse/IGNITE-9184 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.6 >Reporter: Mikhail Cherkasov >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8 > > Attachments: StressTest2.java, logs, stacktrace > > > Please check the attached test case and stack trace. > I can see: "Failed to wait for initial partition map exchange" message. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
[
https://issues.apache.org/jira/browse/IGNITE-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-12200:
-
Fix Version/s: 2.8
> More informative assertion message at constructor of CachedDeploymentInfo
> (GridCacheDeploymentManager class)
>
>
> Key: IGNITE-12200
> URL: https://issues.apache.org/jira/browse/IGNITE-12200
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5, 2.7.5
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * @param sndId Sender.
> * @param ldrId Loader ID.
> * @param userVer User version.
> * @param depMode Deployment mode.
> * @param participants Participants.
> */
> private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
> DeploymentMode depMode,
> Map participants) {
> assert sndId.equals(ldrId.globalId()) || participants != null;
> this.sndId = sndId;
> this.ldrId = ldrId;
> this.userVer = userVer;
> this.depMode = depMode;
> this.participants = participants == null || participants.isEmpty() ? null
> :
> new ConcurrentLinkedHashMap<>(participants);
> }
> {code}
> The code above may produce the following stacktrace, where AssertionError
> should contain more informative message for better root cause analysis:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> 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)
> 2019-09-17
> 18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
> Critical system error detected. Will be handled accordingly
[jira] [Updated] (IGNITE-12207) Inclusion of super.toString() info into some descenders of GridCacheMessage
[
https://issues.apache.org/jira/browse/IGNITE-12207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-12207:
-
Fix Version/s: 2.8
> Inclusion of super.toString() info into some descenders of GridCacheMessage
> ---
>
> Key: IGNITE-12207
> URL: https://issues.apache.org/jira/browse/IGNITE-12207
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7, 2.7.6
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes when errors related to processing of descenders of GridCacheMessage
> happens, we could need information which contained at the GridCacheMessage
> class, in particular deployment information, contained if depInfo field. In
> the some message classes which extends GridCacheMessage, toString() method
> doesn't include the 'super' part, so we haven't that information at log error
> messages, as at example below:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
> msg=GridCacheQueryRequest [id=4922,
> cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
> super=GridCacheIdMessage [cacheId=-724666788]]]
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The assertion condition which produced error above includes the value which
> obtained from GridCacheMessage.depInfo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12207) Inclusion of super.toString() info into some descenders of GridCacheMessage
[
https://issues.apache.org/jira/browse/IGNITE-12207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-12207:
-
Description:
Sometimes when errors related to processing of descenders of GridCacheMessage
happens, we could need information which contained at the GridCacheMessage
class, in particular deployment information, contained if depInfo field. In the
some message classes which extends GridCacheMessage, toString() method doesn't
include the 'super' part, so we haven't that information at log error messages,
as at example below:
{noformat}
2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The assertion condition which produced error above includes the value which
obtained from GridCacheMessage.depInfo.
> Inclusion of super.toString() info into some descenders of GridCacheMessage
> ---
>
> Key: IGNITE-12207
> URL: https://issues.apache.org/jira/browse/IGNITE-12207
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7, 2.7.6
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes when errors related to processing of descenders of GridCacheMessage
> happens, we could need information which contained at the GridCacheMessage
> class, in particular deployment information, contained if depInfo field. In
> the some message classes which extends GridCacheMessage, toString() method
> doesn't include the 'super' part, so we haven't that information at log error
> messages, as at example below:
> {noformat}
> 2019-09-17
> 18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
>
[jira] [Commented] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959839#comment-16959839
]
Dmitriy Sorokin commented on IGNITE-1606:
-
Discussion thread on dev-list:
[Clearing of injected resources on node
stop|http://apache-ignite-developers.2346864.n4.nabble.com/Clearing-of-injected-resources-on-node-stop-td44159.html]
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Probably we should check other components as well. Not sure why we need to
> nullify logger.
> {noformat}
> Exception in thread "ignite-#101%sys-t1-1%" java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1896)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1071)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1034)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1017)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:851)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1500(GridContinuousProcessor.java:85)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958979#comment-16958979
]
Dmitriy Sorokin edited comment on IGNITE-1606 at 10/25/19 8:36 AM:
---
Ultimately, I chose the second solution with leaving injected loggers
non-nullified, see [PR#7004|https://github.com/apache/ignite/pull/7004].
Ticket is ready for code review.
was (Author: cyberdemon):
Ultimately, I chose the second solution with leaving injected loggers
non-nullified, see [PR#7004|https://github.com/apache/ignite/pull/7004.]
Ticket is ready for code review.
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Probably we should check other components as well. Not sure why we need to
> nullify logger.
> {noformat}
> Exception in thread "ignite-#101%sys-t1-1%" java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1896)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1071)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1034)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1017)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:851)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1500(GridContinuousProcessor.java:85)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958979#comment-16958979
]
Dmitriy Sorokin edited comment on IGNITE-1606 at 10/24/19 3:46 PM:
---
Ultimately, I chose the second solution with leaving injected loggers
non-nullified, see [PR#7004|https://github.com/apache/ignite/pull/7004.]
Ticket is ready for code review.
was (Author: cyberdemon):
Ultimately, I chose the second solution with leaving injected loggers
non-nullified, see [PR#7004|[https://github.com/apache/ignite/pull/7004].]
Ticket is ready for code review.
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Probably we should check other components as well. Not sure why we need to
> nullify logger.
> {noformat}
> Exception in thread "ignite-#101%sys-t1-1%" java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1896)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1071)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1034)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1017)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:851)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1500(GridContinuousProcessor.java:85)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958979#comment-16958979
]
Dmitriy Sorokin commented on IGNITE-1606:
-
Ultimately, I chose the second solution with leaving injected loggers
non-nullified, see [PR#7004|[https://github.com/apache/ignite/pull/7004].]
Ticket is ready for code review.
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Probably we should check other components as well. Not sure why we need to
> nullify logger.
> {noformat}
> Exception in thread "ignite-#101%sys-t1-1%" java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1896)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1071)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1034)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1017)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:851)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1500(GridContinuousProcessor.java:85)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953832#comment-16953832
]
Dmitriy Sorokin edited comment on IGNITE-1606 at 10/17/19 3:11 PM:
---
The issue with access to nullified log field is present at the current master
branch (2.8-SNAPSHOT) not only in TcpCommunicationSpi but also in
TcpDiscoveryMulticastIpFinder, see stacktraces below:
{code:java}
[2019-09-24 15:31:19,018][ERROR][sys-stripe-0-#325%worker-8%][root] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]][2019-09-24
15:31:19,018][ERROR][sys-stripe-0-#325%worker-8%][root] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2821)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2805)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2031)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2128)
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.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3619)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$3300(GridDhtAtomicCache.java:142)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3865)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:550)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
[2019-09-24
15:31:11,411][ERROR][tcp-client-disco-reconnector-#64%worker-4%][TcpDiscoverySpi]
Runtime error caught during grid runnable execution: IgniteSpiThread
[name=tcp-client-disco-reconnector-#64%worker-4%][2019-09-24
15:31:11,411][ERROR][tcp-client-disco-reconnector-#64%worker-4%][TcpDiscoverySpi]
Runtime error caught during grid runnable execution: IgniteSpiThread
[name=tcp-client-disco-reconnector-#64%worker-4%]
java.lang.NullPointerException
at
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.requestAddresses(TcpDiscoveryMulticastIpFinder.java:637)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.getRegisteredAddresses(TcpDiscoveryMulticastIpFinder.java:392)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1944)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1892)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:562)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.access$1100(ClientImpl.java:141)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1523)
{code}
I see two different solutions:
1) Replace constructions
{code:java}
if (log.isDebugEnabled())
log.debug(...);{code}
and
{code:java}
if (log.isTraceEnabled())
log.trace(...);{code}
by wrappers similar to U.error(...) and U.warn(...), where log reference will
be checked for null before access.
2) Prevent nullifying of log references annotated by IgniteLogger at
GridResourceProcessor.cleanup() method.
First solution seems more simple to me rather than second one, so I propose use
that for resolving this issue.
Thoughts?
was (Author: cyberdemon):
The issue with access to nullified log field is present at the current master
branch (2.8-SNAPSHOT) not only in TcpCommunicationSpi but also in
TcpDiscoveryMulticastIpFinder, see stacktraces below:
{code:java}
[2019-09-24 15:31:19,018][ERROR][sys-stripe-0-#325%worker-8%][root] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler
[jira] [Commented] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953832#comment-16953832
]
Dmitriy Sorokin commented on IGNITE-1606:
-
The issue with access to nullified log field is present at the current master
branch (2.8-SNAPSHOT) not only in TcpCommunicationSpi but also in
TcpDiscoveryMulticastIpFinder, see stacktraces below:
{code:java}
[2019-09-24 15:31:19,018][ERROR][sys-stripe-0-#325%worker-8%][root] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]][2019-09-24
15:31:19,018][ERROR][sys-stripe-0-#325%worker-8%][root] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NullPointerException]]java.lang.NullPointerException at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2821)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2805)
at
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:2031)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:2128)
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.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3619)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$3300(GridDhtAtomicCache.java:142)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout.run(GridDhtAtomicCache.java:3865)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:550)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
{code:java}
[2019-09-24
15:31:11,411][ERROR][tcp-client-disco-reconnector-#64%worker-4%][TcpDiscoverySpi]
Runtime error caught during grid runnable execution: IgniteSpiThread
[name=tcp-client-disco-reconnector-#64%worker-4%][2019-09-24
15:31:11,411][ERROR][tcp-client-disco-reconnector-#64%worker-4%][TcpDiscoverySpi]
Runtime error caught during grid runnable execution: IgniteSpiThread
[name=tcp-client-disco-reconnector-#64%worker-4%]java.lang.NullPointerException
at
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.requestAddresses(TcpDiscoveryMulticastIpFinder.java:637)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.multicast.TcpDiscoveryMulticastIpFinder.getRegisteredAddresses(TcpDiscoveryMulticastIpFinder.java:392)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1944)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1892)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:562)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.access$1100(ClientImpl.java:141)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1523)
{code}
I see two different solutions:
1) Replace constructions
{code:java}
if (log.isDebugEnabled())
log.debug(...);{code}
and
{code:java}
if (log.isTraceEnabled())
log.trace(...);{code}
by wrappers similar to U.error(...) and U.warn(...), where log reference will
be checked for null before access.
2) Prevent nullifying of log references annotated by IgniteLogger at
GridResourceProcessor.cleanup() method.
First solution seems more simple to me rather than second one, so I propose use
that for resolving this issue.
Thoughts?
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Probably we should check other components as well. Not sure why we need to
> nullify
[jira] [Assigned] (IGNITE-1606) NPE during node stop due to nullified logger in TcpCommunicationSpi
[
https://issues.apache.org/jira/browse/IGNITE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-1606:
---
Assignee: Dmitriy Sorokin
> NPE during node stop due to nullified logger in TcpCommunicationSpi
> ---
>
> Key: IGNITE-1606
> URL: https://issues.apache.org/jira/browse/IGNITE-1606
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Dmitriy Sorokin
>Priority: Major
>
> Probably we should check other components as well. Not sure why we need to
> nullify logger.
> {noformat}
> Exception in thread "ignite-#101%sys-t1-1%" java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1896)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1880)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1066)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1214)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1071)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1034)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1017)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:851)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$1500(GridContinuousProcessor.java:85)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12207) Inclusion of super.toString() info into some descenders of GridCacheMessage
Dmitriy Sorokin created IGNITE-12207: Summary: Inclusion of super.toString() info into some descenders of GridCacheMessage Key: IGNITE-12207 URL: https://issues.apache.org/jira/browse/IGNITE-12207 Project: Ignite Issue Type: Improvement Affects Versions: 2.7.6, 2.7 Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
[
https://issues.apache.org/jira/browse/IGNITE-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-12200:
-
Description:
{code:java}
/**
* @param sndId Sender.
* @param ldrId Loader ID.
* @param userVer User version.
* @param depMode Deployment mode.
* @param participants Participants.
*/
private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
DeploymentMode depMode,
Map participants) {
assert sndId.equals(ldrId.globalId()) || participants != null;
this.sndId = sndId;
this.ldrId = ldrId;
this.userVer = userVer;
this.depMode = depMode;
this.participants = participants == null || participants.isEmpty() ? null :
new ConcurrentLinkedHashMap<>(participants);
}
{code}
The code above may produce the following stacktrace, where AssertionError
should contain more informative message for better root cause analysis:
{noformat}
2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
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)
2019-09-17
18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.AssertionError]]
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
[jira] [Updated] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
[
https://issues.apache.org/jira/browse/IGNITE-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-12200:
-
Description:
{code:java}
/**
* @param sndId Sender.
* @param ldrId Loader ID.
* @param userVer User version.
* @param depMode Deployment mode.
* @param participants Participants.
*/
private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
DeploymentMode depMode,
Map participants) {
assert sndId.equals(ldrId.globalId()) || participants != null;
this.sndId = sndId;
this.ldrId = ldrId;
this.userVer = userVer;
this.depMode = depMode;
this.participants = participants == null || participants.isEmpty() ? null :
new ConcurrentLinkedHashMap<>(participants);
}
{code}
The code above may produce the following stacktrace, where AssertionError
should contain more informative message for better root cause analysis:
{noformat}
2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
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)
2019-09-17
18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR,
err=java.lang.AssertionError]]java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
[jira] [Created] (IGNITE-12200) More informative assertion message at constructor of CachedDeploymentInfo (GridCacheDeploymentManager class)
Dmitriy Sorokin created IGNITE-12200:
Summary: More informative assertion message at constructor of
CachedDeploymentInfo (GridCacheDeploymentManager class)
Key: IGNITE-12200
URL: https://issues.apache.org/jira/browse/IGNITE-12200
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.7.5, 2.5
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin
{code:java}
/**
* @param sndId Sender.
* @param ldrId Loader ID.
* @param userVer User version.
* @param depMode Deployment mode.
* @param participants Participants.
*/
private CachedDeploymentInfo(UUID sndId, IgniteUuid ldrId, String userVer,
DeploymentMode depMode,
Map participants) {
assert sndId.equals(ldrId.globalId()) || participants != null;
this.sndId = sndId;
this.ldrId = ldrId;
this.userVer = userVer;
this.depMode = depMode;
this.participants = participants == null || participants.isEmpty() ? null :
new ConcurrentLinkedHashMap<>(participants);
}
{code}
The code above may produce the following stacktrace, where AssertionError
should contain more informative message for better root cause analysis:
{noformat}
2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]2019-09-17
18:29:29.890[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message [senderId=4c071d12-325a-4bb1-a68d-cc910f636562,
msg=GridCacheQueryRequest [id=4922,
cacheName=com.sbt.limits.data.entity.LimitTemplateV1Entity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=4c071d12-325a-4bb1-a68d-cc910f636562, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=191, minorTopVer=0],
super=GridCacheIdMessage [cacheId=-724666788]]]java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1547)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:582)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
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)2019-09-17
18:29:29.912[ERROR][query-#1577440%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR,
err=java.lang.AssertionError]]java.lang.AssertionError: null at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
[jira] [Created] (IGNITE-11457) Prewarming of page memory after node restart
Dmitriy Sorokin created IGNITE-11457: Summary: Prewarming of page memory after node restart Key: IGNITE-11457 URL: https://issues.apache.org/jira/browse/IGNITE-11457 Project: Ignite Issue Type: New Feature Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin The essence of page memory prewarming feature is that after restarting the node is to load into memory those pages that were loaded before last shutdown. This approach allows to get fully prewarmed node or even cluster just after one has been restarted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10987) --skip-zeros flag of idle_verify command should filter out empty partitions regardless of the value of update counter
[ https://issues.apache.org/jira/browse/IGNITE-10987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749935#comment-16749935 ] Dmitriy Sorokin commented on IGNITE-10987: -- [~ivan.glukos], [~slava.koptilin], looks good to me. > --skip-zeros flag of idle_verify command should filter out empty partitions > regardless of the value of update counter > -- > > Key: IGNITE-10987 > URL: https://issues.apache.org/jira/browse/IGNITE-10987 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Current implementation excludes empty partitions then and only then the > update counter and partition hash equal to zero. > It seems that the condition can be simplified and we should take into account > partition hash and size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10497) jvm-pause-detector-worker should be JVM singleton
[
https://issues.apache.org/jira/browse/IGNITE-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706910#comment-16706910
]
Dmitriy Sorokin commented on IGNITE-10497:
--
Originally, implementation of LongJVMPauseDetector was static and there was one
jvm-pause-detector-worker per JVM. After implementation of IGNITE-8426
LongJVMPauseDetector ceased to be static and becomes a property of IgniteKernal.
I propose not only refactor LongJVMPauseDetector for using one per JVM
jvm-pause-detector-worker, but, moreover, use GarbageCollectorMXBean if it
available, and use jvm-pause-detector-worker only if not because it has
negative effect as incorrect detection of debug pauses as stw-pauses too.
> jvm-pause-detector-worker should be JVM singleton
> -
>
> Key: IGNITE-10497
> URL: https://issues.apache.org/jira/browse/IGNITE-10497
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> Debugging tests I see the following:
> {noformat}
> [2018-11-30 20:36:46,284][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest9] Possible too
> long JVM pause: 5861 milliseconds.
> [2018-11-30 20:36:46,287][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest4] Possible too
> long JVM pause: 5863 milliseconds.
> [2018-11-30 20:36:46,288][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest3] Possible too
> long JVM pause: 5864 milliseconds.
> [2018-11-30 20:36:46,288][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest2] Possible too
> long JVM pause: 5864 milliseconds.
> [2018-11-30 20:36:46,289][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest1] Possible too
> long JVM pause: 5864 milliseconds.
> [2018-11-30 20:36:46,290][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest0] Possible too
> long JVM pause: 5865 milliseconds.
> [2018-11-30 20:36:46,286][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest6] Possible too
> long JVM pause: 5863 milliseconds.
> [2018-11-30 20:36:46,286][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest8] Possible too
> long JVM pause: 5863 milliseconds.
> [2018-11-30 20:36:46,286][WARN
> ][jvm-pause-detector-worker][CacheConsistencyCheckOnReadTest5] Possible too
> long JVM pause: 5862 milliseconds.
> {noformat}
> Is there any reason to have more that one thread at one JVM?
> Let's make jvm-pause-detector-worker static singleton.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10355) Tx rollback failure on put operations with caches whose topology fails validation
[
https://issues.apache.org/jira/browse/IGNITE-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-10355:
-
Summary: Tx rollback failure on put operations with caches whose topology
fails validation (was: Tx rollback failure on put operations with caches whose
topology fails validation.)
> Tx rollback failure on put operations with caches whose topology fails
> validation
> -
>
> Key: IGNITE-10355
> URL: https://issues.apache.org/jira/browse/IGNITE-10355
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6, 2.7
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The issue may occur as stacktrace below:
> {noformat}
> [2018-10-12 18:47:28,351][ERROR][test-runner-#1][GridDhtColocatedCache]
> Failed to rollback transaction (cache may contain stale locks):
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> class org.apache.ignite.IgniteCheckedException: Failed to rollback
> transaction:
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:514)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3962)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.chainFinishFuture(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3864)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2948)
> at
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture.(GridFutureAdapter.java:574)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.chain(GridFutureAdapter.java:360)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2947)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:693)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:447)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2470)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2468)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4233)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2468)
> at
>
[jira] [Updated] (IGNITE-10355) Tx rollback failure on put operations with caches whose topology fails validation.
[
https://issues.apache.org/jira/browse/IGNITE-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-10355:
-
Ignite Flags: (was: Docs Required)
> Tx rollback failure on put operations with caches whose topology fails
> validation.
> --
>
> Key: IGNITE-10355
> URL: https://issues.apache.org/jira/browse/IGNITE-10355
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6, 2.7
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The issue may occur as stacktrace below:
> {noformat}
> [2018-10-12 18:47:28,351][ERROR][test-runner-#1][GridDhtColocatedCache]
> Failed to rollback transaction (cache may contain stale locks):
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> class org.apache.ignite.IgniteCheckedException: Failed to rollback
> transaction:
> GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
> xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
> nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
> state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
> nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0,
> label=null]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:514)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3962)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.chainFinishFuture(GridNearTxLocal.java:3950)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3864)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2966)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2948)
> at
> org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture.(GridFutureAdapter.java:574)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.chain(GridFutureAdapter.java:360)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2947)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:693)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:447)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2470)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2468)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4233)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2468)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
> at
>
[jira] [Created] (IGNITE-10355) Tx rollback failure on put operations with caches whose topology fails validation.
Dmitriy Sorokin created IGNITE-10355:
Summary: Tx rollback failure on put operations with caches whose
topology fails validation.
Key: IGNITE-10355
URL: https://issues.apache.org/jira/browse/IGNITE-10355
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6, 2.7
Reporter: Dmitriy Sorokin
Assignee: Dmitriy Sorokin
The issue may occur as stacktrace below:
{noformat}
[2018-10-12 18:47:28,351][ERROR][test-runner-#1][GridDhtColocatedCache]
Failed to rollback transaction (cache may contain stale locks):
GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0, label=null]
class org.apache.ignite.IgniteCheckedException: Failed to rollback transaction:
GridNearTxLocal[xid=95ce5f86661--08fd-9fc9--0002,
xidVersion=GridCacheVersion [topVer=150839241, order=1539359239257,
nodeOrder=2], concurrency=OPTIMISTIC, isolation=READ_COMMITTED,
state=ROLLED_BACK, invalidate=false, rollbackOnly=true,
nodeId=108e38a0-64e2-4da6-ab06-6db7e6ae9001, timeout=0, duration=0, label=null]
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:514)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:425)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3962)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$27.apply(GridNearTxLocal.java:3950)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.chainFinishFuture(GridNearTxLocal.java:3950)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3864)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2966)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$18.applyx(GridNearTxLocal.java:2948)
at
org.apache.ignite.internal.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:385)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
at
org.apache.ignite.internal.util.future.GridFutureAdapter$ChainFuture.(GridFutureAdapter.java:574)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.chain(GridFutureAdapter.java:360)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2947)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:693)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:447)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2470)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2468)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4233)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2468)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2449)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2426)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1089)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
...
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16623655#comment-16623655 ] Dmitriy Sorokin commented on IGNITE-8719: - [~NIzhikov], A chance is exists, but if is not critical, fix version can be moved to 2.8. > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.7 > > Attachments: IndexRebuildingTest.java > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589126#comment-16589126
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agura] While working on this task, I discovered several problems that I also
fixed in this context:
# Wrong points of metric update at PageMemoryNoStoreImpl class;
# File header size was added to value of 'allocated' field of FilePageStore
class, but substracted at usages of that value;
# Incorrect calculation of totalPersistenceSize variable value at the
checkMetricsConsistency method of IgnitePdsDataRegionMetricsTest class;
# Every-time creation of no-op implementation of AllocatedPageTracker
interface instead usage of singleton;
# ClusterNodeMetricsSelfTest and DataRegionMetricsSelfTest was fixed according
to new metric behaviour.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549465#comment-16549465 ] Dmitriy Sorokin commented on IGNITE-8719: - [~agoncharuk], I wrote the reproducer working by your scheme, but so far no confirmation for case when partially built index can be used. Look at my patch [#4380|https://github.com/apache/ignite/pull/4380], please, and tell me your opinion. > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.7 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549457#comment-16549457
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agura], I modified my solution with your proposal so one it is more simple
now, review my new patch, please.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9024) Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-9024: Summary: Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest (was: Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest) > Wrong usage of idxLatch in DynamicIndexAbstractConcurrentSelfTest > - > > Key: IGNITE-9024 > URL: https://issues.apache.org/jira/browse/IGNITE-9024 > Project: Ignite > Issue Type: Test >Affects Versions: 2.5 >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation > which allows synchronize indexing operations with other concurrent routines. > Transition to waiting for unblock indexing state being notified from > awaitIndexing method by countDown() call on idxLatch, which should be > awaiting on test thread, but calls of countDown() method on idxLatch > instances are present in that code points too. > Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9024) Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest
Dmitriy Sorokin created IGNITE-9024: --- Summary: Wrong usage of IdxLatch in DynamicIndexAbstractConcurrentSelfTest Key: IGNITE-9024 URL: https://issues.apache.org/jira/browse/IGNITE-9024 Project: Ignite Issue Type: Test Affects Versions: 2.5 Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin Fix For: 2.7 DynamicIndexAbstractConcurrentSelfTest has BlockingIndexing inplementation which allows synchronize indexing operations with other concurrent routines. Transition to waiting for unblock indexing state being notified from awaitIndexing method by countDown() call on idxLatch, which should be awaiting on test thread, but calls of countDown() method on idxLatch instances are present in that code points too. Replace of countDown() calls by await() calls on idxLatch instances is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8910) PagesList.takeEmptyPage may fail with AssertionError: type = 1
[
https://issues.apache.org/jira/browse/IGNITE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16532064#comment-16532064
]
Dmitriy Sorokin commented on IGNITE-8910:
-
[~ivan.glukos], review my patch, please!
> PagesList.takeEmptyPage may fail with AssertionError: type = 1
> --
>
> Key: IGNITE-8910
> URL: https://issues.apache.org/jira/browse/IGNITE-8910
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Even after IGNITE-8769 fix, we sometimes get an AssertionError from free list
> during update operation. Page with type PageIO#T_DATA appears in free list
> for some reason.
> Example hang on TC:
> https://ci.ignite.apache.org/viewLog.html?buildId=1442664=IgniteTests24Java8_PdsIndexingWalRecovery
> Example stacktrace:
> {noformat}
> [15:59:26]W: [org.apache.ignite:ignite-indexing]
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1e76dfc5
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1643)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1603)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2436)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1898)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1740)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1630)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1119)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:609)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2428)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2405)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> [15:59:26]W: [org.apache.ignite:ignite-indexing]at
>
[jira] [Commented] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530129#comment-16530129
]
Dmitriy Sorokin commented on IGNITE-7967:
-
[~agoncharuk], done.
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.7
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7967) DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at runtime
[
https://issues.apache.org/jira/browse/IGNITE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin reassigned IGNITE-7967:
---
Assignee: Dmitriy Sorokin
> DataRegionMetrics#totalAllocatedPages is invalid if metrics were enabled at
> runtime
> ---
>
> Key: IGNITE-7967
> URL: https://issues.apache.org/jira/browse/IGNITE-7967
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: iep-6
> Fix For: 2.6
>
>
> {{totalAllocatedPages}} is updated during runtime via callback. When metrics
> are enabled at runtime, some pages may be already allocated, thus the metric
> shows invalid value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-8719: --- Assignee: Dmitriy Sorokin > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Dmitriy Sorokin >Priority: Critical > Fix For: 2.6 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8742) Direct IO 2 suite is timed out by 'out of disk space' failure emulation test: WAL manager failure does not stoped execution
[
https://issues.apache.org/jira/browse/IGNITE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518111#comment-16518111
]
Dmitriy Sorokin commented on IGNITE-8742:
-
[~dpavlov], [~sergey-chugunov], review my patch #4158, please!
It should be merged after #4200.
> Direct IO 2 suite is timed out by 'out of disk space' failure emulation test:
> WAL manager failure does not stoped execution
> ---
>
> Key: IGNITE-8742
> URL: https://issues.apache.org/jira/browse/IGNITE-8742
> Project: Ignite
> Issue Type: Test
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1366882=buildResultsDiv=IgniteTests24Java8_PdsDirectIo2
> Test
> org.apache.ignite.internal.processors.cache.persistence.IgniteNativeIoWalFlushFsyncSelfTest#testFailAfterStart
> emulates problem with disc space using exception.
> In direct IO environment real IO with disk is performed, tmpfs is not used.
> Sometimes this error can come from rollover() of segment, failure handler
> reacted accordingly.
> {noformat}
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.i.pagemem.wal.StorageException: Unable
> to write]]
> class org.apache.ignite.internal.pagemem.wal.StorageException: Unable to write
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.writeBuffer(FsyncModeFileWriteAheadLogManager.java:2964)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2640)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flush(FsyncModeFileWriteAheadLogManager.java:2572)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2525)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.close(FsyncModeFileWriteAheadLogManager.java:2795)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$700(FsyncModeFileWriteAheadLogManager.java:2340)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.rollOver(FsyncModeFileWriteAheadLogManager.java:1029)
> at
> org.apache.ignite.internal.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.log(FsyncModeFileWriteAheadLogManager.java:673)
> {noformat}
> But test seems to be not able to stop, node stopper thread tries to stop
> cache, flush WAL. flush wait for rollover, which will never happen.
> {noformat}
> Thread [name="node-stopper", id=2836, state=WAITING, blockCnt=7, waitCnt=9]
> Lock
> [object=java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@47f6473,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitUninterruptibly(AbstractQueuedSynchronizer.java:1976)
> at o.a.i.i.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7473)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.flushOrWait(FsyncModeFileWriteAheadLogManager.java:2546)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.fsync(FsyncModeFileWriteAheadLogManager.java:2750)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager$FileWriteHandle.access$2000(FsyncModeFileWriteAheadLogManager.java:2340)
> at
> o.a.i.i.processors.cache.persistence.wal.FsyncModeFileWriteAheadLogManager.flush(FsyncModeFileWriteAheadLogManager.java:699)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1243)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stopCaches(GridCacheProcessor.java:969)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:943)
> at o.a.i.i.IgniteKernal.stop0(IgniteKernal.java:2289)
> at o.a.i.i.IgniteKernal.stop(IgniteKernal.java:2167)
> at o.a.i.i.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2588)
> -
[jira] [Commented] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518109#comment-16518109 ] Dmitriy Sorokin commented on IGNITE-8749: - [~sergey-chugunov], [~agoncharuk], review my patch, please! Additional TC runs of PDS suites are linked. > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-8749) Exception for "no space left" situation should be propagated to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reopened IGNITE-8749: - PR 4200 causes PDS 2 suites execution timeouts, PR 4220 needed to apply. > Exception for "no space left" situation should be propagated to FailureHandler > -- > > Key: IGNITE-8749 > URL: https://issues.apache.org/jira/browse/IGNITE-8749 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Sergey Chugunov >Assignee: Dmitriy Sorokin >Priority: Major > Fix For: 2.6 > > > For now if "no space left" situation is detected in > FileWriteAheadLogManager#formatFile method and corresponding exception is > thrown the exception doesn't get propagated to FailureHandler and node > continues working. > As "no space left" is a critical situation, corresponding exception should be > propagated to handler to make necessary actions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8821) Huge logs on BPlusTreeSelfTest put/remove family tests
[ https://issues.apache.org/jira/browse/IGNITE-8821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515745#comment-16515745 ] Dmitriy Sorokin commented on IGNITE-8821: - The run of "Basic 1" test suite seems enouth, but successfull run guarantees only after merging of IGNITE-8769. > Huge logs on BPlusTreeSelfTest put/remove family tests > -- > > Key: IGNITE-8821 > URL: https://issues.apache.org/jira/browse/IGNITE-8821 > Project: Ignite > Issue Type: Test > Components: general >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Minor > Labels: test > Fix For: 2.6 > > > A printLocks method generates huge count of ## XX log lines without any > more info assigned to. Avoiding the output of unnecessary non-informative > lines is suggested. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
