[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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [Created] (IGNITE-11381) Document XML task config format for UriDeploymentSpi
Denis Mekhanikov created IGNITE-11381:
-
Summary: Document XML task config format for UriDeploymentSpi
Key: IGNITE-11381
URL: https://issues.apache.org/jira/browse/IGNITE-11381
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
{{UriDeploymentSpi}} lets archives with deployed classes contain {{ignite.xml}}
file, describing tasks in the the archive. Format of this file should be
documented and examples should be provided.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11379) Drop support of GAR files
Denis Mekhanikov created IGNITE-11379: - Summary: 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 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)
[jira] [Created] (IGNITE-11380) Make UriDeploymentSpi support JAR files
Denis Mekhanikov created IGNITE-11380:
-
Summary: 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
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] [Created] (IGNITE-11371) Cache get operation with readThrough returns null if remove is performed concurrently
Denis Mekhanikov created IGNITE-11371:
-
Summary: 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
Reporter: Denis Mekhanikov
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] [Created] (IGNITE-11062) Calculating Compute Usage section contains confusing numbers
Denis Mekhanikov created IGNITE-11062: - Summary: Calculating Compute Usage section contains confusing numbers Key: IGNITE-11062 URL: https://issues.apache.org/jira/browse/IGNITE-11062 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 2.7 Reporter: Denis Mekhanikov Assignee: Prachi Garg [Calculating Compute Usage|https://apacheignite.readme.io/docs/capacity-planning#section-calculating-compute-usage] section on the capacity planning page contains pretty confusing results. One may get an impression, that SQL queries are faster than cache API, and SQL should be used everywhere it's possible. This is pretty far from the truth, so it's better to rework this section. Plus the provided link doesn't contain the mentioned results. It's better to specify a link to the following page and get benchmark results from it: [https://www.gridgain.com/resources/benchmarks/gridgain-benchmarks-results] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10959) Memory leaks in continuous query handlers
Denis Mekhanikov created IGNITE-10959: - Summary: 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 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 (v7.6.3#76005)
[jira] [Created] (IGNITE-10077) P2P class loading shouldn't be applied to continuous queries with autoUnsubscribe=false
Denis Mekhanikov created IGNITE-10077:
-
Summary: 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
Assignee: Denis Mekhanikov
{{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
(v7.6.3#76005)
[jira] [Created] (IGNITE-9899) Continuous query handlers are not called on backups when one-phase commit is used
Denis Mekhanikov created IGNITE-9899: Summary: Continuous query handlers are not called on backups when one-phase commit is used Key: IGNITE-9899 URL: https://issues.apache.org/jira/browse/IGNITE-9899 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Attachments: CacheContinuousQueryTxBackupTest.java Consider the following cache configuration: * Atomicity mode: Transactional * Cache mode: Partitioned * Backups: 1 If a continuous query is registered for such cache, then it's not processed on backup copies. It results in remote filters not being called on backups and lost events on changing topology. Test case is attached: [^CacheContinuousQueryTxBackupTest.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9794) Registration of a binary type with POJO field under topology lock leads to UnregisteredBinaryTypeException
Denis Mekhanikov created IGNITE-9794: Summary: Registration of a binary type with POJO field under topology lock leads to UnregisteredBinaryTypeException Key: IGNITE-9794 URL: https://issues.apache.org/jira/browse/IGNITE-9794 Project: Ignite Issue Type: Bug Affects Versions: 2.6 Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Fix For: 2.8 Attachments: BinaryMetadataRegistrationInsideEntryProcessorTest.java Please find attached test class with a reproducer. The exception was introduced in IGNITE-8926. Metadata registration should be retried when this exception is thrown, but it doesn't happen. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9615) SQL: Client driver throws "Updates are not supported" exception
Denis Mekhanikov created IGNITE-9615:
Summary: 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
Assignee: Denis Mekhanikov
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
(v7.6.3#76005)
[jira] [Created] (IGNITE-9389) Concurrent Cache#close and put/get operations lead to a deadlock
Denis Mekhanikov created IGNITE-9389: Summary: Concurrent Cache#close and put/get operations lead to a deadlock Key: IGNITE-9389 URL: https://issues.apache.org/jira/browse/IGNITE-9389 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.6 Reporter: Denis Mekhanikov Attachments: CacheConcurrentUseAndCloseTest.java When cache is closed on a client node, while it is being used concurrently in other threads, deadlock may occur. Test case, reproducing the problem is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9196) SQL: Memory leak in MapNodeResults
Denis Mekhanikov created IGNITE-9196:
Summary: SQL: Memory leak in MapNodeResults
Key: IGNITE-9196
URL: https://issues.apache.org/jira/browse/IGNITE-9196
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Denis Mekhanikov
When size of a SQL query result set is a multiple of {{Query#pageSize}}, then
{{MapQueryResult}} is never closed and removed from {{MapNodeResults#res}}
collection.
The following code leads to OOME when run with 1Gb heap:
{code:java}
public class MemLeakRepro {
public static void main(String[] args) {
Ignition.start(getConfiguration("server"));
try (Ignite client =
Ignition.start(getConfiguration("client").setClientMode(true))) {
IgniteCache cache = startPeopleCache(client);
int pages = 10;
int pageSize = 1024;
for (int i = 0; i < pages * pageSize; i++) {
Person p = new Person("Person #" + i, 25);
cache.put(i, p);
}
for (int i = 0; i < 1_000_000; i++) {
if (i % 1000 == 0)
System.out.println("Select iteration #" + i);
Query> qry = new SqlFieldsQuery("select * from people");
qry.setPageSize(pageSize);
QueryCursor> cursor = cache.query(qry);
cursor.getAll();
cursor.close();
}
}
}
private static IgniteConfiguration getConfiguration(String instanceName) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setIgniteInstanceName(instanceName);
TcpDiscoverySpi discoSpi = new TcpDiscoverySpi();
discoSpi.setIpFinder(new TcpDiscoveryVmIpFinder(true));
return igniteCfg;
}
private static IgniteCache startPeopleCache(Ignite node) {
CacheConfiguration cacheCfg = new
CacheConfiguration<>("cache");
QueryEntity qe = new QueryEntity(Integer.class, Person.class);
qe.setTableName("people");
cacheCfg.setQueryEntities(Collections.singleton(qe));
cacheCfg.setSqlSchema("PUBLIC");
return node.getOrCreateCache(cacheCfg);
}
public static class Person {
@QuerySqlField
private String name;
@QuerySqlField
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
}
}
{code}
At the same time it works perfectly fine, when there are, for example, {{pages
* (pageSize + 1)}} records in cache instead.
The reason for it is that {{MapQueryResult#fetchNextPage(...)}} method doesn't
return true, when the result set size is a multiple of the page size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9181) Continuous query with remote filter factory doesn't let nodes join
Denis Mekhanikov created IGNITE-9181: Summary: 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 Attachments: ContinuousQueryNodeJoinTest.java When continuous query is registered, that 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. Reproducer is in the attachment. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9156) SQL: Impossible to specify equality condition on sub-select field
Denis Mekhanikov created IGNITE-9156:
Summary: SQL: Impossible to specify equality condition on
sub-select field
Key: IGNITE-9156
URL: https://issues.apache.org/jira/browse/IGNITE-9156
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.6
Reporter: Denis Mekhanikov
Execution of the following sequence of SQL statements leads to an exception:
{code:sql}
CREATE TABLE PEOPLE (id int PRIMARY KEY, name varchar);
INSERT INTO PEOPLE(id, name) VALUES(1, 'Mike');
SELECT * FROM (SELECT * FROM People p) tmp WHERE tmp.name='Mike';{code}
Exception:
{noformat}
java.lang.ClassCastException: org.h2.table.TableView cannot be cast to
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2340)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2272)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2254)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1991)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1953)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1702)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
~[classes/:?]
... 12 more{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9043) Map field is registered as Object in BinaryType
Denis Mekhanikov created IGNITE-9043:
Summary: Map field is registered as Object in BinaryType
Key: IGNITE-9043
URL: https://issues.apache.org/jira/browse/IGNITE-9043
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 2.6
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Fix For: 2.7
When a binary type is registered during first insertion without use of
BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
It leads to inconvenience in further usage of this type over {{BinaryObject}}
interface.
The following code results in an exception:
{code:java}
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("cache");
cache.put(1, new ExamplePojo());
BinaryObject val = cache.withKeepBinary().get(1);
Map map = val.field("map");
map.put(1, "1");
BinaryObjectBuilder bldr = val.toBuilder();
bldr.setField("map", map);
bldr.build(); // Throws exception.
}
static class ExamplePojo {
Map map = new HashMap<>();
}
{code}
Stacktrace:
{noformat}
Exception in thread "main" class
org.apache.ignite.binary.BinaryObjectException: Wrong value has been set
[typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map,
fieldType=Object, assignedValueType=Map]
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8922) Discovery message delivery guarantee can be violated
Denis Mekhanikov created IGNITE-8922:
Summary: Discovery message delivery guarantee can be violated
Key: IGNITE-8922
URL: https://issues.apache.org/jira/browse/IGNITE-8922
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Attachments: PendingMessageResendTest.java
Under certain circumstances discovery messages may be delivered only to a part
of nodes.
It happens because pending messages are not resent due to data inconsistency in
{{ServerImpl#PendingMessages}} class. If {{discardId}} or {{customDiscardId}}
point to a message, that is not present in the queue, then other messages will
be skipped and won't be resent. It may happen, for example, when queue in
{{PendingMessages}} is overflown.
PFA test, that reproduces this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8917) IgniteOutOfMemory when performing putAll with configured pageEvictionMode
Denis Mekhanikov created IGNITE-8917:
Summary: IgniteOutOfMemory when performing putAll with configured
pageEvictionMode
Key: IGNITE-8917
URL: https://issues.apache.org/jira/browse/IGNITE-8917
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Denis Mekhanikov
Attachments: IgnitePdsPageEvictionBatchTest.java
When {{pageEvictionMode}} is configured and {{IgniteCache#putAll(...)}}
operations are performed, then page eviction may not be applied properly. It
results in IgniteOutOfMemory being thrown.
PFA test, reproducing the problem.
Exception:
{noformat}
Critical system error detected. Will be handled accordingly to configured
handler [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
[type=CRITICAL_ERROR, err=class o.a.i.i.mem.IgniteOutOfMemoryException: Out of
memory in data region [name=evicting-data-region, initSize=256.0 MiB,
maxSize=256.0 MiB, persistenceEnabled=false] Try the following:
^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies]]
class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Out of memory
in data region [name=evicting-data-region, initSize=256.0 MiB, maxSize=256.0
MiB, persistenceEnabled=false] Try the following:
^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies
at
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.allocatePage(PageMemoryNoStoreImpl.java:305)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.allocateDataPage(AbstractFreeList.java:464)
at
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.insertDataRow(AbstractFreeList.java:491)
at
org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:97)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1325)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:4955)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4750)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4464)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3083)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2977)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1726)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1703)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1610)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1272)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:370)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1755)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1882)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1735)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1627)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:812)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:664)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1068)
at
[jira] [Created] (IGNITE-8909) Visor shows unimplemented off-heap memory cache metric
Denis Mekhanikov created IGNITE-8909: Summary: Visor shows unimplemented off-heap memory cache metric Key: IGNITE-8909 URL: https://issues.apache.org/jira/browse/IGNITE-8909 Project: Ignite Issue Type: Task Components: visor Affects Versions: 2.5 Reporter: Denis Mekhanikov "Off-Heap Memory" metric in result of *cache -a* command is always 0. Cache memory metrics were replaced with the ones for data regions, so this metric is unlikely to be implemented. Off-Heap Memory metric should be removed from Visor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8649) Service assignments should be recalculated when deployment fails
Denis Mekhanikov created IGNITE-8649: Summary: Service assignments should be recalculated when deployment fails Key: IGNITE-8649 URL: https://issues.apache.org/jira/browse/IGNITE-8649 Project: Ignite Issue Type: Improvement Components: managed services Reporter: Denis Mekhanikov When a node fails to instantiate and initialize a service during deployment, coordinator should try to assign this service to another node. Deployment should be considered failed only when all suitable nodes failed to deploy the service. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8367) Implement hot redeployment of services
Denis Mekhanikov created IGNITE-8367: Summary: Implement hot redeployment of services Key: IGNITE-8367 URL: https://issues.apache.org/jira/browse/IGNITE-8367 Project: Ignite Issue Type: Improvement Components: managed services Reporter: Denis Mekhanikov There should be a way to update implementation of a deployed service without downtime of the cluster. it can be achieved by employing of the DeploymentSpi. When a service class changes, nodes should redeploy their services automatically, using a new version of the updated class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8366) Replace service instance parameter with a class name in ServiceConfiguration
Denis Mekhanikov created IGNITE-8366:
Summary: Replace service instance parameter with a class name in
ServiceConfiguration
Key: IGNITE-8366
URL: https://issues.apache.org/jira/browse/IGNITE-8366
Project: Ignite
Issue Type: Improvement
Components: managed services
Reporter: Denis Mekhanikov
{{ServiceConfiguration#service}} parameter should be replaced with a
{{className}}. All parameters, needed for service initialization, should be
provided as a map of properties in {{ServiceConfiguration}}.
This approach has two advantages:
# It allows service redeployment with changed classes, because there will be no
need to deserialize the service object.
# Changes of initialization parameters will be able to be detected, when manual
redeployment happens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8365) Introduce service failure events
Denis Mekhanikov created IGNITE-8365:
Summary: Introduce service failure events
Key: IGNITE-8365
URL: https://issues.apache.org/jira/browse/IGNITE-8365
Project: Ignite
Issue Type: Improvement
Components: managed services
Reporter: Denis Mekhanikov
When a deployed service is propagated to a new node, and it fails to
initialize, then a corresponding system event should be triggered in the
cluster.
This way a user will be able to handle situations, when services can't be
deployed on joining nodes.
Also, exceptions thrown from {{Service#execute}} method should trigger
corresponding events.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8364) Propagate deployed services to joining nodes
Denis Mekhanikov created IGNITE-8364: Summary: Propagate deployed services to joining nodes Key: IGNITE-8364 URL: https://issues.apache.org/jira/browse/IGNITE-8364 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Joining nodes should receive information about service configurations and assignments in discovery data, and deploy services, assigned to them, automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8363) Handle topology changes during service deployment
Denis Mekhanikov created IGNITE-8363: Summary: Handle topology changes during service deployment Key: IGNITE-8363 URL: https://issues.apache.org/jira/browse/IGNITE-8363 Project: Ignite Issue Type: Improvement Components: managed services Reporter: Denis Mekhanikov Topology changes should be handled correctly during service deployment process. Assignments recalculation should be triggered when necessary. Special attention should be paid to cases, when a coordinator or assigned nodes fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8362) Collect service deployment results asynchronously on coordinator
Denis Mekhanikov created IGNITE-8362: Summary: Collect service deployment results asynchronously on coordinator Key: IGNITE-8362 URL: https://issues.apache.org/jira/browse/IGNITE-8362 Project: Ignite Issue Type: Improvement Components: managed services Reporter: Denis Mekhanikov When service deployment discovery message is sent, assigned nodes should start the deployment asynchronously outside the discovery thread. Deployment results should be sent to the coordinator over communication. Deployment should be considered finished once all deployment result are collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8361) Use discovery messages for service deployment
Denis Mekhanikov created IGNITE-8361: Summary: Use discovery messages for service deployment Key: IGNITE-8361 URL: https://issues.apache.org/jira/browse/IGNITE-8361 Project: Ignite Issue Type: Improvement Components: managed services Reporter: Denis Mekhanikov Service deployment should be based on discovery messages distribution. The procedure is as follows: # Deploying node sends a message with a service configuration. # Coordinator calculates the assignments and sends them in another message. # Nodes check, whether they are assigned to deploy any services, and do so, if they are. Utility cache won't be needed after these changes are made. All its mentions should be removed from the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8279) Clients can't operate on services after deactivation
Denis Mekhanikov created IGNITE-8279:
Summary: 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
Affects Versions: 2.4
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Fix For: 2.6
Attachments: ServiceDeploymentAfterDeactivationTest.java
When this 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 in service
cache changes.
Find attached test, reproducing this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8205) Services are not redeployed when cluster is getting activated
Denis Mekhanikov created IGNITE-8205: Summary: Services are not redeployed when cluster is getting activated Key: IGNITE-8205 URL: https://issues.apache.org/jira/browse/IGNITE-8205 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Fix For: 2.5 Attachments: ServiceDeploymentOnActivationTest.java Steps to reproduce: # Start a node # Activate the cluster # Deploy a service # Deactivate the cluster # Activate the cluster Service is getting cancelled after the step 4, but not coming back after the step 5. Test class with a reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8010) Validate marshaller mappings on join
Denis Mekhanikov created IGNITE-8010: Summary: 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 Assignee: Denis Mekhanikov Fix For: 2.5 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 (v7.6.3#76005)
[jira] [Created] (IGNITE-7978) Recovery from WAL may result in JVM crash
Denis Mekhanikov created IGNITE-7978:
Summary: Recovery from WAL may result in JVM crash
Key: IGNITE-7978
URL: https://issues.apache.org/jira/browse/IGNITE-7978
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
{{GridCacheDatabaseSharedManager}} checks page tags, when acquiring page write
locks. If the actual tag doesn't match the expected value, then
{{PageSupport#writeLock}} method returns 0 pointer, which results in JVM crash.
A proposed solution here is to make {{GridCacheDatabaseSharedManager}} ignore
the page tag, i.e. use {{restore=true}} option in {{PageSupport#writeLock}}
method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes
Denis Mekhanikov created IGNITE-7794: Summary: Marshaller mappings are not saved to disk on joining nodes Key: IGNITE-7794 URL: https://issues.apache.org/jira/browse/IGNITE-7794 Project: Ignite Issue Type: Bug Affects Versions: 2.4 Reporter: Denis Mekhanikov Fix For: 2.5 Attachments: GridMarshallerMappingConsistencyTest.java Find attached test class. When a node connects to a cluster, that already has some marshaller mappings, they are not saved to disk on the joining node. It may result in "Unknown pair" error, if a cluster has persistence enabled, and a nodes without needed mappings start and try to read persisted data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
Denis Mekhanikov created IGNITE-7441: Summary: Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property Key: IGNITE-7441 URL: https://issues.apache.org/jira/browse/IGNITE-7441 Project: Ignite Issue Type: Task Reporter: Denis Mekhanikov IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to configure backward compatibility mode for service configuration classes. But since it was done in 1.9 and current version is completely incompatible with it, there is no point in keeping this property. Moreover, it is ignored after IGNITE-5145. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7347) Warning about page eviction, when persistence for different data region is enabled
Denis Mekhanikov created IGNITE-7347:
Summary: Warning about page eviction, when persistence for
different data region is enabled
Key: IGNITE-7347
URL: https://issues.apache.org/jira/browse/IGNITE-7347
Project: Ignite
Issue Type: Bug
Affects Versions: 2.3
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Priority: Trivial
Consider the following configuration:
{noformat}
{noformat}
It leads to the following warning on start: *Page eviction mode for
\[B_Region\] memory region is ignored because Ignite Native Persistence is
enabled*.
But page eviction is actually applied and work as expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7125) Cluster metrics for a single node differ from local metrics
Denis Mekhanikov created IGNITE-7125:
Summary: Cluster metrics for a single node differ from local
metrics
Key: IGNITE-7125
URL: https://issues.apache.org/jira/browse/IGNITE-7125
Project: Ignite
Issue Type: Bug
Affects Versions: 2.3
Reporter: Denis Mekhanikov
Some metrics, that perform aggregation of multiple values, have different
meanings for a local node and for a cluster. Local metrics perform aggregation
over time, but cluster metrics – over nodes in the cluster. As a result, you
can get different values of local metrics and cluster metrics, when there is
only one node in the cluster.
Here is a reproducer:
{code}
public class ExampleNodeStartup {
public static void main(String[] args) throws Exception {
Ignite ignite = Ignition.start();
while (true) {
ClusterMetrics locMetrics = ignite.cluster().localNode().metrics();
ClusterMetrics clusterMetrics = ignite.cluster().metrics();
System.out.println("averageCpuLoad: " +
"local=" + locMetrics.getAverageCpuLoad() +
"; cluster=" + clusterMetrics.getAverageCpuLoad());
System.out.println("maximumThreadCount: " +
"local=" + locMetrics.getMaximumThreadCount() +
"; cluster=" + clusterMetrics.getMaximumThreadCount());
Thread.sleep(200);
}
}
}
{code}
After some time values begin to differ.
All {{ClusterMetrics#getMaximum*}} and {{ClusterMetrics#getAverage*}} metrics
seem to have the same problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6863) visorcmd: 'cache -a' shows nodes that are not matched by nodeFilter
Denis Mekhanikov created IGNITE-6863: Summary: visorcmd: 'cache -a' shows nodes that are not matched by nodeFilter Key: IGNITE-6863 URL: https://issues.apache.org/jira/browse/IGNITE-6863 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: visor Affects Versions: 2.3 Reporter: Denis Mekhanikov 'cache -a' command shows all nodes in the detailed summary, even those, which are not matched by a configured node filter. Please find attached archive with the reproducing example project. LOCAL cache also has this issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6571) Service not found exception when calling service method before initialization finished
Denis Mekhanikov created IGNITE-6571:
Summary: Service not found exception when calling service method
before initialization finished
Key: IGNITE-6571
URL: https://issues.apache.org/jira/browse/IGNITE-6571
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
Priority: Minor
When trying to call a method of a service after its assignment is written to
cache, but before initialization is complete, then the following exception
appears in log:
{noformat}
[2017-10-06 16:33:14,688][ERROR][sys-#37%null%][GridTaskWorker] Failed to
obtain remote job result policy for result from ComputeTask.result(..) method
(will fail the whole task): GridJobResultImpl [job=C2 [c=ServiceProxyCallable
[mtdName=foo, svcName=testService, ignite=null]], sib=GridJobSiblingImpl
[sesId=1f1d3e1fe51-1d90f286-d1f5-452b-8e1e-621f218d0e3e,
jobId=3f1d3e1fe51-1d90f286-d1f5-452b-8e1e-621f218d0e3e,
nodeId=037457d8-e2d3-434b-8d34-70f152a3e777, isJobDone=false],
jobCtx=GridJobContextImpl
[jobId=3f1d3e1fe51-1d90f286-d1f5-452b-8e1e-621f218d0e3e, timeoutObj=null,
attrs={}], node=TcpDiscoveryNode [id=037457d8-e2d3-434b-8d34-70f152a3e777,
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.25.4.149],
sockAddrs=[/0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501,
latitude.gridgain.local/172.25.4.149:47501], discPort=47501, order=17,
intOrder=10, lastExchangeTime=1507296794313, loc=false,
ver=2.1.0#19700101-sha1:, isClient=false], ex=class
o.a.i.IgniteException: Service not found: testService, hasRes=true,
isCancelled=false, isOccupied=true]
class org.apache.ignite.IgniteException: Remote job threw user exception
(override or implement ComputeTask.result(..) method if you would like to have
automatic failover for this exception).
at
org.apache.ignite.compute.ComputeTaskAdapter.result(ComputeTaskAdapter.java:101)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1027)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(GridTaskWorker.java:1020)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6640)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.result(GridTaskWorker.java:1020)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:838)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1066)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
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.IgniteException: Service not found:
testService
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1850)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6608)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1181)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
... 7 more
Caused by: class
org.apache.ignite.internal.processors.service.GridServiceNotFoundException:
Service not found: testService
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:408)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
... 14 more
{noformat}
After that method call waits for initialization to finish and returns
successfully. Exception in log looks misleading and makes people think that
something went wrong, but actually everything works as
[jira] [Created] (IGNITE-6548) Improve service grid documentation
Denis Mekhanikov created IGNITE-6548: Summary: Improve service grid documentation Key: IGNITE-6548 URL: https://issues.apache.org/jira/browse/IGNITE-6548 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Priority: Minor Documentation should include information about the way how services configuration is stored. Currently it's unclear whether it is stored on all nodes, or only on nodes that are matched by the node filter, and in what cases services should be redeployed. It would be good to specify what actions are required to update service's implementation or configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6389) Cache.invoke fails on atomic cache with configured AccessedExpiryPolicy
Denis Mekhanikov created IGNITE-6389:
Summary: Cache.invoke fails on atomic cache with configured
AccessedExpiryPolicy
Key: IGNITE-6389
URL: https://issues.apache.org/jira/browse/IGNITE-6389
Project: Ignite
Issue Type: Bug
Reporter: Denis Mekhanikov
When calling {{invoke(...)}} on atomic cache with {{AccessedExpiryPolicy}}, and
the target key already exists in cache, then the following exception is thrown:
{noformat}
[2017-09-15 12:10:18,435][ERROR][main][GridDhtAtomicCache] Unexpected
exception during cache update
class org.apache.ignite.IgniteException: Runtime failure on search row:
org.apache.ignite.internal.processors.cache.tree.SearchRow@7334aada
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2481)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1944)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1797)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1689)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1170)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:879)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:837)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1338)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1384)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1348)
at org.apache.ignite.examples.ExpiryExample.main(ExpiryExample.java:67)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1253)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.initResultOnCancelUpdate(GridCacheMapEntry.java:4270)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4157)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:3921)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:2988)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2882)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1719)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1602)
... 18 more
Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException:
Failed to update keys (retry update if possible).: [1]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1269)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1648)
at
[jira] [Created] (IGNITE-6388) ExpiryPolicy is used incorrectly during invoke
Denis Mekhanikov created IGNITE-6388:
Summary: ExpiryPolicy is used incorrectly during invoke
Key: IGNITE-6388
URL: https://issues.apache.org/jira/browse/IGNITE-6388
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1, 2.0, 1.9, 1.8, 1.7
Reporter: Denis Mekhanikov
Behavior of {{invoke(...)}} regarding {{ExpiryPolicy}} doesn't conform to the
spec.
Based on {{EntryProcessor}} doc, the expected behavior is:
{code:java}
cache.invoke(key, (e, a) -> {
e.getValue(); // getExpiryForAccess()
e.setValue(2);
e.getValue();
e.setValue(3); // getExpiryForUpdate()
return e.getValue();
});
{code}
{code:java}
cache.invoke(key, (e, a) -> {
e.getValue(); // getExpiryForAccess()
e.remove();
e.getValue();
e.setValue(2); // getExpiryForUpdate()
return e.getValue();
});
{code}
{code:java}
cache.invoke(key, (e, a) -> {
e.getValue(); // getExpiryForAccess()
e.setValue(2);
e.getValue();
e.setValue(3);
e.remove();
return e.getValue();
});
{code}
Additionally, if {{CacheStore}} with read-through is configured, and the
accessed value wasn't loaded before, then {{getExpiryForCreation()}} should be
called.
Currently behavior depends on configured atomicity mode and none of observed
options conform to the spec.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6289) Remove "allOrNone" flag from IgniteServices#deployAll method
Denis Mekhanikov created IGNITE-6289:
Summary: Remove "allOrNone" flag from IgniteServices#deployAll
method
Key: IGNITE-6289
URL: https://issues.apache.org/jira/browse/IGNITE-6289
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
{{allOrNone}} flag in {{IgniteServices#deployAll}} method, introduced in
IGNITE-5145, looks counter-intuitive. It should be removed and
partial-deployment approach should be chosen as default.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6273) Move ServiceDeploymentException to org.apache.ignite.services package
Denis Mekhanikov created IGNITE-6273:
Summary: Move ServiceDeploymentException to
org.apache.ignite.services package
Key: IGNITE-6273
URL: https://issues.apache.org/jira/browse/IGNITE-6273
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov
Priority: Minor
Fix For: 2.3
{{ServiceDeploymentException}} is currently located in
{{org.apache.ignite.internal.processors.service}} package, which is internal.
But at the same time it is mentioned in {{IgniteService}} interface, which is a
part of the API.
It should be moved to {{org.apache.ignite.services}} package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6271) Fix ServicesTest in .NET part
Denis Mekhanikov created IGNITE-6271: Summary: Fix ServicesTest in .NET part Key: IGNITE-6271 URL: https://issues.apache.org/jira/browse/IGNITE-6271 Project: Ignite Issue Type: Test Reporter: Denis Mekhanikov IGNITE-5145 causes failures of some tests in ServiceTest class. The reason is changed services API and a new type of exception thrown from deployment methods. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
Denis Mekhanikov created IGNITE-6259: Summary: GridServiceProcessor may leave futures hanging on unstable topology Key: IGNITE-6259 URL: https://issues.apache.org/jira/browse/IGNITE-6259 Project: Ignite Issue Type: Bug Affects Versions: 2.1, 2.0, 1.9, 1.8, 1.7 Reporter: Denis Mekhanikov GridServiceProcessor subscribes to updates on the internal cache to get information about new deployments or cancellations of services. Some of such updates may be lost under conditions of unstable topology. It leads to services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6214) Client hangs when executing SQL updates
Denis Mekhanikov created IGNITE-6214: Summary: Client hangs when executing SQL updates Key: IGNITE-6214 URL: https://issues.apache.org/jira/browse/IGNITE-6214 Project: Ignite Issue Type: Bug Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Sometimes client may hang when performing concurrent SQL updates. Reproducing code is in the attachment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
