[jira] [Commented] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426808#comment-17426808 ] Denis Mekhanikov commented on IGNITE-13631: --- [~nizhikov], thanks for the review! I fixed your comments. Could you help with a merge? > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-13631: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) Release Note: Changed data storage metric names: WalFsyncTimeDuration -> WalFsyncDuration, WalFsyncTimeNum -> WalFsyncNum. > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419281#comment-17419281 ] Denis Mekhanikov commented on IGNITE-13631: --- [~nizhikov], maybe you can take a look? > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418346#comment-17418346 ] Denis Mekhanikov commented on IGNITE-13631: --- I resolved the conflicts in the PR. Should be good to merge. The failing tests clearly can't be a result of changed comments. [~agura], could you help with a review/merge? Here's the PR: https://github.com/apache/ignite/pull/9432 > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14505) Print information about striped pool in metrics for local node
[ https://issues.apache.org/jira/browse/IGNITE-14505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-14505: -- Release Note: Extend the metrics log message with information about the striped pool. > Print information about striped pool in metrics for local node > -- > > Key: IGNITE-14505 > URL: https://issues.apache.org/jira/browse/IGNITE-14505 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently only information about public and system thread pools are printed > in metrics for a local node. It would be good to have the same information > about striped pool as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14505) Print information about striped pool in metrics for local node
[ https://issues.apache.org/jira/browse/IGNITE-14505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317996#comment-17317996 ] Denis Mekhanikov commented on IGNITE-14505: --- [~ilyak] could you take a look at the fix? > Print information about striped pool in metrics for local node > -- > > Key: IGNITE-14505 > URL: https://issues.apache.org/jira/browse/IGNITE-14505 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently only information about public and system thread pools are printed > in metrics for a local node. It would be good to have the same information > about striped pool as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14505) Print information about striped pool in metrics for local node
Denis Mekhanikov created IGNITE-14505: - Summary: Print information about striped pool in metrics for local node Key: IGNITE-14505 URL: https://issues.apache.org/jira/browse/IGNITE-14505 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Currently only information about public and system thread pools are printed in metrics for a local node. It would be good to have the same information about striped pool as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
[
https://issues.apache.org/jira/browse/IGNITE-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-13399:
--
Comment: was deleted
(was: [~maliev] could you take a look?)
> CpuLoad metric reports -1 under Java 11 in embedded mode
>
>
> Key: IGNITE-13399
> URL: https://issues.apache.org/jira/browse/IGNITE-13399
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running a node in embedded mode under Java 11, the CpuLoad metric
> reports -1. The process needs to be started with the following option:
> {{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> We need to get rid of this requirement to run Java with additional flags to
> get proper values for the CpuLoad metric.
> Some investigation was done under the following issue:
> https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
[
https://issues.apache.org/jira/browse/IGNITE-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307160#comment-17307160
]
Denis Mekhanikov commented on IGNITE-13399:
---
[~maliev] could you take a look?
> CpuLoad metric reports -1 under Java 11 in embedded mode
>
>
> Key: IGNITE-13399
> URL: https://issues.apache.org/jira/browse/IGNITE-13399
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running a node in embedded mode under Java 11, the CpuLoad metric
> reports -1. The process needs to be started with the following option:
> {{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> We need to get rid of this requirement to run Java with additional flags to
> get proper values for the CpuLoad metric.
> Some investigation was done under the following issue:
> https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14349) Add query attributes to QueryHistoryTracker#qryHist and QueryHistory
Denis Mekhanikov created IGNITE-14349: - Summary: Add query attributes to QueryHistoryTracker#qryHist and QueryHistory Key: IGNITE-14349 URL: https://issues.apache.org/jira/browse/IGNITE-14349 Project: Ignite Issue Type: Improvement Components: sql Reporter: Denis Mekhanikov We want to see two additional metrics into an query history: enforceJoinOrder and lazy. Someone should add them to QueryHistoryTracker#qryHist and map to QueryHistory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
[
https://issues.apache.org/jira/browse/IGNITE-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-13399:
-
Assignee: Denis Mekhanikov
> CpuLoad metric reports -1 under Java 11 in embedded mode
>
>
> Key: IGNITE-13399
> URL: https://issues.apache.org/jira/browse/IGNITE-13399
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
>
> When running a node in embedded mode under Java 11, the CpuLoad metric
> reports -1. The process needs to be started with the following option:
> {{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> We need to get rid of this requirement to run Java with additional flags to
> get proper values for the CpuLoad metric.
> Some investigation was done under the following issue:
> https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13886) Change units of cache-related histograms to milliseconds
[ https://issues.apache.org/jira/browse/IGNITE-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253964#comment-17253964 ] Denis Mekhanikov commented on IGNITE-13886: --- This change can break existing dashboards, you are right. On the other hand, the change will make the metrics more usable. Work on the new metrics framework is still in progress, so I don't think we should preserve compatibility here. [~nizhikov], [~agura] what do you think? > Change units of cache-related histograms to milliseconds > > > Key: IGNITE-13886 > URL: https://issues.apache.org/jira/browse/IGNITE-13886 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Priority: Major > > Ignite has different metrics that have the "histogram" type: > * tx.nodeSystemTimeHistogram > * tx.nodeUserTimeHistogram > * pme.DurationHistogram > * pme.CacheOperationsBlockedDurationHistogram > * cache..GetTime > * cache..PutTime > * cache..RemoveTime > * cache..CommitTime > * cache..RollbackTime > First four have buckets corresponding to the amount of time the operation > took in milliseconds. > Cache-related histograms are measured in nanoseconds, while it would be > enough to use milliseconds there as well. > It's hard to distinguish between 1 and 10 nanoseconds > visually. > The following set of buckets should be used: > * 1 > * 10 > * 100 > * 250 > * 1000 > The values are provided in milliseconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13886) Change units of cache-related histograms to milliseconds
Denis Mekhanikov created IGNITE-13886: - Summary: Change units of cache-related histograms to milliseconds Key: IGNITE-13886 URL: https://issues.apache.org/jira/browse/IGNITE-13886 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Ignite has different metrics that have the "histogram" type: * tx.nodeSystemTimeHistogram * tx.nodeUserTimeHistogram * pme.DurationHistogram * pme.CacheOperationsBlockedDurationHistogram * cache..GetTime * cache..PutTime * cache..RemoveTime * cache..CommitTime * cache..RollbackTime First four have buckets corresponding to the amount of time the operation took in milliseconds. Cache-related histograms are measured in nanoseconds, while it would be enough to use milliseconds there as well. It's hard to distinguish between 1 and 10 nanoseconds visually. The following set of buckets should be used: * 1 * 10 * 100 * 250 * 1000 The values are provided in milliseconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13886) Change units of cache-related histograms to milliseconds
[ https://issues.apache.org/jira/browse/IGNITE-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253502#comment-17253502 ] Denis Mekhanikov commented on IGNITE-13886: --- [~NSAmelchev] it seems that you've added these metrics. Do you think we can convert buckets from nanoseconds to milliseconds? > Change units of cache-related histograms to milliseconds > > > Key: IGNITE-13886 > URL: https://issues.apache.org/jira/browse/IGNITE-13886 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Priority: Major > > Ignite has different metrics that have the "histogram" type: > * tx.nodeSystemTimeHistogram > * tx.nodeUserTimeHistogram > * pme.DurationHistogram > * pme.CacheOperationsBlockedDurationHistogram > * cache..GetTime > * cache..PutTime > * cache..RemoveTime > * cache..CommitTime > * cache..RollbackTime > First four have buckets corresponding to the amount of time the operation > took in milliseconds. > Cache-related histograms are measured in nanoseconds, while it would be > enough to use milliseconds there as well. > It's hard to distinguish between 1 and 10 nanoseconds > visually. > The following set of buckets should be used: > * 1 > * 10 > * 100 > * 250 > * 1000 > The values are provided in milliseconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240644#comment-17240644 ] Denis Mekhanikov commented on IGNITE-13631: --- [~agura] could you take a look? > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13631) Improve names and descriptions of data storage metrics
[ https://issues.apache.org/jira/browse/IGNITE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240629#comment-17240629 ] Denis Mekhanikov commented on IGNITE-13631: --- The following metrics were renamed: WalFsyncTimeDuration -> WalFsyncDuration WalFsyncTimeNum -> WalFsyncNum For other metrics only descriptions were changed. > Improve names and descriptions of data storage metrics > -- > > Key: IGNITE-13631 > URL: https://issues.apache.org/jira/browse/IGNITE-13631 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Data storage metrics have unclear descriptions. They need to be improved. > ||Metric||Description||Comment|| > |*WalLoggingRate*|Average number of WAL records per second written during the > last time interval.|The "time interval" part is unclear. Which time interval?| > |*WalFsyncTimeDuration*|Total duration of fsync|Why not just > *WalFsyncDuration*? > The description could be more verbose.| > |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The > description could be more verbose| > |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time > interval. |Over which time interval?| > |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in > milliseconds |The description doesn't match the name.| > |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the > last checkpoint or all checkpoints from the beginning?| > |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage > this is about. Is disk included, or is it just about memory?| > |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be > capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13487) Decrease logging level for exceptions thrown from compute engine
[
https://issues.apache.org/jira/browse/IGNITE-13487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240625#comment-17240625
]
Denis Mekhanikov commented on IGNITE-13487:
---
[~nizhikov] could you take a look?
> Decrease logging level for exceptions thrown from compute engine
>
>
> Key: IGNITE-13487
> URL: https://issues.apache.org/jira/browse/IGNITE-13487
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a compute job fails during execution, it leads to two error messages
> printed on different nodes:
> 1. {{Failed to execute job}} on the map node.
> 2. {{Failed to obtain remote job result policy for result from
> ComputeTask.result(..) method (will fail the whole task)}} on the reduce node.
> Also an exception is thrown from the {{execute()}} method that triggered this
> task.
> It seems that none of these errors should actually be shown to users. This
> information should be printed only if debug logging is enabled for the
> corresponding packages.
> The issue can be reproduced by running the following example:
> {code:java}
> public class ComputeException {
> public static void main(String[] args) {
> new ComputeException().run();
> }
> void run() {
> IgniteConfiguration igniteCfg =
> Ignition.loadSpringBean("config/ignite.xml", "ignite.cfg");
> igniteCfg.setClientMode(true);
> try (Ignite ignite = Ignition.start(igniteCfg)) {
> ignite.compute(ignite.cluster().forServers()).execute(new
> ErroneousTask(), null);
> }
> }
> public static class ErroneousTask extends ComputeTaskAdapter Object> {
> @Override public @NotNull Map
> map(List list,
> @Nullable Object o) throws IgniteException {
> LinkedHashMap map = new
> LinkedHashMap<>();
> for (ClusterNode node : list)
> map.put(new ErroneousJob(), node);
> return map;
> }
> @Override public @Nullable Object reduce(List list)
> throws IgniteException {
> return null;
> }
> }
> public static class ErroneousJob extends ComputeJobAdapter {
> @Override public Object execute() throws IgniteException {
> throw new IgniteException("I failed. Sorry :(");
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13642) Nodes fail when they meet objects of unknown type in metastorage
Denis Mekhanikov created IGNITE-13642:
-
Summary: Nodes fail when they meet objects of unknown type in
metastorage
Key: IGNITE-13642
URL: https://issues.apache.org/jira/browse/IGNITE-13642
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Denis Mekhanikov
When a node sees an object of a class that is missing on this node's classpath,
it fails with the following exception:
{noformat}
[16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.IgniteCheckedException: Failed to find class with given class loader for
unmarshalling (make sure same versions of all classes are available on all
nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
cls=example.ClientNode$BamboozleClass]]]
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
cls=example.ClientNode$BamboozleClass]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
... 11 more{noformat}
The result is that one node can write an object of some custom class to the
metastorage and make all other nodes fail.
The following reproducer can be used:
{code:java}
public class ClientNode {
public static void main(String[] args) throws IgniteCheckedException {
IgniteConfiguration igniteCfg = nodeConfiguration().setClientMode(true);
IgniteKernal ignite = (IgniteKernal) Ignition.start(igniteCfg);
DistributedMetaStorage metaStorage =
ignite.context().distributedMetastorage();
metaStorage.write("hey", new BamboozleClass());
}
private static IgniteConfiguration nodeConfiguration() {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
TcpDiscoverySpi discoverySpi = new
[jira] [Created] (IGNITE-13631) Improve names and descriptions of data storage metrics
Denis Mekhanikov created IGNITE-13631: - Summary: Improve names and descriptions of data storage metrics Key: IGNITE-13631 URL: https://issues.apache.org/jira/browse/IGNITE-13631 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Data storage metrics have unclear descriptions. They need to be improved. ||Metric||Description||Comment|| |*WalLoggingRate*|Average number of WAL records per second written during the last time interval.|The "time interval" part is unclear. Which time interval?| |*WalFsyncTimeDuration*|Total duration of fsync|Why not just *WalFsyncDuration*? The description could be more verbose.| |*WalFsyncTimeNum*|Total count of fsync|Why not just *WalFsyncNum*? The description could be more verbose| |*WalBuffPollSpinsRate*|WAL buffer poll spins number over the last time interval. |Over which time interval?| |*LastCheckpointMarkDuration*|Duration of the checkpoint lock wait in milliseconds |The description doesn't match the name.| |*CheckpointTotalTime*|Total duration of checkpoint|Is it the duration of the last checkpoint or all checkpoints from the beginning?| |*StorageSize*|Storage space allocated, in bytes.|It's unclear which storage this is about. Is disk included, or is it just about memory?| |*WalTotalSize*|Total size in bytes for storage wal files.|WAL should be capital. The grammar| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220775#comment-17220775
]
Denis Mekhanikov commented on IGNITE-12794:
---
[~alex_pl] we've merged it into our fork – GridGain, and it works fine there.
Let's merge it here as well.
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.10
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13398) NPE in IgniteServiceProcessor when destroying a cache
[
https://issues.apache.org/jira/browse/IGNITE-13398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219574#comment-17219574
]
Denis Mekhanikov commented on IGNITE-13398:
---
The patch looks good to me.
> NPE in IgniteServiceProcessor when destroying a cache
> --
>
> Key: IGNITE-13398
> URL: https://issues.apache.org/jira/browse/IGNITE-13398
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Denis Mekhanikov
>Assignee: Ilya Kazakov
>Priority: Major
> Attachments: Main.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Try running the attached reproducer: [^Main.java]. The following exception is
> printed to the logs:
> {noformat}
> Sep 03, 2020 12:13:58 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to notify direct custom event listener:
> DynamicCacheChangeBatch [id=c1d6e335471-6bafb375-9d3e-487a-974d-35927ae02c04,
> reqs=ArrayList [DynamicCacheChangeRequest [cacheName=foo, hasCfg=false,
> nodeId=5e41fda8-e749-432c-9832-7b1c6ee3d0c8, clientStartOnly=false,
> stop=true, destroy=false, disabledAfterStartfalse]],
> exchangeActions=ExchangeActions [startCaches=null, stopCaches=[foo],
> startGrps=[], stopGrps=[foo, destroy=true], resetParts=null,
> stateChangeRequest=null], startCaches=false]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.lambda$processDynamicCacheChangeRequest$6(IgniteServiceProcessor.java:1694)
> at java.util.Collection.removeIf(Collection.java:414)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.processDynamicCacheChangeRequest(IgniteServiceProcessor.java:1691)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.access$200(IgniteServiceProcessor.java:108)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:229)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:665)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13487) Decrease logging level for exceptions thrown from compute engine
[
https://issues.apache.org/jira/browse/IGNITE-13487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-13487:
--
Summary: Decrease logging level for exceptions thrown from compute engine
(was: Decrease logging level for exceptions throws from compute engine)
> Decrease logging level for exceptions thrown from compute engine
>
>
> Key: IGNITE-13487
> URL: https://issues.apache.org/jira/browse/IGNITE-13487
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
>
> When a compute job fails during execution, it leads to two error messages
> printed on different nodes:
> 1. {{Failed to execute job}} on the map node.
> 2. {{Failed to obtain remote job result policy for result from
> ComputeTask.result(..) method (will fail the whole task)}} on the reduce node.
> Also an exception is thrown from the {{execute()}} method that triggered this
> task.
> It seems that none of these errors should actually be shown to users. This
> information should be printed only if debug logging is enabled for the
> corresponding packages.
> The issue can be reproduced by running the following example:
> {code:java}
> public class ComputeException {
> public static void main(String[] args) {
> new ComputeException().run();
> }
> void run() {
> IgniteConfiguration igniteCfg =
> Ignition.loadSpringBean("config/ignite.xml", "ignite.cfg");
> igniteCfg.setClientMode(true);
> try (Ignite ignite = Ignition.start(igniteCfg)) {
> ignite.compute(ignite.cluster().forServers()).execute(new
> ErroneousTask(), null);
> }
> }
> public static class ErroneousTask extends ComputeTaskAdapter Object> {
> @Override public @NotNull Map
> map(List list,
> @Nullable Object o) throws IgniteException {
> LinkedHashMap map = new
> LinkedHashMap<>();
> for (ClusterNode node : list)
> map.put(new ErroneousJob(), node);
> return map;
> }
> @Override public @Nullable Object reduce(List list)
> throws IgniteException {
> return null;
> }
> }
> public static class ErroneousJob extends ComputeJobAdapter {
> @Override public Object execute() throws IgniteException {
> throw new IgniteException("I failed. Sorry :(");
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13487) Decrease logging level for exceptions throws from compute engine
Denis Mekhanikov created IGNITE-13487:
-
Summary: Decrease logging level for exceptions throws from compute
engine
Key: IGNITE-13487
URL: https://issues.apache.org/jira/browse/IGNITE-13487
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
When a compute job fails during execution, it leads to two error messages
printed on different nodes:
1. {{Failed to execute job}} on the map node.
2. {{Failed to obtain remote job result policy for result from
ComputeTask.result(..) method (will fail the whole task)}} on the reduce node.
Also an exception is thrown from the {{execute()}} method that triggered this
task.
It seems that none of these errors should actually be shown to users. This
information should be printed only if debug logging is enabled for the
corresponding packages.
The issue can be reproduced by running the following example:
{code:java}
public class ComputeException {
public static void main(String[] args) {
new ComputeException().run();
}
void run() {
IgniteConfiguration igniteCfg =
Ignition.loadSpringBean("config/ignite.xml", "ignite.cfg");
igniteCfg.setClientMode(true);
try (Ignite ignite = Ignition.start(igniteCfg)) {
ignite.compute(ignite.cluster().forServers()).execute(new
ErroneousTask(), null);
}
}
public static class ErroneousTask extends ComputeTaskAdapter {
@Override public @NotNull Map
map(List list,
@Nullable Object o) throws IgniteException {
LinkedHashMap map = new
LinkedHashMap<>();
for (ClusterNode node : list)
map.put(new ErroneousJob(), node);
return map;
}
@Override public @Nullable Object reduce(List list)
throws IgniteException {
return null;
}
}
public static class ErroneousJob extends ComputeJobAdapter {
@Override public Object execute() throws IgniteException {
throw new IgniteException("I failed. Sorry :(");
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
[
https://issues.apache.org/jira/browse/IGNITE-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202208#comment-17202208
]
Denis Mekhanikov commented on IGNITE-13399:
---
[~agura], yes, it's still actual. IGNITE-13306 addressed only the case of a
standalone node started using {{ignite.sh}}.
> CpuLoad metric reports -1 under Java 11 in embedded mode
>
>
> Key: IGNITE-13399
> URL: https://issues.apache.org/jira/browse/IGNITE-13399
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Mekhanikov
>Priority: Major
>
> When running a node in embedded mode under Java 11, the CpuLoad metric
> reports -1. The process needs to be started with the following option:
> {{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
> We need to get rid of this requirement to run Java with additional flags to
> get proper values for the CpuLoad metric.
> Some investigation was done under the following issue:
> https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13399) CpuLoad metric reports -1 under Java 11 in embedded mode
Denis Mekhanikov created IGNITE-13399:
-
Summary: CpuLoad metric reports -1 under Java 11 in embedded mode
Key: IGNITE-13399
URL: https://issues.apache.org/jira/browse/IGNITE-13399
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
When running a node in embedded mode under Java 11, the CpuLoad metric reports
-1. The process needs to be started with the following option:
{{--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED}}
We need to get rid of this requirement to run Java with additional flags to get
proper values for the CpuLoad metric.
Some investigation was done under the following issue:
https://issues.apache.org/jira/browse/IGNITE-13306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13398) NPE in IgniteServiceProcessor when destroying a cache
Denis Mekhanikov created IGNITE-13398:
-
Summary: NPE in IgniteServiceProcessor when destroying a cache
Key: IGNITE-13398
URL: https://issues.apache.org/jira/browse/IGNITE-13398
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
Attachments: Main.java
Try running the attached reproducer: [^Main.java]. The following exception is
printed to the logs:
{noformat}
Sep 03, 2020 12:13:58 PM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Failed to notify direct custom event listener: DynamicCacheChangeBatch
[id=c1d6e335471-6bafb375-9d3e-487a-974d-35927ae02c04, reqs=ArrayList
[DynamicCacheChangeRequest [cacheName=foo, hasCfg=false,
nodeId=5e41fda8-e749-432c-9832-7b1c6ee3d0c8, clientStartOnly=false, stop=true,
destroy=false, disabledAfterStartfalse]], exchangeActions=ExchangeActions
[startCaches=null, stopCaches=[foo], startGrps=[], stopGrps=[foo,
destroy=true], resetParts=null, stateChangeRequest=null], startCaches=false]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.lambda$processDynamicCacheChangeRequest$6(IgniteServiceProcessor.java:1694)
at java.util.Collection.removeIf(Collection.java:414)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.processDynamicCacheChangeRequest(IgniteServiceProcessor.java:1691)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor.access$200(IgniteServiceProcessor.java:108)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:232)
at
org.apache.ignite.internal.processors.service.IgniteServiceProcessor$3.onCustomEvent(IgniteServiceProcessor.java:229)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:665)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13306) CpuLoad metric return -1 under Java 11
[
https://issues.apache.org/jira/browse/IGNITE-13306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17172953#comment-17172953
]
Denis Mekhanikov commented on IGNITE-13306:
---
[~slukyanov], this fix doesn't work. The issue is that we try to access a
public method in an internal class. In case of OpenJDK Hotspot it's
{{com.sun.management.internal.OperatingSystemImpl}}.
The proper way to fix this issue would be to cast the used
{{java.lang.management.OperatingSystemMXBean}} object to
{{com.sun.management.OperatingSystemMXBean}} and use the method
{{OperatingSystemMXBean#getSystemCpuLoad}} from there. But in this case we will
rely on the Sun interface (which we probably already rely on).
Another option is to access this method through reflection using the public
interface somehow, but not the implementation class. This is better than the
first option only in case if there is another implementation of
{{OperatingSystemMXBean}} that has a {{getSystemCpuLoad}} method.
> CpuLoad metric return -1 under Java 11
> --
>
> Key: IGNITE-13306
> URL: https://issues.apache.org/jira/browse/IGNITE-13306
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Start cluster under Java 11.
> Observed:
> CpuLoad metric will return -1
> Expected:
> Real CpuLoad.
> We investigated this issue and found that under Java 11 code failed with
> following trace:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to get property value
> [property=processCpuTime,
> obj=com.sun.management.internal.OperatingSystemImpl@1dd92fe2] at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8306)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.getCpuLoad(GridDiscoveryManager.java:3131)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.run(GridDiscoveryManager.java:3093)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:364)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.base/java.lang.Thread.run(Thread.java:834) Caused by:
> java.lang.reflect.InaccessibleObjectException: Unable to make public long
> com.sun.management.internal.OperatingSystemImpl.getProcessCpuTime()
> accessible: module jdk.management does not "opens
> com.sun.management.internal" to unnamed module @35fb3008 at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:192) at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8297)
> ... 6 more
> {code}
> Under Java 8 metric has expected value.
>
> Solution:
> The behaviour is expected because in Java 11 the CPU load metrics is moved to
> JDK internal module which is not accessible by default. Adding the following
> line to the jvm in which Ignite node is started should solve the issue:
> {noformat}
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13288) Include few system events by default
[ https://issues.apache.org/jira/browse/IGNITE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167177#comment-17167177 ] Denis Mekhanikov commented on IGNITE-13288: --- The fix looks good to me. I left a minor comment in the PR. > Include few system events by default > > > Key: IGNITE-13288 > URL: https://issues.apache.org/jira/browse/IGNITE-13288 > Project: Ignite > Issue Type: Wish >Reporter: Aleksandr Kozhenkov >Assignee: Aleksandr Kozhenkov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > There are discovery events that are listened to by all nodes. > It will be useful to include these events to listen on all nodes by default > too: > - EVT_CLUSTER_ACTIVATED > - EVT_CLUSTER_DEACTIVATED > - EVT_BASELINE_CHANGED > - EVT_CLUSTER_STATE_CHANGED > > They all are rare, system and cluster-wide. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13306) CpuLoad metric return -1 under Java 11
[
https://issues.apache.org/jira/browse/IGNITE-13306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17167164#comment-17167164
]
Denis Mekhanikov commented on IGNITE-13306:
---
[~ibessonov] there are different possible ways to solve this issue.
One of them is to cast the {{java.lang.management.OperatingSystemMXBean}} to
{{com.sun.management.OperatingSystemMXBean}} and call {{getProcessCpuTime()}}
directly. This way metrics will only work on those JVMs that have
{{com.sun.management.OperatingSystemMXBean}}, which is platform-specific.
Another way is to figure out how to call {{getProcessCpuTime()}} via reflection
without violating any checks. It's possible that there are other
implementations of {{java.lang.management.OperatingSystemMXBean}} that have
this method. But even if you remove the call to {{setAccessible(true)}}, then
the exception will be thrown anyways, since the internal class
{{OperatingSystemImpl}} will be used, even though a public interface is present.
So, I suggest merging this change as a temporary workaround that will work for
most cases, and see how it can be fixed properly in a separate ticket.
> CpuLoad metric return -1 under Java 11
> --
>
> Key: IGNITE-13306
> URL: https://issues.apache.org/jira/browse/IGNITE-13306
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Start cluster under Java 11.
> Observed:
> CpuLoad metric will return -1
> Expected:
> Real CpuLoad.
> We investigated this issue and found that under Java 11 code failed with
> following trace:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to get property value
> [property=processCpuTime,
> obj=com.sun.management.internal.OperatingSystemImpl@1dd92fe2] at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8306)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.getCpuLoad(GridDiscoveryManager.java:3131)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$MetricsUpdater.run(GridDiscoveryManager.java:3093)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:364)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119) at
> java.base/java.lang.Thread.run(Thread.java:834) Caused by:
> java.lang.reflect.InaccessibleObjectException: Unable to make public long
> com.sun.management.internal.OperatingSystemImpl.getProcessCpuTime()
> accessible: module jdk.management does not "opens
> com.sun.management.internal" to unnamed module @35fb3008 at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
> at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:192) at
> org.apache.ignite.internal.util.IgniteUtils.property(IgniteUtils.java:8297)
> ... 6 more
> {code}
> Under Java 8 metric has expected value.
>
> Solution:
> The behaviour is expected because in Java 11 the CPU load metrics is moved to
> JDK internal module which is not accessible by default. Adding the following
> line to the jvm in which Ignite node is started should solve the issue:
> {noformat}
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152703#comment-17152703 ] Denis Mekhanikov commented on IGNITE-10417: --- [~alex_pl] it doesn't seem that Pavel is working on this issue anymore. The patch is not ready to be merged. [~voropava] can we mark it as open and unassigned, or do you have plans on resuming your work? > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.9 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10077) P2P class loading shouldn't be applied to continuous queries with autoUnsubscribe=false
[
https://issues.apache.org/jira/browse/IGNITE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-10077:
-
Assignee: (was: Denis Mekhanikov)
> P2P class loading shouldn't be applied to continuous queries with
> autoUnsubscribe=false
> ---
>
> Key: IGNITE-10077
> URL: https://issues.apache.org/jira/browse/IGNITE-10077
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Mekhanikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ContinuousQuery#autoUnsubscribe}} flag makes it possible to deploy a
> continuous query, which won't be undeployed, when the subscriber node leaves.
> P2P class loading is not applicable in these settings, because when the
> subscriber leaves topology, it becomes impossible to load any classes from it
> to new nodes.
> So, P2P class loading should be disabled for continuous queries with
> {{autoUnsubscribe=false}}
> Dev list discussion:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-query-deployment-td36732.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8010) Validate marshaller mappings on join
[ https://issues.apache.org/jira/browse/IGNITE-8010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov reassigned IGNITE-8010: Assignee: (was: Denis Mekhanikov) > Validate marshaller mappings on join > > > Key: IGNITE-8010 > URL: https://issues.apache.org/jira/browse/IGNITE-8010 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a new node joins topology, it sends its marshaller mappings in a > discovery join message. > Additional validation should be implemented to make nodes with conflicting > marshaller mappings be rejected from connecting to the cluster. > Such procedure is already implemented for binary metadata. Marshaller > mappings should be validated in a similar way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067610#comment-17067610
]
Denis Mekhanikov commented on IGNITE-12702:
---
I only see a possibility to write such warnings when IgniteCache#put is
performed. But we need to throttle such messages and make sure that no
performance impact is going to be introduced in this case. For log throttling
check out the following class: GridLogThrottle
Alternatively it can be a moment of type registration. But as far as I know, we
don't propagate the information whether the object is going to be used as a key
or a value to the code that performs the type registration.
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Assignee: Kartik Somani
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061635#comment-17061635
]
Denis Mekhanikov commented on IGNITE-12794:
---
A patch is ready: [https://github.com/apache/ignite/pull/7541]
[~gvvinblade] could you help with a review?
Thanks!
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8.1
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-12794:
--
Reviewer: Igor Seliverstov
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8.1
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
Denis Mekhanikov created IGNITE-12794:
-
Summary: Scan query fails with an assertion error: Unexpected row
key
Key: IGNITE-12794
URL: https://issues.apache.org/jira/browse/IGNITE-12794
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Attachments: ScanQueryExample.java
Scan query fails with an exception:
{noformat}
Exception in thread "main" java.lang.AssertionError: Unexpected row key
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
at scan.ScanQueryExample.main(ScanQueryExample.java:31)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)"
{noformat}
The issue is reproduced when performing concurrent scan queries and updates. A
reproducer is attached. You will need to enable asserts in order to reproduce
this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12503) Fix SSL configuration in Jetty REST: httpCfg assignment
[
https://issues.apache.org/jira/browse/IGNITE-12503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060291#comment-17060291
]
Denis Mekhanikov commented on IGNITE-12503:
---
This is a minor thing, so feel free to keep it the way you have it.
Please continue with a merge.
> Fix SSL configuration in Jetty REST: httpCfg assignment
> ---
>
> Key: IGNITE-12503
> URL: https://issues.apache.org/jira/browse/IGNITE-12503
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Labels: easyfix
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
> {code}
> should become
> {code}
> class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
> {code}
> Or this assignment is not being made.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12503) Fix SSL configuration in Jetty REST: httpCfg assignment
[
https://issues.apache.org/jira/browse/IGNITE-12503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17060131#comment-17060131
]
Denis Mekhanikov commented on IGNITE-12503:
---
[~ilyak] all examples of such configuration I could find in the documentation
have a name of the argument specified explicitly. You can find an example here:
[https://www.eclipse.org/jetty/documentation/9.4.x/configuring-connectors.html]
Do you know if that's a recommended way?
Otherwise looks good.
> Fix SSL configuration in Jetty REST: httpCfg assignment
> ---
>
> Key: IGNITE-12503
> URL: https://issues.apache.org/jira/browse/IGNITE-12503
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Labels: easyfix
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
> {code}
> should become
> {code}
> class="org.eclipse.jetty.server.HttpConnectionFactory">
>
>
> {code}
> Or this assignment is not being made.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12753) Cache SSL contexts in SslContextFactory
[ https://issues.apache.org/jira/browse/IGNITE-12753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056733#comment-17056733 ] Denis Mekhanikov commented on IGNITE-12753: --- [~ilyak] the tests are green. Could you help with a merge? > Cache SSL contexts in SslContextFactory > --- > > Key: IGNITE-12753 > URL: https://issues.apache.org/jira/browse/IGNITE-12753 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > When SSL is enabled in a cluster, SslContextFactory#createSslContext is > created every time when connections between nodes are created. It involves > accessing key storage on disk. It may slow down creation of new communication > connections and block striped pool threads if disks are slow. > SSL contexts are stateless and can be shared between threads, so it's safe to > create an SSL context once and use the same instance every time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12753) Cache SSL contexts in SslContextFactory
Denis Mekhanikov created IGNITE-12753: - Summary: Cache SSL contexts in SslContextFactory Key: IGNITE-12753 URL: https://issues.apache.org/jira/browse/IGNITE-12753 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov When SSL is enabled in a cluster, SslContextFactory#createSslContext is created every time when connections between nodes are created. It involves accessing key storage on disk. It may slow down creation of new communication connections and block striped pool threads if disks are slow. SSL contexts are stateless and can be shared between threads, so it's safe to create an SSL context once and use the same instance every time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-12702:
--
Labels: newbie (was: )
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
Denis Mekhanikov created IGNITE-12702:
-
Summary: Print warning when a cache value contains
@AffinityKeyMapped annotation
Key: IGNITE-12702
URL: https://issues.apache.org/jira/browse/IGNITE-12702
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Denis Mekhanikov
Consider the following code snippet:
{code:java}
public class WrongAffinityExample {
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
IgniteCache cache =
ignite.getOrCreateCache("employees");
EmployeeKey key = new EmployeeKey(1);
EmployeeValue value = new EmployeeValue(1, "Denis");
cache.put(key, value);
}
public static class EmployeeKey {
private int id;
public EmployeeKey(int id) {
this.id = id;
}
}
public static class EmployeeValue {
@AffinityKeyMapped
int departmentId;
String name;
public EmployeeValue(int departmentId, String name) {
this.departmentId = departmentId;
this.name = name;
}
}
}
{code}
Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
which doesn't have any effect, since it's specified in a value, and not in a
key.
Such mistake is simple to make and pretty hard to track down.
This configuration should trigger a warning message printed in log to let the
user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12480) Add BinaryFieldExtractionSelfTest to the Binary Objects test suite
[ https://issues.apache.org/jira/browse/IGNITE-12480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002730#comment-17002730 ] Denis Mekhanikov commented on IGNITE-12480: --- A patch is ready. [~ilyak] could you help with a review? PR: https://github.com/apache/ignite/pull/7179 > Add BinaryFieldExtractionSelfTest to the Binary Objects test suite > -- > > Key: IGNITE-12480 > URL: https://issues.apache.org/jira/browse/IGNITE-12480 > Project: Ignite > Issue Type: Test > Components: binary >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > BinaryFieldExtractionSelfTest is not run on TeamCity because it's not > included into any test suite. > It should be added into IgniteBinaryObjectsTestSuite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12479) All binary types are registered twice
[
https://issues.apache.org/jira/browse/IGNITE-12479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002728#comment-17002728
]
Denis Mekhanikov commented on IGNITE-12479:
---
A patch is ready. [~sergey-chugunov] could you help with a review?
PR: https://github.com/apache/ignite/pull/7178
> All binary types are registered twice
> -
>
> Key: IGNITE-12479
> URL: https://issues.apache.org/jira/browse/IGNITE-12479
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a POJO is put into a cache, its binary type is registered twice during
> marshalling.
> Example:
> {code:java}
> public class MetadataRegistrationExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> Person p = new Person("Denis");
> ignite.getOrCreateCache("cache").put(1, p);
> }
> static class Person {
> private String name;
> public Person(String name) {
> this.name = name;
> }
> }
> }
> {code}
>
> Here is the generated debug log from the package
> {noformat}
> [23:31:14,020][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, changedSchemas=[],
> holder=null, fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928,
> ver=0]]]
> [23:31:14,023][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateProposedListener [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
> acceptedVer=0, schemasCnt=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Versions are stamped on coordinator [typeId=-1210012928, changedSchemas=[],
> pendingVer=1, acceptedVer=0]
> [23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Updated metadata on originating node: [typeId=-1210012928, pendingVer=1,
> acceptedVer=0]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
> [id=599e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
> acceptedVer=1, duplicated=false]
> [23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Completing future MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=1]] for [typeId=-1210012928, pendingVer=1,
> acceptedVer=1]
> [23:31:14,026][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=4ms,
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=1]],
> tx=null]
> [23:31:14,027][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person,
> changedSchemas=[1975878747], holder=[typeId=-1210012928, pendingVer=1,
> acceptedVer=1], fut=MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=0]]]
> [23:31:14,027][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateProposedListener [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
> acceptedVer=0, schemasCnt=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Versions are stamped on coordinator [typeId=-1210012928,
> changedSchemas=[1975878747], pendingVer=2, acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Updated metadata on originating node: [typeId=-1210012928, pendingVer=2,
> acceptedVer=1]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
> [id=d99e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
> acceptedVer=2, duplicated=false]
> [23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
> Completing future MetadataUpdateResultFuture [key=SyncKey
> [typeId=-1210012928, ver=2]] for [typeId=-1210012928, pendingVer=2,
> acceptedVer=2]
> [23:31:14,029][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed
> metadata update [typeId=-1210012928,
> typeName=binary.NestedObjectMarshallingExample$Person, waitTime=1ms,
> fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=2]],
> tx=null]
> {noformat}
> You can see, that a type is registered twice. First it's registered without
> any fields, and only the second
[jira] [Created] (IGNITE-12480) Add BinaryFieldExtractionSelfTest to the Binary Objects test suite
Denis Mekhanikov created IGNITE-12480: - Summary: Add BinaryFieldExtractionSelfTest to the Binary Objects test suite Key: IGNITE-12480 URL: https://issues.apache.org/jira/browse/IGNITE-12480 Project: Ignite Issue Type: Test Components: binary Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Fix For: 2.8 BinaryFieldExtractionSelfTest is not run on TeamCity because it's not included into any test suite. It should be added into IgniteBinaryObjectsTestSuite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12479) All binary types are registered twice
Denis Mekhanikov created IGNITE-12479:
-
Summary: All binary types are registered twice
Key: IGNITE-12479
URL: https://issues.apache.org/jira/browse/IGNITE-12479
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Fix For: 2.8
When a POJO is put into a cache, its binary type is registered twice during
marshalling.
Example:
{code:java}
public class MetadataRegistrationExample {
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
Person p = new Person("Denis");
ignite.getOrCreateCache("cache").put(1, p);
}
static class Person {
private String name;
public Person(String name) {
this.name = name;
}
}
}
{code}
Here is the generated debug log from the package
{noformat}
[23:31:14,020][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting metadata
update [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person, changedSchemas=[],
holder=null, fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928,
ver=0]]]
[23:31:14,023][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Received MetadataUpdateProposedListener [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
acceptedVer=0, schemasCnt=0]
[23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Versions are stamped on coordinator [typeId=-1210012928, changedSchemas=[],
pendingVer=1, acceptedVer=0]
[23:31:14,024][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Updated metadata on originating node: [typeId=-1210012928, pendingVer=1,
acceptedVer=0]
[23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
[id=599e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
acceptedVer=1, duplicated=false]
[23:31:14,025][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Completing future MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928,
ver=1]] for [typeId=-1210012928, pendingVer=1, acceptedVer=1]
[23:31:14,026][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed metadata
update [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person, waitTime=4ms,
fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=1]],
tx=null]
[23:31:14,027][DEBUG][main][CacheObjectBinaryProcessorImpl] Requesting metadata
update [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person,
changedSchemas=[1975878747], holder=[typeId=-1210012928, pendingVer=1,
acceptedVer=1], fut=MetadataUpdateResultFuture [key=SyncKey
[typeId=-1210012928, ver=0]]]
[23:31:14,027][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Received MetadataUpdateProposedListener [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person, pendingVer=0,
acceptedVer=0, schemasCnt=1]
[23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Versions are stamped on coordinator [typeId=-1210012928,
changedSchemas=[1975878747], pendingVer=2, acceptedVer=1]
[23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Updated metadata on originating node: [typeId=-1210012928, pendingVer=2,
acceptedVer=1]
[23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Received MetadataUpdateAcceptedMessage MetadataUpdateAcceptedMessage
[id=d99e0a86c61-183a790b-7038-4dd5-b99d-89f1483e3635, typeId=-1210012928,
acceptedVer=2, duplicated=false]
[23:31:14,028][DEBUG][disco-notifier-worker-#41][CacheObjectBinaryProcessorImpl]
Completing future MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928,
ver=2]] for [typeId=-1210012928, pendingVer=2, acceptedVer=2]
[23:31:14,029][DEBUG][main][CacheObjectBinaryProcessorImpl] Completed metadata
update [typeId=-1210012928,
typeName=binary.NestedObjectMarshallingExample$Person, waitTime=1ms,
fut=MetadataUpdateResultFuture [key=SyncKey [typeId=-1210012928, ver=2]],
tx=null]
{noformat}
You can see, that a type is registered twice. First it's registered without any
fields, and only the second time the type is registered properly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-9615) SQL: Client driver throws "Updates are not supported" exception
[
https://issues.apache.org/jira/browse/IGNITE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-9615:
Assignee: (was: Denis Mekhanikov)
> SQL: Client driver throws "Updates are not supported" exception
> ---
>
> Key: IGNITE-9615
> URL: https://issues.apache.org/jira/browse/IGNITE-9615
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Major
>
> When calling certain methods on Connection object, retrieved from a client
> JDBC driver, {{SQLFeatureNotSupportedException}} with message "Updates are
> not supported" is thrown.
> Affected methods:
> * {{JdbcConnection#setReadOnly(boolean)}}
> * {{JdbcConnection#prepareStatement(java.lang.String, int)}}
> * {{JdbcConnection#prepareStatement(java.lang.String, int[])}}
> * {{JdbcConnection#prepareStatement(java.lang.String, java.lang.String[])}}
> {{SetReadOnly}} method shouldn't throw this exception, and exceptions thrown
> from {{prepareStatement}} methods should have a proper description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12284) When service class not found on any server nodes, service not deployed without any error
[
https://issues.apache.org/jira/browse/IGNITE-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952038#comment-16952038
]
Denis Mekhanikov edited comment on IGNITE-12284 at 10/15/19 3:42 PM:
-
The error should be propagated to the deployer's site after IGNITE-3392
Current master shouldn't have this issue unless
{{IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED}} property is set to false.
was (Author: dmekhanikov):
The error should be propagated to the deployer's site after IGNITE-3392
Current master shouldn't have this issue.
> When service class not found on any server nodes, service not deployed
> without any error
>
>
> Key: IGNITE-12284
> URL: https://issues.apache.org/jira/browse/IGNITE-12284
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> When service class presents on client node but not on server node, the
> following is printed on server:
> {code}
> [17:57:43,398][SEVERE][srvc-deploy-#44][GridServiceProcessor] Failed to
> initialize service (service will not be deployed): FService
> class org.apache.ignite.IgniteCheckedException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10174)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:1440)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1361)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1988)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1615)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:126)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1597)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2064)
> 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.binary.BinaryInvalidTypeException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1758)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1717)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:102)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10168)
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: com.gridgain.datetest.MyService
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8775)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:698)
> ... 16 more
> {code}
> but on client, ServiceDeploymentException is not thrown. Instead, deploy
> returns normally.
> Code to reproduce:
> {code}
> public class ServiceStarterMain {
> public static void main(String[] args) {
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> ServiceConfiguration serviceConfiguration = new
> ServiceConfiguration();
> serviceConfiguration.setName("FService");
> serviceConfiguration.setMaxPerNodeCount(4);
> serviceConfiguration.setTotalCount(10);
> serviceConfiguration.setService(new
[jira] [Commented] (IGNITE-12284) When service class not found on any server nodes, service not deployed without any error
[
https://issues.apache.org/jira/browse/IGNITE-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952038#comment-16952038
]
Denis Mekhanikov commented on IGNITE-12284:
---
The error should be propagated to the deployer's site after IGNITE-3392
Current master shouldn't have this issue.
> When service class not found on any server nodes, service not deployed
> without any error
>
>
> Key: IGNITE-12284
> URL: https://issues.apache.org/jira/browse/IGNITE-12284
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> When service class presents on client node but not on server node, the
> following is printed on server:
> {code}
> [17:57:43,398][SEVERE][srvc-deploy-#44][GridServiceProcessor] Failed to
> initialize service (service will not be deployed): FService
> class org.apache.ignite.IgniteCheckedException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10174)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.copyAndInject(GridServiceProcessor.java:1440)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1361)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1988)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1615)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:126)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1597)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:2064)
> 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.binary.BinaryInvalidTypeException:
> com.gridgain.datetest.MyService
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1758)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1717)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:102)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10168)
> ... 10 more
> Caused by: java.lang.ClassNotFoundException: com.gridgain.datetest.MyService
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8775)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:349)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:698)
> ... 16 more
> {code}
> but on client, ServiceDeploymentException is not thrown. Instead, deploy
> returns normally.
> Code to reproduce:
> {code}
> public class ServiceStarterMain {
> public static void main(String[] args) {
> Ignition.setClientMode(true);
> Ignite ignite = Ignition.start();
> ServiceConfiguration serviceConfiguration = new
> ServiceConfiguration();
> serviceConfiguration.setName("FService");
> serviceConfiguration.setMaxPerNodeCount(4);
> serviceConfiguration.setTotalCount(10);
> serviceConfiguration.setService(new MyService());
> ignite.services().deploy(serviceConfiguration); // Exception
> expected, but does not happen
> }
> }
> {code}
> against a blank Ignite node started from bin distro.
> This affects Java and .Net.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948484#comment-16948484 ] Denis Mekhanikov commented on IGNITE-10959: --- [~mmuzaf] I haven't been working on this issue lately. Sorry for the misleading "in progress" status. I don't have a patch for it, so let's move it to the next release unless somebody wants to fix it before 2.8 is released. > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CacheContinuousQueryMemoryUsageTest.java > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov reassigned IGNITE-10959: - Assignee: (was: Denis Mekhanikov) > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CacheContinuousQueryMemoryUsageTest.java > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
[
https://issues.apache.org/jira/browse/IGNITE-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947697#comment-16947697
]
Denis Mekhanikov commented on IGNITE-9181:
--
This issue is resolved under IGNITE-3653
> Continuous query with remote filter factory doesn't let nodes join
> ---
>
> Key: IGNITE-9181
> URL: https://issues.apache.org/jira/browse/IGNITE-9181
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Attachments: ContinuousQueryNodeJoinTest.java
>
>
> When continuous query is registered from a client node and it has a remote
> filter factory configured, and P2P class loading is enabled, then all new
> nodes fail with an exception, which doesn't let them join the cluster.
> Exception:
> {noformat}
> [ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
> Runtime error caught during grid runnable execution: GridWorker
> [name=tcp-disco-msg-worker,
> igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
> hashCode=726450632, interrupted=false,
> runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
> nextNode=[null]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4502)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Reproducer is in the attachment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
[
https://issues.apache.org/jira/browse/IGNITE-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-9181:
-
Release Note: (was: This issue is resolved under IGNITE-3653)
> Continuous query with remote filter factory doesn't let nodes join
> ---
>
> Key: IGNITE-9181
> URL: https://issues.apache.org/jira/browse/IGNITE-9181
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Attachments: ContinuousQueryNodeJoinTest.java
>
>
> When continuous query is registered from a client node and it has a remote
> filter factory configured, and P2P class loading is enabled, then all new
> nodes fail with an exception, which doesn't let them join the cluster.
> Exception:
> {noformat}
> [ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
> Runtime error caught during grid runnable execution: GridWorker
> [name=tcp-disco-msg-worker,
> igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
> hashCode=726450632, interrupted=false,
> runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
> nextNode=[null]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4502)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Reproducer is in the attachment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
[
https://issues.apache.org/jira/browse/IGNITE-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov resolved IGNITE-9181.
--
Release Note: This issue is resolved under IGNITE-3653
Resolution: Duplicate
> Continuous query with remote filter factory doesn't let nodes join
> ---
>
> Key: IGNITE-9181
> URL: https://issues.apache.org/jira/browse/IGNITE-9181
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Attachments: ContinuousQueryNodeJoinTest.java
>
>
> When continuous query is registered from a client node and it has a remote
> filter factory configured, and P2P class loading is enabled, then all new
> nodes fail with an exception, which doesn't let them join the cluster.
> Exception:
> {noformat}
> [ERROR][tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%][TestTcpDiscoverySpi]
> Runtime error caught during grid runnable execution: GridWorker
> [name=tcp-disco-msg-worker,
> igniteInstanceName=continuous.ContinuousQueryNodeJoinTest1, finished=false,
> hashCode=726450632, interrupted=false,
> runner=tcp-disco-msg-worker-#15%continuous.ContinuousQueryNodeJoinTest1%],
> nextNode=[null]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.getEventFilter(CacheContinuousQueryHandlerV2.java:108)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.register(CacheContinuousQueryHandler.java:330)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.registerHandler(GridContinuousProcessor.java:1738)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onDiscoDataReceived(GridContinuousProcessor.java:646)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.onGridDataReceived(GridContinuousProcessor.java:538)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:889)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4502)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2804)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
> Reproducer is in the attachment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8279) Clients can't operate on services after deactivation
[
https://issues.apache.org/jira/browse/IGNITE-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946913#comment-16946913
]
Denis Mekhanikov commented on IGNITE-8279:
--
[~mmuzaf] this issue is not reproduced in the new implementation of the service
grid, that was done under the following IEP:
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid]
The issue appears only when {{IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED}}
environment property is set to false.
I guess, we can resolve this issue as "won't fix".
> Clients can't operate on services after deactivation
>
>
> Key: IGNITE-8279
> URL: https://issues.apache.org/jira/browse/IGNITE-8279
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Denis Mekhanikov
>Assignee: Pavel Vinokurov
>Priority: Major
> Fix For: 2.8
>
> Attachments: ServiceDeploymentAfterDeactivationTest.java
>
>
> When a cluster gets deactivated and activated back again, clients become
> incapable of service deployment. Calls to {{IgniteService.deploy*}} methods
> hang indefinitely, and no services are getting deployed to these clients.
> After deactivation, {{ServiceEntriesListener}} stops being invoked on service
> cache changes.
> Find attached test, reproducing this problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12265) JavaDoc doesn't have documentation for the org.apache.ignite.client package
Denis Mekhanikov created IGNITE-12265:
-
Summary: JavaDoc doesn't have documentation for the
org.apache.ignite.client package
Key: IGNITE-12265
URL: https://issues.apache.org/jira/browse/IGNITE-12265
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
JavaDoc published on the website doesn't have documentation for the
{{org.apache.ignite.client}} package. Link to the website:
[https://ignite.apache.org/releases/2.7.6/javadoc/]
A lack of {{package-info.java}} file or exclusion from the
{{maven-javadoc-plugin}} in the root {{pom.xml}} may be the reason.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12099) Don't write metadata to disk in discovery thread
[ https://issues.apache.org/jira/browse/IGNITE-12099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov reassigned IGNITE-12099: - Assignee: (was: Denis Mekhanikov) > Don't write metadata to disk in discovery thread > > > Key: IGNITE-12099 > URL: https://issues.apache.org/jira/browse/IGNITE-12099 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Denis Mekhanikov >Priority: Major > > When persistence is enabled, binary metadata is written to disk upon > registration. Currently it happens in the discovery thread, which makes > processing of related messages very slow. > A different thread should be used to write metadata to disk. Binary type > registration will be considered finished before information about it is > written to disks on all nodes. > The implementation should guarantee consistency in cases of cluster restarts. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12237) Forbid thin client connections dynamically
Denis Mekhanikov created IGNITE-12237: - Summary: Forbid thin client connections dynamically Key: IGNITE-12237 URL: https://issues.apache.org/jira/browse/IGNITE-12237 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Denis Mekhanikov Sometimes it's useful to forbid thin clients connections to nodes for some period of time. At this time cluster may be performing some activation needed for correct work of the application. It would be good to have an API call, opening and closing thin client connections. This feature was requested in the following StackOverflow question: https://stackoverflow.com/questions/58106297/how-to-block-java-thin-client-request-till-preloading-of-data-in-ignite-cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12099) Don't write metadata to disk in discovery thread
[ https://issues.apache.org/jira/browse/IGNITE-12099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov reassigned IGNITE-12099: - Assignee: Denis Mekhanikov > Don't write metadata to disk in discovery thread > > > Key: IGNITE-12099 > URL: https://issues.apache.org/jira/browse/IGNITE-12099 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > > When persistence is enabled, binary metadata is written to disk upon > registration. Currently it happens in the discovery thread, which makes > processing of related messages very slow. > A different thread should be used to write metadata to disk. Binary type > registration will be considered finished before information about it is > written to disks on all nodes. > The implementation should guarantee consistency in cases of cluster restarts. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12099) Don't write metadata to disk in discovery thread
[ https://issues.apache.org/jira/browse/IGNITE-12099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-12099: -- Description: When persistence is enabled, binary metadata is written to disk upon registration. Currently it happens in the discovery thread, which makes processing of related messages very slow. A different thread should be used to write metadata to disk. Binary type registration will be considered finished before information about it is written to disks on all nodes. The implementation should guarantee consistency in cases of cluster restarts. Dev list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html was: When persistence is enabled, binary metadata is written to disk upon registration. Currently it happens in the discovery thread, which makes processing of related messages very slow. A different thread should be used to write metadata to disk. Binary type registration will be considered finished before information about it will is written to disks on all nodes. The implementation should guarantee consistency in cases of cluster restarts. Dev list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html > Don't write metadata to disk in discovery thread > > > Key: IGNITE-12099 > URL: https://issues.apache.org/jira/browse/IGNITE-12099 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Denis Mekhanikov >Priority: Major > > When persistence is enabled, binary metadata is written to disk upon > registration. Currently it happens in the discovery thread, which makes > processing of related messages very slow. > A different thread should be used to write metadata to disk. Binary type > registration will be considered finished before information about it is > written to disks on all nodes. > The implementation should guarantee consistency in cases of cluster restarts. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12099) Don't write metadata to disk in discovery thread
Denis Mekhanikov created IGNITE-12099: - Summary: Don't write metadata to disk in discovery thread Key: IGNITE-12099 URL: https://issues.apache.org/jira/browse/IGNITE-12099 Project: Ignite Issue Type: Improvement Components: binary Reporter: Denis Mekhanikov When persistence is enabled, binary metadata is written to disk upon registration. Currently it happens in the discovery thread, which makes processing of related messages very slow. A different thread should be used to write metadata to disk. Binary type registration will be considered finished before information about it will is written to disks on all nodes. The implementation should guarantee consistency in cases of cluster restarts. Dev list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Asynchronous-registration-of-binary-metadata-td43021.html -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
[ https://issues.apache.org/jira/browse/IGNITE-10808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914111#comment-16914111 ] Denis Mekhanikov commented on IGNITE-10808: --- [~sergey-chugunov] Thanks a lot for the review! The tests don't show any blockers. [~DmitriyGovorukhin], could you help with a merge? > Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage > -- > > Key: IGNITE-10808 > URL: https://issues.apache.org/jira/browse/IGNITE-10808 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Stanislav Lukyanov >Assignee: Denis Mekhanikov >Priority: Major > Labels: discovery > Fix For: 2.8 > > Attachments: IgniteMetricsOverflowTest.java > > > A node receives a new metrics update message every `metricsUpdateFrequency` > milliseconds, and the message will be put at the top of the queue (because it > is a high priority message). > If processing one message takes more than `metricsUpdateFrequency` then > multiple `TcpDiscoveryMetricsUpdateMessage` will be in the queue. A long > enough delay (e.g. caused by a network glitch or GC) may lead to the queue > building up tens of metrics update messages which are essentially useless to > be processed. Finally, if processing a message on average takes a little more > than `metricsUpdateFrequency` (even for a relatively short period of time, > say, for a minute due to network issues) then the message worker will end up > processing only the metrics updates and the cluster will essentially hang. > Reproducer is attached. In the test, the queue first builds up and then very > slowly being teared down, causing "Failed to wait for PME" messages. > Need to change ServerImpl's SocketReader not to put another metrics update > message to the top of the queue if it already has one (or replace the one at > the top with new one). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-10808) Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
[
https://issues.apache.org/jira/browse/IGNITE-10808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912282#comment-16912282
]
Denis Mekhanikov commented on IGNITE-10808:
---
[~sergey-chugunov] , I reverted the changes for
{{TcpDiscoveryClientAckResponse}}. Now this is the only high priority message.
If we decide to remove high priority discovery messages completely, then let's
do it in a different ticket.
Also some refactoring was performed. Could you take another look?
> Discovery message queue may build up with TcpDiscoveryMetricsUpdateMessage
> --
>
> Key: IGNITE-10808
> URL: https://issues.apache.org/jira/browse/IGNITE-10808
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
> Labels: discovery
> Fix For: 2.8
>
> Attachments: IgniteMetricsOverflowTest.java
>
>
> A node receives a new metrics update message every `metricsUpdateFrequency`
> milliseconds, and the message will be put at the top of the queue (because it
> is a high priority message).
> If processing one message takes more than `metricsUpdateFrequency` then
> multiple `TcpDiscoveryMetricsUpdateMessage` will be in the queue. A long
> enough delay (e.g. caused by a network glitch or GC) may lead to the queue
> building up tens of metrics update messages which are essentially useless to
> be processed. Finally, if processing a message on average takes a little more
> than `metricsUpdateFrequency` (even for a relatively short period of time,
> say, for a minute due to network issues) then the message worker will end up
> processing only the metrics updates and the cluster will essentially hang.
> Reproducer is attached. In the test, the queue first builds up and then very
> slowly being teared down, causing "Failed to wait for PME" messages.
> Need to change ServerImpl's SocketReader not to put another metrics update
> message to the top of the queue if it already has one (or replace the one at
> the top with new one).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-6877) Improve behaviour for non-correlated subqueries
[ https://issues.apache.org/jira/browse/IGNITE-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879385#comment-16879385 ] Denis Mekhanikov commented on IGNITE-6877: -- No other tickets for this issue have been created yet, but the problem is still present. So, I'm for keeping the ticket open. Feel free to close as a duplicate, when another one is created. > Improve behaviour for non-correlated subqueries > --- > > Key: IGNITE-6877 > URL: https://issues.apache.org/jira/browse/IGNITE-6877 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Alin Andrei Corodescu >Priority: Minor > > Ignite behaves poorly in terms of performance when given queries which > contain IN or = operators followed by a non-correlated subquery. My guess is > that the query is actually run for each row of the table in order to test the > condition. > A possible solution is to store the results of the subquery in a temporary > table, and use it from there. > A workaround at the moment is to use joins instead of IN or = operators, but > this makes the query much more complicated. > Example: > SELECT name > FROM Employees > WHERE age IN (SELECT age FROM Customers) > The performance of this query is very slow for small amounts of data (about > 20 seconds for 4000 rows in each table last time I tried) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
[ https://issues.apache.org/jira/browse/IGNITE-11907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876990#comment-16876990 ] Denis Mekhanikov commented on IGNITE-11907: --- [~Pavlukhin] I looked through your changes. The approach looks valid to me. Please proceed with the patch. > Registration of continuous query should fail if nodes don't have remote > filter class > > > Key: IGNITE-11907 > URL: https://issues.apache.org/jira/browse/IGNITE-11907 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Assignee: Ivan Pavlukhin >Priority: Major > Attachments: > ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If one of data nodes doesn't have a remote filter class, then registration of > continuous queries should fail with an exception. Currently nodes fail > instead. > Reproducer is attached: > [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[ https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876274#comment-16876274 ] Denis Mekhanikov commented on IGNITE-3653: -- [~Pavlukhin], good catch, thanks. Fixed. > P2P doesn't work for remote filter and filter factory. > -- > > Key: IGNITE-3653 > URL: https://issues.apache.org/jira/browse/IGNITE-3653 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolai Tikhonov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > Attachments: CCP2PTest.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Remote filter and filter factory classes were not deployed on nodes which > join to cluster after their initialization. Test attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
[
https://issues.apache.org/jira/browse/IGNITE-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866601#comment-16866601
]
Denis Mekhanikov commented on IGNITE-11914:
---
It's actually a tricky question, what should be done in a situation, when
discovery data cannot be deserialized.
I would say, that if an existing node cannot deserialize data sent from a new
one, then the joining node should not be let into the cluster.
If we decide to always propagate such failures to the failure handler, then one
node with some class in discovery data, which is available on that node only,
will be able to bring down the whole cluster.
> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: DiscoveryDataDeserializationFailureHanderTest.java
>
>
> When a node during join receives a discovery data packet, that it cannot
> deserialize, then this error is printed to log and not handled in any way. It
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
>
[jira] [Commented] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
[
https://issues.apache.org/jira/browse/IGNITE-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866594#comment-16866594
]
Denis Mekhanikov commented on IGNITE-11914:
---
[~ibessonov] sorry, forgot to attach it.
Fixed.
> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: DiscoveryDataDeserializationFailureHanderTest.java
>
>
> When a node during join receives a discovery data packet, that it cannot
> deserialize, then this error is printed to log and not handled in any way. It
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at
[jira] [Updated] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
[
https://issues.apache.org/jira/browse/IGNITE-11914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-11914:
--
Attachment: DiscoveryDataDeserializationFailureHanderTest.java
> Failures to deserialize discovery data should be handled by a failure handler
> -
>
> Key: IGNITE-11914
> URL: https://issues.apache.org/jira/browse/IGNITE-11914
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.5
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: DiscoveryDataDeserializationFailureHanderTest.java
>
>
> When a node during join receives a discovery data packet, that it cannot
> deserialize, then this error is printed to log and not handled in any way. It
> leads to swallowing potentially important failures.
> For example, a failure to deserialize a continuous query remote filter should
> be propagated to a failure handler, but it doesn't happen. Test is attached.
> Error message:
> {noformat}
> Failed to unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
> at
> org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
> at
[jira] [Created] (IGNITE-11914) Failures to deserialize discovery data should be handled by a failure handler
Denis Mekhanikov created IGNITE-11914:
-
Summary: Failures to deserialize discovery data should be handled
by a failure handler
Key: IGNITE-11914
URL: https://issues.apache.org/jira/browse/IGNITE-11914
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.5
Reporter: Denis Mekhanikov
When a node during join receives a discovery data packet, that it cannot
deserialize, then this error is printed to log and not handled in any way. It
leads to swallowing potentially important failures.
For example, a failure to deserialize a continuous query remote filter should
be propagated to a failure handler, but it doesn't happen. Test is attached.
Error message:
{noformat}
Failed to unmarshal discovery data for component: 0
class org.apache.ignite.IgniteCheckedException: Failed to find class with given
class loader for unmarshalling (make sure same versions of all classes are
available on all nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
cls=org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:146)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshalZip(IgniteUtils.java:10068)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalData(DiscoveryDataPacket.java:292)
at
org.apache.ignite.spi.discovery.tcp.internal.DiscoveryDataPacket.unmarshalGridData(DiscoveryDataPacket.java:154)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:2065)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4882)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2964)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2696)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7527)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2818)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7458)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:61)
Caused by: java.lang.ClassNotFoundException:
org.apache.ignite.tests.p2p.CacheDeploymentEntryEventFilterFactory
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8672)
at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1863)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1746)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2037)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandlerV2.readExternal(CacheContinuousQueryHandlerV2.java:179)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:2113)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2062)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
at java.util.HashMap.readObject(HashMap.java:1409)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158)
at
[jira] [Created] (IGNITE-11907) Registration of continuous query should fail if nodes don't have remote filter class
Denis Mekhanikov created IGNITE-11907: - Summary: Registration of continuous query should fail if nodes don't have remote filter class Key: IGNITE-11907 URL: https://issues.apache.org/jira/browse/IGNITE-11907 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Denis Mekhanikov Attachments: ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java If one of data nodes doesn't have a remote filter class, then registration of continuous queries should fail with an exception. Currently nodes fail instead. Reproducer is attached: [^ContinuousQueryRemoteFilterMissingInClassPathSelfTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
[
https://issues.apache.org/jira/browse/IGNITE-11883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853064#comment-16853064
]
Denis Mekhanikov commented on IGNITE-11883:
---
AFAICS, invocation to {{primaryKey}} cannot generate a primary key for the
provided cache on a tested node. It means that the node has no primary
partitions available locally. Most probably, it's not in the baseline topology.
> Unable to find keys in testKeyAffinityDeploy
>
>
> Key: IGNITE-11883
> URL: https://issues.apache.org/jira/browse/IGNITE-11883
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Priority: Major
>
> After turn on IgniteConfigVariationsAbstractTest
> IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed
> - "Unable to find 1 required keys" [1].
> It is necessary to investigate the reason and fix the test.
> [1]
> https://ci.ignite.apache.org/viewLog.html?buildId=3978784=buildResultsDiv=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11110) UnsupportedOperationException: null when stopping grid
[
https://issues.apache.org/jira/browse/IGNITE-0?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-0:
--
Ignite Flags: (was: Docs Required)
> UnsupportedOperationException: null when stopping grid
> --
>
> Key: IGNITE-0
> URL: https://issues.apache.org/jira/browse/IGNITE-0
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Jens Borgland
>Priority: Major
>
> After upgrading to 2.7 we've started getting these errors when stopping grids:
> {noformat}
> java.lang.UnsupportedOperationException: null
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at org.apache.ignite.Ignition.stop(Ignition.java:225)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568)
> ~[ignite-core-2.7.0.jar:2.7.0]
> {noformat}
> At first glance it looks likely that it was introduced with commit
> [d04d764|https://github.com/apache/ignite/commit/d04d76440ce86873de7aebc8c03d39484cd1e3e5]
> (the {{GridJobProcessor}} still calls {{clear()}} on maps).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
Denis Mekhanikov created IGNITE-11854:
-
Summary: Serialization of arrays of primitives in python thin
client is not optimal
Key: IGNITE-11854
URL: https://issues.apache.org/jira/browse/IGNITE-11854
Project: Ignite
Issue Type: Bug
Components: thin client
Affects Versions: 2.7
Reporter: Denis Mekhanikov
The following code hangs indefinitely inside of invocation to {{my_cache.put()}}
{code:java}
from pyignite import Client
arr_len = 3_000_000
content = bytearray(arr_len)
for i in range(arr_len):
content[i] = i % 256
client = Client()
client.connect('127.0.0.1', 10800)
my_cache = client.get_or_create_cache('my cache')
my_cache.put("key_bin", content){code}
While the value is only 3MB in size. Implementation of serialization of
primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11792) Web console agent throws NullPointerException if node endpoint is incorrect
[
https://issues.apache.org/jira/browse/IGNITE-11792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-11792:
--
Ignite Flags: (was: Docs Required)
> Web console agent throws NullPointerException if node endpoint is incorrect
> ---
>
> Key: IGNITE-11792
> URL: https://issues.apache.org/jira/browse/IGNITE-11792
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
> Labels: web-console
>
> Starting web agent using the following command:
> {code:bash}
> ./ignite-web-agent.sh -n localhost:8080 -s https://console.gridgain.com/
> {code}
> Note, that {{localhost:8080}} is specified without the {{http://}} part. It
> leads to the following exception:
> {noformat}
> [ERROR][pool-1-thread-1][ClusterListener] WatchTask failed
> java.lang.NullPointerException
> at
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:185)
> at
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:237)
> at
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.restCommand(ClusterListener.java:421)
> at
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.topology(ClusterListener.java:457)
> at
> org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.run(ClusterListener.java:506)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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 {{localhost:8080}} format should either be supported or a reasonable
> error message should be printed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11792) Web console agent throws NullPointerException if node endpoint is incorrect
Denis Mekhanikov created IGNITE-11792:
-
Summary: Web console agent throws NullPointerException if node
endpoint is incorrect
Key: IGNITE-11792
URL: https://issues.apache.org/jira/browse/IGNITE-11792
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Denis Mekhanikov
Starting web agent using the following command:
{code:bash}
./ignite-web-agent.sh -n localhost:8080 -s https://console.gridgain.com/
{code}
Note, that {{localhost:8080}} is specified without the {{http://}} part. It
leads to the following exception:
{noformat}
[ERROR][pool-1-thread-1][ClusterListener] WatchTask failed
java.lang.NullPointerException
at
org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:185)
at
org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:237)
at
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.restCommand(ClusterListener.java:421)
at
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.topology(ClusterListener.java:457)
at
org.apache.ignite.console.agent.handlers.ClusterListener$WatchTask.run(ClusterListener.java:506)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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 {{localhost:8080}} format should either be supported or a reasonable error
message should be printed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11520) SQL schema is overwritten by static query entity configuration
[
https://issues.apache.org/jira/browse/IGNITE-11520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov resolved IGNITE-11520.
---
Resolution: Duplicate
> SQL schema is overwritten by static query entity configuration
> --
>
> Key: IGNITE-11520
> URL: https://issues.apache.org/jira/browse/IGNITE-11520
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8
>
>
> Steps to reproduce:
> 1. Start and restart a node with persistence enabled and the following cache
> configuration:
> {code}
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> 2. Execute the following DDL statement:
> {code}
> ALTER TABLE "cache".Person ADD COLUMN lastName varchar;
> {code}
> 3. Restart the node.
> After the restart Person table contains only two columns
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11380) Make UriDeploymentSpi support JAR files
[
https://issues.apache.org/jira/browse/IGNITE-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801620#comment-16801620
]
Denis Mekhanikov commented on IGNITE-11380:
---
Documentation ticket: IGNITE-11628
> Make UriDeploymentSpi support JAR files
> ---
>
> Key: IGNITE-11380
> URL: https://issues.apache.org/jira/browse/IGNITE-11380
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{UriDeploymentSpi}} doesn't support JAR files. Only GAR files can be used
> currently.
> It would be good to add possibility to provide classes to the
> {{UriDeployment}} packaged as plain JARs.
> Dev list discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/UriDeploymentSpi-and-GAR-files-td40869.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11628) Document the possibility to use JAR files in UriDeploymentSpi
[
https://issues.apache.org/jira/browse/IGNITE-11628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-11628:
--
Description:
{{UriDeploymentSpi}} got a possibility to support regular JAR files along with
GARs in IGNITE-11380
This possibility should be reflected in the documentation.
was:
{{UriDeploymentSpi}} got a possibility to support regular JAR files along with
GARs in https://issues.apache.org/jira/browse/IGNITE-11380
This possibility should be reflected in the documentation.
> Document the possibility to use JAR files in UriDeploymentSpi
> -
>
> Key: IGNITE-11628
> URL: https://issues.apache.org/jira/browse/IGNITE-11628
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Mekhanikov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.8
>
>
> {{UriDeploymentSpi}} got a possibility to support regular JAR files along
> with GARs in IGNITE-11380
> This possibility should be reflected in the documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11628) Document the possibility to use JAR files in UriDeploymentSpi
Denis Mekhanikov created IGNITE-11628:
-
Summary: Document the possibility to use JAR files in
UriDeploymentSpi
Key: IGNITE-11628
URL: https://issues.apache.org/jira/browse/IGNITE-11628
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Denis Mekhanikov
Assignee: Artem Budnikov
Fix For: 2.8
{{UriDeploymentSpi}} got a possibility to support regular JAR files along with
GARs in https://issues.apache.org/jira/browse/IGNITE-11380
This possibility should be reflected in the documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11575) Make UriDeploymentSpi ignore archives with untrusted signature
Denis Mekhanikov created IGNITE-11575:
-
Summary: Make UriDeploymentSpi ignore archives with untrusted
signature
Key: IGNITE-11575
URL: https://issues.apache.org/jira/browse/IGNITE-11575
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
{{UriDeploymentSpi}} checks whether a loaded JAR/GAR file has a correct
signature. But there is no way to specify the expected public key. So, it's
possible to perform a "man-in-the-middle" attack by amending an archive being
transferred from a remote storage to an Ignite node.
It's even possible just to remove the signature, and a completely unsigned file
will be processed without errors.
There should be a way to specify an expected public key, that should be used
while signing archives.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11371) Cache get operation with readThrough returns null if remove is performed concurrently
[
https://issues.apache.org/jira/browse/IGNITE-11371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796122#comment-16796122
]
Denis Mekhanikov commented on IGNITE-11371:
---
[~agoncharuk] the changes look good to me. Consider adding tests for
transactional caches and having at least one backup.
Also I think, it would be good to have a test like follows, just to fix the
behaviour:
{code:java}
@Test
public void testRemoveIsApplied() throws Exception {
startGrid(0);
IgniteEx client = startGrid("client");
IgniteCache cache = client.cache(TEST_CACHE);
String key = "key";
assertNotNull(cache.get(key));
IgniteFuture getFut = cache.getAsync(key);
cache.remove(key);
assertNotNull(getFut.get());
assertNull(cache.localPeek(key)); // Check, that remove actually takes
place.
assertNotNull(cache.get(key));
}
{code}
> Cache get operation with readThrough returns null if remove is performed
> concurrently
> -
>
> Key: IGNITE-11371
> URL: https://issues.apache.org/jira/browse/IGNITE-11371
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.8, 2.5, 2.7
>Reporter: Denis Mekhanikov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Attachments: IgniteInvalidationNullRunner.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider a situation, when you have a cache with {{CacheStore}} and
> {{readThrough}} configured.
> One may expect, that {{IgniteCache#get(...)}} operation will never return
> {{null}} for keys, that are present in the underlying {{CacheStore}}. But
> actually it's possible to get {{null}} in case if remove operation is called
> on the same key while {{CacheStore#load}} is running.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11543) TransactionOptimisticException on topology change when readThrough is enabled
Denis Mekhanikov created IGNITE-11543:
-
Summary: TransactionOptimisticException on topology change when
readThrough is enabled
Key: IGNITE-11543
URL: https://issues.apache.org/jira/browse/IGNITE-11543
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7
Reporter: Denis Mekhanikov
Attachments:
CacheOptimisticTransactionTopologyChangeReadThroughTest.java
When topology changes during an optimistic serializable transaction on a
replicated cache with {{readThrough}} enabled,
{{TransactionOptimisticException}} may appear.
Cache configuration:
{noformat}
cacheMode: REPLICATED
atomicityMode: TRANSACTIONAL
readThrough: true
{noformat}
Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11543) TransactionOptimisticException on topology change when readThrough is enabled
[
https://issues.apache.org/jira/browse/IGNITE-11543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-11543:
--
Attachment: (was:
CacheOptimisticTransactionTopologyChangeReadThroughTest.java)
> TransactionOptimisticException on topology change when readThrough is enabled
> -
>
> Key: IGNITE-11543
> URL: https://issues.apache.org/jira/browse/IGNITE-11543
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments:
> CacheOptimisticTransactionTopologyChangeReadThroughTest.java
>
>
> When topology changes during an optimistic serializable transaction on a
> replicated cache with {{readThrough}} enabled,
> {{TransactionOptimisticException}} may appear.
> Cache configuration:
> {noformat}
> cacheMode: REPLICATED
> atomicityMode: TRANSACTIONAL
> readThrough: true
> {noformat}
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11543) TransactionOptimisticException on topology change when readThrough is enabled
[
https://issues.apache.org/jira/browse/IGNITE-11543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-11543:
--
Attachment: CacheOptimisticTransactionTopologyChangeReadThroughTest.java
> TransactionOptimisticException on topology change when readThrough is enabled
> -
>
> Key: IGNITE-11543
> URL: https://issues.apache.org/jira/browse/IGNITE-11543
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments:
> CacheOptimisticTransactionTopologyChangeReadThroughTest.java
>
>
> When topology changes during an optimistic serializable transaction on a
> replicated cache with {{readThrough}} enabled,
> {{TransactionOptimisticException}} may appear.
> Cache configuration:
> {noformat}
> cacheMode: REPLICATED
> atomicityMode: TRANSACTIONAL
> readThrough: true
> {noformat}
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11531) Merge concurrent registrations of the same binary type
Denis Mekhanikov created IGNITE-11531:
-
Summary: Merge concurrent registrations of the same binary type
Key: IGNITE-11531
URL: https://issues.apache.org/jira/browse/IGNITE-11531
Project: Ignite
Issue Type: Improvement
Components: binary
Reporter: Denis Mekhanikov
When a binary type is registered multiple times simultaneously, then a lot of
type versions are generated with the same schema. It leads to long binary type
registration especially on big topologies.
The following code sample demonstrates the problem:
{code:java}
public class LongRegistration {
public static void main(String[] args) throws InterruptedException {
Ignite ignite = Ignition.start(igniteConfig());
int threadsNum = 50;
ExecutorService exec = Executors.newFixedThreadPool(threadsNum);
CyclicBarrier barrier = new CyclicBarrier(threadsNum);
long startTime = System.currentTimeMillis();
// register(ignite);
for (int i = 0; i < threadsNum; i++)
exec.submit(new TypeRegistrator(ignite, barrier));
exec.shutdown();
exec.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
System.out.println("Total registration time: " +
(System.currentTimeMillis() - startTime));
}
private static IgniteConfiguration igniteConfig() {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(Collections.singletonList("127.0.0.1:47500..47509"));
TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
discoverySpi.setLocalAddress("127.0.0.1");
discoverySpi.setLocalPort(47500);
discoverySpi.setIpFinder(ipFinder);
igniteCfg.setDiscoverySpi(discoverySpi);
return igniteCfg;
}
private static void register(Ignite ignite) {
long startTime = System.currentTimeMillis();
IgniteBinary binary = ignite.binary();
BinaryObjectBuilder builder = binary.builder("TestType");
builder.setField("intField", 1);
builder.build();
System.out.println("Registration time: " + (System.currentTimeMillis()
- startTime));
}
private static class TypeRegistrator implements Runnable {
private Ignite ignite;
private CyclicBarrier cyclicBarrier;
TypeRegistrator(Ignite ignite, CyclicBarrier cyclicBarrier) {
this.ignite = ignite;
this.cyclicBarrier = cyclicBarrier;
}
@Override public void run() {
try {
cyclicBarrier.await();
register(ignite);
} catch (InterruptedException | BrokenBarrierException e) {
e.printStackTrace();
}
}
}
}
{code}
This code sample leads to registration of 50 versions of the same type. The
effect is more noticeable if a cluster contains a lot of nodes.
If you uncomment the call to {{register()}} method, then overall registration
becomes 10 times faster on topology of 5 nodes.
Registration of matching types should be merged to avoid long processing of
such cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11520) SQL schema is overwritten by static query entity configuration
Denis Mekhanikov created IGNITE-11520:
-
Summary: SQL schema is overwritten by static query entity
configuration
Key: IGNITE-11520
URL: https://issues.apache.org/jira/browse/IGNITE-11520
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.7, 2.4
Reporter: Denis Mekhanikov
Fix For: 2.8
Steps to reproduce:
1. Start and restart a node with persistence enabled and the following cache
configuration:
{code}
{code}
2. Execute the following DDL statement:
{code}
ALTER TABLE "cache".Person ADD COLUMN lastName varchar;
{code}
3. Restart the node.
After the restart Person table contains only two columns
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Issue Type: Improvement (was: Bug) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Summary: Introduce a way to enable system data region metrics in configuration (was: DataStorageConfiguration.metricsEnabled flag is ignored) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime or in a specific `DataRegionConfiguration`. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Priority: Minor (was: Major) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Minor > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Currently system data region metrics can be only enabled at runtime. It would be convenient to have a configuration property, that will enable metrics for system data region, just like for any other data region. was:Currently system data region metrics can be only enabled in runtime. > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Currently system data region metrics can be only enabled in runtime. (was: Data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime or in a specific `DataRegionConfiguration`. Expected behaviour: `metricsEnabled` flag shouldn't be ignored.) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled in runtime. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) DataStorageConfiguration.metricsEnabled flag is ignored
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime or in a specific `DataRegionConfiguration`. Expected behaviour: `metricsEnabled` flag shouldn't be ignored. was: System data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime. Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system data region. > DataStorageConfiguration.metricsEnabled flag is ignored > --- > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime or in a specific `DataRegionConfiguration`. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) DataStorageConfiguration.metricsEnabled flag is ignored
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Summary: DataStorageConfiguration.metricsEnabled flag is ignored (was: System data region metrics are disabled regardless of metricsEnabled flag) > DataStorageConfiguration.metricsEnabled flag is ignored > --- > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > System data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system > data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) System data region metrics are disabled regardless of metricsEnabled flag
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Labels: metrics usability (was: ) > System data region metrics are disabled regardless of metricsEnabled flag > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > System data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system > data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11490) System data region metrics are disabled regardless of metricsEnabled flag
Denis Mekhanikov created IGNITE-11490: - Summary: System data region metrics are disabled regardless of metricsEnabled flag Key: IGNITE-11490 URL: https://issues.apache.org/jira/browse/IGNITE-11490 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Denis Mekhanikov System data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime. Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11384) Introduce an ability of services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16784671#comment-16784671 ] Denis Mekhanikov commented on IGNITE-11384: --- The changes look good to me. Please proceed with the merge. > Introduce an ability of services hot redeployment via DeploymentSpi > --- > > Key: IGNITE-11384 > URL: https://issues.apache.org/jira/browse/IGNITE-11384 > Project: Ignite > Issue Type: Sub-task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > We can integrate service processor with DeploymentSpi to introduce an > opportunity of services hot redeployment. For this change, the service > processor should try to get and use registered classloader registered for the > service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11371) Cache get operation with readThrough returns null if remove is performed concurrently
[
https://issues.apache.org/jira/browse/IGNITE-11371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782634#comment-16782634
]
Denis Mekhanikov commented on IGNITE-11371:
---
[~itsick] the workaround is to use
[IgniteCache#clear(...)|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#clear-K-]
method instead of remove. It removes the entry from cache only if no
operations are performed concurrently.
Currently nobody seems to be working on the fix, so you can take it over. At
this point it's unclear, if it's possible to guarantee consistency at all, when
readThrough is enabled, but writeThrough is disabled. We need to research this
point first.
> Cache get operation with readThrough returns null if remove is performed
> concurrently
> -
>
> Key: IGNITE-11371
> URL: https://issues.apache.org/jira/browse/IGNITE-11371
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.8, 2.5, 2.7
>Reporter: Denis Mekhanikov
>Priority: Major
> Attachments: IgniteInvalidationNullRunner.java
>
>
> Consider a situation, when you have a cache with {{CacheStore}} and
> {{readThrough}} configured.
> One may expect, that {{IgniteCache#get(...)}} operation will never return
> {{null}} for keys, that are present in the underlying {{CacheStore}}. But
> actually it's possible to get {{null}} in case if remove operation is called
> on the same key while {{CacheStore#load}} is running.
> Reproducer is attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11380) Make UriDeploymentSpi support JAR files
[
https://issues.apache.org/jira/browse/IGNITE-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-11380:
-
Assignee: Denis Mekhanikov
> Make UriDeploymentSpi support JAR files
> ---
>
> Key: IGNITE-11380
> URL: https://issues.apache.org/jira/browse/IGNITE-11380
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.8
>
>
> {{UriDeploymentSpi}} doesn't support JAR files. Only GAR files can be used
> currently.
> It would be good to add possibility to provide classes to the
> {{UriDeployment}} packaged as plain JARs.
> Dev list discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/UriDeploymentSpi-and-GAR-files-td40869.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11379) Drop support of GAR files
[ https://issues.apache.org/jira/browse/IGNITE-11379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774141#comment-16774141 ] Denis Mekhanikov commented on IGNITE-11379: --- It's fine to keep it till 3.0. But in 3.0 it should be dropped then. > Drop support of GAR files > - > > Key: IGNITE-11379 > URL: https://issues.apache.org/jira/browse/IGNITE-11379 > Project: Ignite > Issue Type: Task >Reporter: Denis Mekhanikov >Priority: Major > > GAR file format doesn't seem to be actually needed in Ignite. There are > virtually no tools for their assembly, and simple JARs with the same > structure could be used instead. > Dev list discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/UriDeploymentSpi-and-GAR-files-td40869.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
