[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20688: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Java Thin Client - Error while deserializing Collection > --- > > Key: IGNITE-20688 > URL: https://issues.apache.org/jira/browse/IGNITE-20688 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15 >Reporter: Rahul Mohan >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Attachments: image001.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > I have encountered an issue in deserializing cache values which are of > Collection type. > The issue occurs if a field in different objects within the collection > points to the same reference. > *Versions:* > org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0 > > {code:java} > Person.java > public class Person implements Serializable { > private String id; > private String firstName; > private String lastName; > private double salary; > private String country; > private String deleted; > private Set accounts; > } > Client > ClientCacheConfiguration cacheCfg = new > ClientCacheConfiguration().setName(cacheName). > setCacheMode(CacheMode.REPLICATED). > > setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC); > > cache = client.getOrCreateCache(cacheCfg); > > Set set = new HashSet<>(); > set.add("1"); > > List persons = new ArrayList<>(); > persons.add(new Person("105286a4","Jack","Smith",1f, > "USA","false", set)); > persons.add(new Person("98545b0fd3af","John", "Doe", 50f, > "Australia","false", null)); > persons.add(new Person("98545b0fd3afd","Hari","M",40f, > "India", null, null)); > persons.add(new > Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set)); > cache.put("group1", value) // Write collection to cache > > List persons = (List) cache.get("group1"); // Get > from cache, Exception here {code} > > *Exception:* > {code:java} > class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize > object [typeName=com.ignite.example.model.Person] > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561) > at > org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown > Source) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219) > at > org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198) > at > org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261) > at > org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508) > at > org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111) > at > com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117) > at >
[jira] [Commented] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850689#comment-17850689 ] Mikhail Petrov commented on IGNITE-20688: - Merged to the master branch. [~alexpl] Thank you a lot for the review! > Java Thin Client - Error while deserializing Collection > --- > > Key: IGNITE-20688 > URL: https://issues.apache.org/jira/browse/IGNITE-20688 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15 >Reporter: Rahul Mohan >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Attachments: image001.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > I have encountered an issue in deserializing cache values which are of > Collection type. > The issue occurs if a field in different objects within the collection > points to the same reference. > *Versions:* > org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0 > > {code:java} > Person.java > public class Person implements Serializable { > private String id; > private String firstName; > private String lastName; > private double salary; > private String country; > private String deleted; > private Set accounts; > } > Client > ClientCacheConfiguration cacheCfg = new > ClientCacheConfiguration().setName(cacheName). > setCacheMode(CacheMode.REPLICATED). > > setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC); > > cache = client.getOrCreateCache(cacheCfg); > > Set set = new HashSet<>(); > set.add("1"); > > List persons = new ArrayList<>(); > persons.add(new Person("105286a4","Jack","Smith",1f, > "USA","false", set)); > persons.add(new Person("98545b0fd3af","John", "Doe", 50f, > "Australia","false", null)); > persons.add(new Person("98545b0fd3afd","Hari","M",40f, > "India", null, null)); > persons.add(new > Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set)); > cache.put("group1", value) // Write collection to cache > > List persons = (List) cache.get("group1"); // Get > from cache, Exception here {code} > > *Exception:* > {code:java} > class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize > object [typeName=com.ignite.example.model.Person] > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561) > at > org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown > Source) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219) > at > org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198) > at > org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261) > at > org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508) > at > org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111) > at > com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117) > at >
[jira] [Updated] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20688: Fix Version/s: 2.17 > Java Thin Client - Error while deserializing Collection > --- > > Key: IGNITE-20688 > URL: https://issues.apache.org/jira/browse/IGNITE-20688 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15 >Reporter: Rahul Mohan >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Attachments: image001.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > I have encountered an issue in deserializing cache values which are of > Collection type. > The issue occurs if a field in different objects within the collection > points to the same reference. > *Versions:* > org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0 > > {code:java} > Person.java > public class Person implements Serializable { > private String id; > private String firstName; > private String lastName; > private double salary; > private String country; > private String deleted; > private Set accounts; > } > Client > ClientCacheConfiguration cacheCfg = new > ClientCacheConfiguration().setName(cacheName). > setCacheMode(CacheMode.REPLICATED). > > setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC); > > cache = client.getOrCreateCache(cacheCfg); > > Set set = new HashSet<>(); > set.add("1"); > > List persons = new ArrayList<>(); > persons.add(new Person("105286a4","Jack","Smith",1f, > "USA","false", set)); > persons.add(new Person("98545b0fd3af","John", "Doe", 50f, > "Australia","false", null)); > persons.add(new Person("98545b0fd3afd","Hari","M",40f, > "India", null, null)); > persons.add(new > Person("985488b0fd3ae","Bugs","Bunny",30f,"Wabbit Land ", null, set)); > cache.put("group1", value) // Write collection to cache > > List persons = (List) cache.get("group1"); // Get > from cache, Exception here {code} > > *Exception:* > {code:java} > class org.apache.ignite.binary.BinaryObjectException: Failed to deserialize > object [typeName=com.ignite.example.model.Person] > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:927) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:316) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:557) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapCollection(ClientUtils.java:578) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:562) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:546) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:556) > at > org.apache.ignite.internal.client.thin.TcpClientCache.readObject(TcpClientCache.java:561) > at > org.apache.ignite.internal.client.thin.TcpClientCache$$Lambda$395/1950117092.apply(Unknown > Source) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:284) > at > org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:219) > at > org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198) > at > org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261) > at > org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508) > at > org.apache.ignite.internal.client.thin.TcpClientCache.get(TcpClientCache.java:111) > at > com.ignite.example.service.ApacheIgniteService.printAllKeys(ApacheIgniteService.java:117) > at > com.ignite.example.service.ApacheIgniteService.init(ApacheIgniteService.java:103) >
[jira] [Comment Edited] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850685#comment-17850685 ] Mikhail Petrov edited comment on IGNITE-20688 at 5/30/24 11:26 AM: --- Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to completely avoid unmarshalling value bytes serialized by the thin client during cache#put operations (marshalling cache value bytes stored in cache during thin client cache#get operations) on server nodes (see https://issues.apache.org/jira/browse/IGNITE-12625). Currently this approach is error prone and may cause more problems than it solves. Ignite intercepts values during cache operations processing - it can be JCache interceptors or different listeners/filters/policies. In this cases we are forced to unmarshal raw value bytes to Binary Object and we must avoid of detach operation as it can lead to the mentioned orphaned references problem. Keep in mind that if the cache value is a collection of objects, then after unmarshalling we will end up with a collection of binary objects, each containing a reference to a byte array that contains ALL the elements of the serialized collections and corresponding offset. If we will try to store these Binary Objects in cache or send them over the network, we may end up with sending/storing byte array containing ALL serialized collection elements for each collection's element. And this situation is difficult to detect because of mentioned interceptors. Here you should also consider that collections serialized on thin client may differ from the ones serialized on Ignite node. Because thin client serializes collection as single element and Ignite node serialize each element independently. As a result it is possible that in some cases keys that are stored using thin client will not be visible from the nodes and vice versa or we can face problems with CAS operations. 2. Resolving orphaned references during Binary Object detach procedure - we just replace orphaned reference with object and reassemble the binary object. This approach eliminates differences in collection serialization between Ignite node and Thin client. So mentioned problems with CAS or missing keys are no longer available. The goal is not to avoid the binary object detach process, but to make it work correctly. Also it is compatible with thin client of old versions. But detection of orphaned references is costly - we need to iterate over object binary representation. Not to mention reassembling the object if we need to replace the reference to the real object. --- The second approach was chosen. As a result we will get performance drop for cache operations that uses collections as value and are performed from java thin client. The degree of degradation depends on the structure of the collection's values and the length of the collection. You can consider it to be around 4-5% in case collection cross element references are not present. However, the performance degradation can be completely eliminated by wrapping the collection in an object and using it for cache operations. was (Author: petrovmikhail): Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches
[jira] [Comment Edited] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850685#comment-17850685 ] Mikhail Petrov edited comment on IGNITE-20688 at 5/30/24 11:21 AM: --- Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to completely avoid unmarshalling value bytes serialized by the thin client during cache#put operations (marshalling cache value bytes stored in cache during thin client cache#get operations) on server nodes (see https://issues.apache.org/jira/browse/IGNITE-12625). Currently this approach is error prone and may cause more problems than it solves. Ignite intercepts values during cache operations processing - it can be JCache interceptors or different listeners/filters/policies. In this cases we are forced to unmarshal raw value bytes to Binary Object and we must avoid of detach operation as it can lead to the mentioned orphaned references problem. Keep in mind that if the cache value is a collection of objects, then after unmarshalling we will end up with a collection of binary objects, each containing a reference to a byte array that contains ALL the elements of the serialized collections and corresponding offset. If we will try to store these Binary Objects in cache or send them over the network, we may end up with sending/storing byte array containing ALL serialized collection elements for each collection's element. And this situation is difficult to detect because of mentioned interceptors. Here you should also consider that collections serialized on thin client may differ from the ones serialized on Ignite node. Because thin client serializes collection as single element and Ignite node serialize each element independently. As a result it is possible that in some cases keys that are stored using thin client will not be visible from the nodes and vice versa or we can face problems with CAS operations. 2. Resolving orphaned references during Binary Object detach procedure - we just replace orphaned reference with object and reassemble the binary object. This approach eliminates differences in collection serialization between Ignite node and Thin client. So mentioned problems with CAS or missing keys are no longer available. The goal is not to avoid the binary object detach process, but to make it work correctly. Also it is compatible with thin client of old versions. But detection of orphaned references is costly - we need to iterate over object binary representation. Not to mention reassembling the object if we need to replace the reference to the real object. --- The second approach was chosen. As a result we will get performance drop for cache operations that uses collections as value and are performed from java thin client. The degree of degradation depends on the structure of the collection's values and the length of the collection. You can consider it to be around 4-5% in case collection cross element references are not present. However, the performance degradation can be completely eliminated by wrapping the collection in an object. was (Author: petrovmikhail): Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was
[jira] [Comment Edited] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850685#comment-17850685 ] Mikhail Petrov edited comment on IGNITE-20688 at 5/30/24 11:20 AM: --- Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to completely avoid unmarshalling value bytes serialized by the thin client during cache#put operations (marshalling cache value bytes stored in cache during thin client cache#get operations) on server nodes (see https://issues.apache.org/jira/browse/IGNITE-12625). Currently this approach is error prone and may cause more problems than it solves. Ignite intercepts values during cache operations processing - it can be JCache interceptors or different listeners/filters/policies. In this cases we are forced to unmarshal raw value bytes to Binary Object and we must avoid of detach operation as it can lead to the mentioned orphaned references problem. Keep in mind that if the cache value is a collection of objects, then after unmarshalling we will end up with a collection of binary objects, each containing a reference to a byte array that contains ALL the elements of the serialized collections and corresponding offset. If we will try to store these Binary Objects in cache or send them over the network, we may end up with sending/storing byte array containing ALL serialized collection elements for each collection's element. And this situation is difficult to detect because of mentioned interceptors. Here you should also consider that collections serialized on thin client may differ from the ones serialized on Ignite node. Because thin client serializes collection as single element and Ignite node serialize each element independently. As a result it is possible that in some cases keys that are stored using thin client will not be visible from the nodes and vice versa or we can face problems with CAS operations. 2. Resolving orphaned references during Binary Object detach procedure - we just replace orphaned reference with object and reassemble the binary object. This approach eliminates differences in collection serialization between Ignite node and Thin client. So mentioned problems with CAS or missing keys are no longer available. The goal is not to avoid the binary object detach process, but to make it work correctly. Also it is compatible with thin client of old versions. But detection of orphaned references is costly - we need to iterate over object binary representation. Not to mention reassembling the object if we need to replace the reference to the real object. --- The second approach was chosen. As a result we will get performance drop for cache operations that uses collections as value and are performed from java thin client. The degree of degradation depends on the structure of the collection's values and the length of the collection. You can consider it to be around 4-5% in case collection cross elemnt references are not present. However, the performance degradation can be completely eliminated by wrapping the collection in an object. was (Author: petrovmikhail): Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was
[jira] [Comment Edited] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850685#comment-17850685 ] Mikhail Petrov edited comment on IGNITE-20688 at 5/30/24 11:19 AM: --- Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to completely avoid unmarshalling value bytes serialized by the thin client during cache#put operations (marshalling cache value bytes stored in cache during thin client cache#get operations) on server nodes (see https://issues.apache.org/jira/browse/IGNITE-12625). Currently this approach is error prone and may cause more problems than it solves. Ignite intercepts values during cache operations processing - it can be JCache interceptors or different listeners/filters/policies. In this cases we are forced to unmarshal raw value bytes to Binary Object and we must avoid of detach operation as it can lead to the mentioned orphaned references problem. Keep in mind that if the cache value is a collection of objects, then after unmarshalling we will end up with a collection of binary objects, each containing a reference to a byte array that contains ALL the elements of the serialized collections and corresponding offset. If we will try to store these Binary Objects in cache or send them over the network, we may end up with sending/storing byte array containing ALL serialized collection elements for each collection's element. And this situation is difficult to detect because of mentioned interceptors. Here you should also consider that collections serialized on thin client may differ from the ones serialized on Ignite node. Because thin client serializes collection as single element and Ignite node serialize each element independently. As a result it is possible that in some cases keys that are stored using thin client will not be visible from the nodes and vice versa or we can face problems with CAS operations. 2. Resolving orphaned references during Binary Object detach procedure - we just replace orphaned reference with object and reassemble the binary object. This approach eliminates differences in collection serialization between Ignite node and Thin client. So mentioned problems with CAS or missing keys are no longer available. The goal is not to avoid the binary object detach process, but to make it work correctly. Also it is compatible with thin client of old versions. But detection of orphaned references is costly - we need to iterate over object binary representation. Not to mention reassembling the object if we need to replace the reference to the real object. The second approach was chosen. As a result we will get performance drop for cache operations that uses collections as value and are performed from java thin client. The degree of degradation depends on the structure of the collection's values and the length of the collection. You can consider it to be around 4-5% in case collection cross elemnt references are not present. However, the performance degradation can be completely eliminated by wrapping the collection in an object. was (Author: petrovmikhail): Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to
[jira] [Commented] (IGNITE-20688) Java Thin Client - Error while deserializing Collection
[ https://issues.apache.org/jira/browse/IGNITE-20688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850685#comment-17850685 ] Mikhail Petrov commented on IGNITE-20688: - Root cause of the issue: Ignite does not consider references (handles) during the Binary Object detachment process. As a result, after detaching a binary object, it may contain references to the part of the binary array that was cut off during the detaching procedure. This issue primarily affects Java thin client and cache operations that use collections (maps/arrays/lists, etc.) as the value. Java thin client serializes collection as a single object and reuses references across all collections elements. When a cache request with a serialized collection is received by the Ignite server node, it is unmarshalled to a collection of binary objects, each containing its own chunk of of the serialized value bytes after "detach" procedure. This is where the problem with orphaned references can arises. The following approaches for solving this issue was considered: 1. The most preferred way is to completely avoid unmarshalling value bytes serialized by the thin client during cache#put operations (marshalling cache value bytes stored in cache during thin client cache#get operations) on server nodes (see https://issues.apache.org/jira/browse/IGNITE-12625). Currently this approach is error prone and may cause more problems than it solves. Ignite intercepts values during cache operations processing - it can be JCache interceptors or different listeners/filters/policies. In this cases we are forced to unmarshal raw value bytes to Binary Object and we must avoid of detach operation as it can lead to the mentioned orphaned references problem. Keep in mind that if the cache value is a collection of objects, then after unmarshalling we will end up with a collection of binary objects, each containing a reference to a byte array that contains ALL the elements of the serialized collections and corresponding offset. If we will try to store these Binary Objects in cache or send them over the network, we may end up with sending/storing byte array containing ALL serialized collection elements for each collection's element. And this situation is difficult to detect because of mentioned interceptors. Here you should also consider that collections serialized on thin client may differ from the ones serialized on Ignite node. Because thin client serializes collection as single element and Ignite node serialize each element independently. As a result it is possible that in some cases keys that are stored using thin client will not be visible from the nodes and vice versa or we can face problems with CAS operations. 2. Resolving orphaned references during Binary Object detach procedure - we just replace orphaned reference with object and reassemble the binary object. This approach eliminates differences in collection serialization between Ignite node and Thin client. So mentioned problems with CAS or missing keys are no longer available. The goal is not to avoid the binary object detach process, but to make it work correctly. Also it is compatible with thin client of old versions. But detection of orphaned references is costly - we need to iterate over object binary representation. Not to mention reassembling the object if we need to replace the reference to the real object. The second approach was chosen. As a result we will get performance drop for cache operations that uses collections as value and are performed from java thin client. The degree of degradation depends on the structure of the collection's values and the length of the collection. You can consider it to be around 4-5% in case cross object references are not found. Still it can be completely eliminated by wrapping collection to object. > Java Thin Client - Error while deserializing Collection > --- > > Key: IGNITE-20688 > URL: https://issues.apache.org/jira/browse/IGNITE-20688 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Affects Versions: 2.9, 2.10, 2.12, 2.13, 2.14, 2.15 >Reporter: Rahul Mohan >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Attachments: image001.png > > Time Spent: 1h 20m > Remaining Estimate: 0h > > I have encountered an issue in deserializing cache values which are of > Collection type. > The issue occurs if a field in different objects within the collection > points to the same reference. > *Versions:* > org.apache.ignite:ignite-core:2.9.0 to org.apache.ignite:ignite-core:2.15.0 > > {code:java} > Person.java > public class Person implements Serializable { > private String id; > private String firstName; >
[jira] [Commented] (IGNITE-21830) Add logging of connection check for each address
[ https://issues.apache.org/jira/browse/IGNITE-21830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848084#comment-17848084 ] Mikhail Petrov commented on IGNITE-21830: - [~mmdavydov] Thank you for the contribution. Merged to the master branch. > Add logging of connection check for each address > > > Key: IGNITE-21830 > URL: https://issues.apache.org/jira/browse/IGNITE-21830 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Shishkov >Assignee: Maksim Davydov >Priority: Trivial > Labels: ise, newbie > Fix For: 2.17 > > Time Spent: 13.5h > Remaining Estimate: 0h > > Currently, exception thrown during checking of address is ignored [1]. It > would be useful to print message with connection check summary including each > address checking state and error message (if any). > # > https://github.com/apache/ignite/blob/7cd0c7a7d1150bbf6be6aae5efe80627a73757c0/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L7293 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21830) Add logging of connection check for each address
[ https://issues.apache.org/jira/browse/IGNITE-21830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21830: Fix Version/s: 2.17 > Add logging of connection check for each address > > > Key: IGNITE-21830 > URL: https://issues.apache.org/jira/browse/IGNITE-21830 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Shishkov >Assignee: Maksim Davydov >Priority: Trivial > Labels: ise, newbie > Fix For: 2.17 > > Time Spent: 13.5h > Remaining Estimate: 0h > > Currently, exception thrown during checking of address is ignored [1]. It > would be useful to print message with connection check summary including each > address checking state and error message (if any). > # > https://github.com/apache/ignite/blob/7cd0c7a7d1150bbf6be6aae5efe80627a73757c0/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L7293 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22203) Refactor CommandHandler, remove unnecessary code
[ https://issues.apache.org/jira/browse/IGNITE-22203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-22203: Labels: ise (was: ) > Refactor CommandHandler, remove unnecessary code > > > Key: IGNITE-22203 > URL: https://issues.apache.org/jira/browse/IGNITE-22203 > Project: Ignite > Issue Type: Task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[ https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12625: --- Assignee: (was: Mikhail Petrov) > Thin client: Marshaling/unmarshaling of objects performed twice > --- > > Key: IGNITE-12625 > URL: https://issues.apache.org/jira/browse/IGNITE-12625 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Reporter: Aleksey Plekhanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For each thin client cache operation marshaling/unmarshaling of objects > performed twice. For example, cache "put" operation marshal object on the > client-side, then unmarshal object (with keep binaries) on the server-side > and marshal it again before putting it to the cache. It causes some > undesirable effects. For example, references to the same binary object in a > collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized > as different objects. > Reproducer: > {code:java} > try (IgniteClient client = startClient()) { > ClientCache cache = > client.getOrCreateCache(DEFAULT_CACHE_NAME); > Person person = new Person(0, "name"); > cache.put(0, new Object[] {person, person} ); > Object[] res = cache.get(0); > assertTrue(res[0] == res[1]); > }{code} > Also, we need to unwrap binaries recursively since all objects inside > collections, arrays and maps become binary objects after > marshaling/unmarshalling (see IGNITE-12468) > Also, we don't know do we really need to deserialize binary objects. If > object was originally binary there is no evidence of this after > marshaling/unmarshaling on server-side. This leads to problems when a binary > object was created for unknown class. > Reproducer: > {code:java} > cache.put(0, client.binary().builder("TestType").setField("test", > "val").build()); > cache.get(0);{code} > Will throw exception: > {noformat} > class org.apache.ignite.binary.BinaryInvalidTypeException: TestType > at > org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat} > To avoid double marshaling we could pass byte array from request content to > cache directly (for example using {{CacheObject}}), but we don't have object > size in thin client protocol, so in any case, we need to traverse the > objects. Also, we don't have the ability to get {{CacheObject}} from the > cache now, so such an approach will only work in one way, for "put" > operations, but not for "get" operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[ https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12625: --- Assignee: Mikhail Petrov > Thin client: Marshaling/unmarshaling of objects performed twice > --- > > Key: IGNITE-12625 > URL: https://issues.apache.org/jira/browse/IGNITE-12625 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Reporter: Aleksey Plekhanov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For each thin client cache operation marshaling/unmarshaling of objects > performed twice. For example, cache "put" operation marshal object on the > client-side, then unmarshal object (with keep binaries) on the server-side > and marshal it again before putting it to the cache. It causes some > undesirable effects. For example, references to the same binary object in a > collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized > as different objects. > Reproducer: > {code:java} > try (IgniteClient client = startClient()) { > ClientCache cache = > client.getOrCreateCache(DEFAULT_CACHE_NAME); > Person person = new Person(0, "name"); > cache.put(0, new Object[] {person, person} ); > Object[] res = cache.get(0); > assertTrue(res[0] == res[1]); > }{code} > Also, we need to unwrap binaries recursively since all objects inside > collections, arrays and maps become binary objects after > marshaling/unmarshalling (see IGNITE-12468) > Also, we don't know do we really need to deserialize binary objects. If > object was originally binary there is no evidence of this after > marshaling/unmarshaling on server-side. This leads to problems when a binary > object was created for unknown class. > Reproducer: > {code:java} > cache.put(0, client.binary().builder("TestType").setField("test", > "val").build()); > cache.get(0);{code} > Will throw exception: > {noformat} > class org.apache.ignite.binary.BinaryInvalidTypeException: TestType > at > org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat} > To avoid double marshaling we could pass byte array from request content to > cache directly (for example using {{CacheObject}}), but we don't have object > size in thin client protocol, so in any case, we need to traverse the > objects. Also, we don't have the ability to get {{CacheObject}} from the > cache now, so such an approach will only work in one way, for "put" > operations, but not for "get" operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[ https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12625: --- Assignee: (was: Mikhail Petrov) > Thin client: Marshaling/unmarshaling of objects performed twice > --- > > Key: IGNITE-12625 > URL: https://issues.apache.org/jira/browse/IGNITE-12625 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Reporter: Aleksey Plekhanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For each thin client cache operation marshaling/unmarshaling of objects > performed twice. For example, cache "put" operation marshal object on the > client-side, then unmarshal object (with keep binaries) on the server-side > and marshal it again before putting it to the cache. It causes some > undesirable effects. For example, references to the same binary object in a > collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized > as different objects. > Reproducer: > {code:java} > try (IgniteClient client = startClient()) { > ClientCache cache = > client.getOrCreateCache(DEFAULT_CACHE_NAME); > Person person = new Person(0, "name"); > cache.put(0, new Object[] {person, person} ); > Object[] res = cache.get(0); > assertTrue(res[0] == res[1]); > }{code} > Also, we need to unwrap binaries recursively since all objects inside > collections, arrays and maps become binary objects after > marshaling/unmarshalling (see IGNITE-12468) > Also, we don't know do we really need to deserialize binary objects. If > object was originally binary there is no evidence of this after > marshaling/unmarshaling on server-side. This leads to problems when a binary > object was created for unknown class. > Reproducer: > {code:java} > cache.put(0, client.binary().builder("TestType").setField("test", > "val").build()); > cache.get(0);{code} > Will throw exception: > {noformat} > class org.apache.ignite.binary.BinaryInvalidTypeException: TestType > at > org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat} > To avoid double marshaling we could pass byte array from request content to > cache directly (for example using {{CacheObject}}), but we don't have object > size in thin client protocol, so in any case, we need to traverse the > objects. Also, we don't have the ability to get {{CacheObject}} from the > cache now, so such an approach will only work in one way, for "put" > operations, but not for "get" operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21586: Fix Version/s: 2.17 > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21586. - Resolution: Fixed > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820348#comment-17820348 ] Mikhail Petrov commented on IGNITE-21586: - [~NSAmelchev] Thank you for the review. > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819545#comment-17819545 ] Mikhail Petrov commented on IGNITE-21266: - [~alex_pl] Thank you for the review. > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > ClientCacheAffinityContext is susceptible to the similar problem that > described in > [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a > result cache affinity data required for PA work is not updated after cluster > restart. > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Fix Version/s: 2.17 > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > ClientCacheAffinityContext is susceptible to the similar problem that > described in > [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a > result cache affinity data required for PA work is not updated after cluster > restart. > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21586: --- Assignee: Mikhail Petrov > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21586) Removed orphaned rawRetval flag.
[ https://issues.apache.org/jira/browse/IGNITE-21586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21586: Ignite Flags: (was: Docs Required,Release Notes Required) > Removed orphaned rawRetval flag. > > > Key: IGNITE-21586 > URL: https://issues.apache.org/jira/browse/IGNITE-21586 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21586) Removed orphaned rawRetval flag.
Mikhail Petrov created IGNITE-21586: --- Summary: Removed orphaned rawRetval flag. Key: IGNITE-21586 URL: https://issues.apache.org/jira/browse/IGNITE-21586 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[ https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812785#comment-17812785 ] Mikhail Petrov commented on IGNITE-21399: - [~NSAmelchev] Thank you for the review. > IgniteCache#getAll invoked on transactional cache can lead to a node failure > with OutOfMemoryError > -- > > Key: IGNITE-21399 > URL: https://issues.apache.org/jira/browse/IGNITE-21399 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Exception: > {code:java} > 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.OutOfMemoryError]] > java.lang.OutOfMemoryError: null > at > java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) > ~[?:?] > at > java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) > ~[?:?] > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) > ~[?:?] > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) > ~[?:?] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) > ~[ignite-core-14.1.2.jar:14.1.2] > at >
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[ https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21399: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > IgniteCache#getAll invoked on transactional cache can lead to a node failure > with OutOfMemoryError > -- > > Key: IGNITE-21399 > URL: https://issues.apache.org/jira/browse/IGNITE-21399 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Exception: > {code:java} > 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.OutOfMemoryError]] > java.lang.OutOfMemoryError: null > at > java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) > ~[?:?] > at > java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) > ~[?:?] > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) > ~[?:?] > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) > ~[?:?] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) > ~[ignite-core-14.1.2.jar:14.1.2] > at >
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[ https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21399: Labels: ise (was: ) > IgniteCache#getAll invoked on transactional cache can lead to a node failure > with OutOfMemoryError > -- > > Key: IGNITE-21399 > URL: https://issues.apache.org/jira/browse/IGNITE-21399 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Exception: > {code:java} > 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.OutOfMemoryError]] > java.lang.OutOfMemoryError: null > at > java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) > ~[?:?] > at > java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) > ~[?:?] > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) > ~[?:?] > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) > ~[?:?] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > ~[ignite-core-14.1.2.jar:14.1.2] > at >
[jira] [Updated] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[ https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21399: Fix Version/s: 2.17 > IgniteCache#getAll invoked on transactional cache can lead to a node failure > with OutOfMemoryError > -- > > Key: IGNITE-21399 > URL: https://issues.apache.org/jira/browse/IGNITE-21399 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Exception: > {code:java} > 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.OutOfMemoryError]] > java.lang.OutOfMemoryError: null > at > java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) > ~[?:?] > at > java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) > ~[?:?] > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) > ~[?:?] > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) > ~[?:?] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > ~[ignite-core-14.1.2.jar:14.1.2] > at >
[jira] [Assigned] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
[ https://issues.apache.org/jira/browse/IGNITE-21399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21399: --- Assignee: Mikhail Petrov > IgniteCache#getAll invoked on transactional cache can lead to a node failure > with OutOfMemoryError > -- > > Key: IGNITE-21399 > URL: https://issues.apache.org/jira/browse/IGNITE-21399 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Exception: > {code:java} > 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. > Will be handled accordingly to configured handler > [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=CRITICAL_ERROR, > err=java.lang.OutOfMemoryError]] > java.lang.OutOfMemoryError: null > at > java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) > ~[?:?] > at > java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) > ~[?:?] > at > java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) > ~[?:?] > at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) > ~[?:?] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at > org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) > ~[ignite-core-14.1.2.jar:14.1.2] > at java.lang.String.valueOf(String.java:2951) ~[?:?] > at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) > ~[ignite-core-14.1.2.jar:14.1.2] > at > org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) > ~[ignite-core-14.1.2.jar:14.1.2] > at >
[jira] [Created] (IGNITE-21399) IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError
Mikhail Petrov created IGNITE-21399: --- Summary: IgniteCache#getAll invoked on transactional cache can lead to a node failure with OutOfMemoryError Key: IGNITE-21399 URL: https://issues.apache.org/jira/browse/IGNITE-21399 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Exception: {code:java} 2024-01-18 09:28:07.374 [ERROR][sys-#4371][] Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.OutOfMemoryError]] java.lang.OutOfMemoryError: null at java.lang.AbstractStringBuilder.hugeCapacity(AbstractStringBuilder.java:214) ~[?:?] at java.lang.AbstractStringBuilder.newCapacity(AbstractStringBuilder.java:206) ~[?:?] at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:173) ~[?:?] at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:538) ~[?:?] at java.lang.StringBuilder.append(StringBuilder.java:178) ~[?:?] at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] at java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1329) ~[?:?] at java.lang.String.valueOf(String.java:2951) ~[?:?] at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] at org.apache.ignite.internal.processors.cache.GridCacheUtils$18.toString(GridCacheUtils.java:646) ~[ignite-core-14.1.2.jar:14.1.2] at java.lang.String.valueOf(String.java:2951) ~[?:?] at org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:102) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:100) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:910) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1121) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1055) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:622) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:561) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.future.GridCompoundFuture.toString(GridCompoundFuture.java:421) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.future.GridCompoundIdentityFuture.toString(GridCompoundIdentityFuture.java:47) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.processors.cache.distributed.dht.CacheDistributedGetFutureAdapter.toString(CacheDistributedGetFutureAdapter.java:377) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.toString(GridPartitionedGetFuture.java:664) ~[ignite-core-14.1.2.jar:14.1.2] at java.lang.String.valueOf(String.java:2951) ~[?:?] at java.lang.StringBuilder.append(StringBuilder.java:172) ~[?:?] at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2290) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations(GridCachePartitionExchangeManager.java:2439) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.lambda$null$0(IgniteTxManager.java:398) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7437) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827) ~[ignite-core-14.1.2.jar:14.1.2] at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) ~[ignite-core-14.1.2.jar:14.1.2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?] at java.lang.Thread.run(Thread.java:829) ~[?:?] 2024-01-18 09:28:07.411 [WARN ][sys-#4371][org.apache.ignite.internal.processors.cache.CacheDiagnosticManager] Page locks dump: {code} Java version: OpenJDK
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Description: After GridLocalAtomicCache removal in [IGNITE-15759|https://issues.apache.org/jira/browse/IGNITE-15759] some code in GridCacheAdapter #getAllAsync methods is orphaned and should be removed as well. > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > After GridLocalAtomicCache removal in > [IGNITE-15759|https://issues.apache.org/jira/browse/IGNITE-15759] some code > in GridCacheAdapter #getAllAsync methods is orphaned and should be removed as > well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810224#comment-17810224 ] Mikhail Petrov commented on IGNITE-21308: - [~av] Thank you for the review. > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Description: ClientCacheAffinityContext is susceptible to the similar problem that described in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a result cache affinity data required for PA work is not updated after cluster restart. Reproducer: {code:java} /** */ public class PartitionAwarenessClusterRestartTest extends ThinClientAbstractPartitionAwarenessTest { /** */ @Test public void testGroupNodesAfterClusterRestart() throws Exception { prepareCluster(); initClient(getClientConfiguration(0), 0, 1); checkPartitionAwareness(); stopAllGrids(); prepareCluster(); checkPartitionAwareness(); } /** */ private void checkPartitionAwareness() throws Exception { ClientCache cache = client.cache(DEFAULT_CACHE_NAME); cache.put(0, 0); opsQueue.clear(); for (int i = 1; i < 1000; i++) { cache.put(i, i); assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), ClientOperation.CACHE_PUT); } } /** */ private void prepareCluster() throws Exception { startGrids(3); grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); } } {code} was: ClientCacheAffinityContext is susceptible to the similar problem ерфе described in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. Reproducer: {code:java} /** */ public class PartitionAwarenessClusterRestartTest extends ThinClientAbstractPartitionAwarenessTest { /** */ @Test public void testGroupNodesAfterClusterRestart() throws Exception { prepareCluster(); initClient(getClientConfiguration(0), 0, 1); checkPartitionAwareness(); stopAllGrids(); prepareCluster(); checkPartitionAwareness(); } /** */ private void checkPartitionAwareness() throws Exception { ClientCache cache = client.cache(DEFAULT_CACHE_NAME); cache.put(0, 0); opsQueue.clear(); for (int i = 1; i < 1000; i++) { cache.put(i, i); assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), ClientOperation.CACHE_PUT); } } /** */ private void prepareCluster() throws Exception { startGrids(3); grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); } } {code} > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > ClientCacheAffinityContext is susceptible to the similar problem that > described in > [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. As a > result cache affinity data required for PA work is not updated after cluster > restart. > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21266: --- Assignee: Mikhail Petrov > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > ClientCacheAffinityContext is susceptible to the similar problem ерфе > described in > [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Description: ClientCacheAffinityContext is susceptible to the similar problem ерфе described in [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. Reproducer: {code:java} /** */ public class PartitionAwarenessClusterRestartTest extends ThinClientAbstractPartitionAwarenessTest { /** */ @Test public void testGroupNodesAfterClusterRestart() throws Exception { prepareCluster(); initClient(getClientConfiguration(0), 0, 1); checkPartitionAwareness(); stopAllGrids(); prepareCluster(); checkPartitionAwareness(); } /** */ private void checkPartitionAwareness() throws Exception { ClientCache cache = client.cache(DEFAULT_CACHE_NAME); cache.put(0, 0); opsQueue.clear(); for (int i = 1; i < 1000; i++) { cache.put(i, i); assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), ClientOperation.CACHE_PUT); } } /** */ private void prepareCluster() throws Exception { startGrids(3); grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); } } {code} was: Reproducer: {code:java} /** */ public class PartitionAwarenessClusterRestartTest extends ThinClientAbstractPartitionAwarenessTest { /** */ @Test public void testGroupNodesAfterClusterRestart() throws Exception { prepareCluster(); initClient(getClientConfiguration(0), 0, 1); checkPartitionAwareness(); stopAllGrids(); prepareCluster(); checkPartitionAwareness(); } /** */ private void checkPartitionAwareness() throws Exception { ClientCache cache = client.cache(DEFAULT_CACHE_NAME); cache.put(0, 0); opsQueue.clear(); for (int i = 1; i < 1000; i++) { cache.put(i, i); assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), ClientOperation.CACHE_PUT); } } /** */ private void prepareCluster() throws Exception { startGrids(3); grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); } } {code} > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > ClientCacheAffinityContext is susceptible to the similar problem ерфе > described in > [IGNITE-21001|https://issues.apache.org/jira/browse/IGNITE-21001]. > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Ignite Flags: (was: Docs Required,Release Notes Required) > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Labels: ise (was: ) > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21308: Fix Version/s: 2.17 > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21308) Remove orphaned GridCacheAdapter code
[ https://issues.apache.org/jira/browse/IGNITE-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21308: --- Assignee: Mikhail Petrov > Remove orphaned GridCacheAdapter code > -- > > Key: IGNITE-21308 > URL: https://issues.apache.org/jira/browse/IGNITE-21308 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15478) Add access to the IgniteMBeanManager via KernalContext
[ https://issues.apache.org/jira/browse/IGNITE-15478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-15478: --- Assignee: (was: Mikhail Petrov) > Add access to the IgniteMBeanManager via KernalContext > -- > > Key: IGNITE-15478 > URL: https://issues.apache.org/jira/browse/IGNITE-15478 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > It is needed to add an access to the IgniteMBeanManager via KernalContext. It > helps to access the IgniteMBeanManager in the same way as for other Ignite > components, and allows Ignite components to register needed MBeans from their > own implementations. > It's also proposed to refactor MBeans registration to be performed explicitly > via IgniteMBeanManager. As an example we can eliminate > GridQueryIndexing#registerMxBeans method and registers beans directly. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Labels: ise (was: ) > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808644#comment-17808644 ] Mikhail Petrov commented on IGNITE-21240: - [~av] Thank you for the review. > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21308) Remove orphaned GridCacheAdapter code
Mikhail Petrov created IGNITE-21308: --- Summary: Remove orphaned GridCacheAdapter code Key: IGNITE-21308 URL: https://issues.apache.org/jira/browse/IGNITE-21308 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17808166#comment-17808166 ] Mikhail Petrov commented on IGNITE-21001: - [~alex_pl] Thank you for the review. > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Time Spent: 1h > Remaining Estimate: 0h > > When a client requests information about cluster nodes, it sends the version > of the topology for which it received a list of cluster nodes the previous > time. > And if the client's version of the topology matches the one currently on the > server, then the server does not send the list of cluster nodes back to the > client. Like the client knows everything itself. > But after full cluster restart, the topology version may not change. But the > nodes will be different. > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Summary: [Java Thin Client] Partition Awareness does not work after cluster restart (was: [Java Thin Client] PA do not work after cluster restart) > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21266) [Java Thin Client] Partition Awareness does not work after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21266: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > [Java Thin Client] Partition Awareness does not work after cluster restart > -- > > Key: IGNITE-21266 > URL: https://issues.apache.org/jira/browse/IGNITE-21266 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > > Reproducer: > {code:java} > /** */ > public class PartitionAwarenessClusterRestartTest extends > ThinClientAbstractPartitionAwarenessTest { > /** */ > @Test > public void testGroupNodesAfterClusterRestart() throws Exception { > prepareCluster(); > initClient(getClientConfiguration(0), 0, 1); > checkPartitionAwareness(); > stopAllGrids(); > prepareCluster(); > checkPartitionAwareness(); > } > /** */ > private void checkPartitionAwareness() throws Exception { > ClientCache cache = client.cache(DEFAULT_CACHE_NAME); > cache.put(0, 0); > opsQueue.clear(); > for (int i = 1; i < 1000; i++) { > cache.put(i, i); > > assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), > ClientOperation.CACHE_PUT); > } > } > /** */ > private void prepareCluster() throws Exception { > startGrids(3); > grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21266) [Java Thin Client] PA do not work after cluster restart
Mikhail Petrov created IGNITE-21266: --- Summary: [Java Thin Client] PA do not work after cluster restart Key: IGNITE-21266 URL: https://issues.apache.org/jira/browse/IGNITE-21266 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Reproducer: {code:java} /** */ public class PartitionAwarenessClusterRestartTest extends ThinClientAbstractPartitionAwarenessTest { /** */ @Test public void testGroupNodesAfterClusterRestart() throws Exception { prepareCluster(); initClient(getClientConfiguration(0), 0, 1); checkPartitionAwareness(); stopAllGrids(); prepareCluster(); checkPartitionAwareness(); } /** */ private void checkPartitionAwareness() throws Exception { ClientCache cache = client.cache(DEFAULT_CACHE_NAME); cache.put(0, 0); opsQueue.clear(); for (int i = 1; i < 1000; i++) { cache.put(i, i); assertOpOnChannel(nodeChannel(grid(0).affinity(DEFAULT_CACHE_NAME).mapKeyToNode(i).id()), ClientOperation.CACHE_PUT); } } /** */ private void prepareCluster() throws Exception { startGrids(3); grid(0).createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)); } } {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Fix Version/s: 2.17 > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Issue Type: Task (was: Bug) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Description: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. They currently are used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and support both authorization approaches for the JOIN_AS_SERVER permission (the only permission that is checked through SecurityContext authorization API). was: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. They currently are used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and migrate completely to the first. > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and support both > authorization approaches for the JOIN_AS_SERVER permission (the only > permission that is checked through SecurityContext authorization API). > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Priority: Minor (was: Major) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Description: We need to finally remove what was described ad deprecated in https://issues.apache.org/jira/browse/IGNITE-19807 (was: We need to finally remove what was described ad deprecated in ) > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in > https://issues.apache.org/jira/browse/IGNITE-19807 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21240: Description: We need to finally remove what was described ad deprecated in > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We need to finally remove what was described ad deprecated in -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21240) Remove deprecated authorization method from Security Context
[ https://issues.apache.org/jira/browse/IGNITE-21240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21240: --- Assignee: Mikhail Petrov > Remove deprecated authorization method from Security Context > > > Key: IGNITE-21240 > URL: https://issues.apache.org/jira/browse/IGNITE-21240 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21240) Remove deprecated authorization method from Security Context
Mikhail Petrov created IGNITE-21240: --- Summary: Remove deprecated authorization method from Security Context Key: IGNITE-21240 URL: https://issues.apache.org/jira/browse/IGNITE-21240 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21001: Description: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything itself. But after full cluster restart, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} was: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything itself. But after cluster restart, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > When a client requests information about cluster nodes, it sends the version > of the topology for which it received a list of cluster nodes the previous > time. > And if the client's version of the topology matches the one currently on the > server, then the server does not send the list of cluster nodes back to the > client. Like the client knows everything itself. > But after full cluster restart, the topology version may not change. But the > nodes will be different. > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21001: Description: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything itself. But after cluster restart, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} was: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything itself. But after restarting the cluster, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > When a client requests information about cluster nodes, it sends the version > of the topology for which it received a list of cluster nodes the previous > time. > And if the client's version of the topology matches the one currently on the > server, then the server does not send the list of cluster nodes back to the > client. Like the client knows everything itself. > But after cluster restart, the topology version may not change. But the nodes > will be different. > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21001: Description: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything itself. But after restarting the cluster, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} was: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything himself. But after restarting the cluster, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > When a client requests information about cluster nodes, it sends the version > of the topology for which it received a list of cluster nodes the previous > time. > And if the client's version of the topology matches the one currently on the > server, then the server does not send the list of cluster nodes back to the > client. Like the client knows everything itself. > But after restarting the cluster, the topology version may not change. But > the nodes will be different. > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21001: Description: When a client requests information about cluster nodes, it sends the version of the topology for which it received a list of cluster nodes the previous time. And if the client's version of the topology matches the one currently on the server, then the server does not send the list of cluster nodes back to the client. Like the client knows everything himself. But after restarting the cluster, the topology version may not change. But the nodes will be different. The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} was: The reproducer: {noformat} @Test public void testClusterGroup() throws Exception { IgniteEx srv = startGrid(0); try (IgniteClient client = startClient(0)) { assertTrue(client.cluster().nodes().contains(srv.localNode())); stopAllGrids(); srv = startGrid(0); assertTrue(client.cluster().nodes().contains(srv.localNode())); } } {noformat} > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > When a client requests information about cluster nodes, it sends the version > of the topology for which it received a list of cluster nodes the previous > time. > And if the client's version of the topology matches the one currently on the > server, then the server does not send the list of cluster nodes back to the > client. Like the client knows everything himself. > But after restarting the cluster, the topology version may not change. But > the nodes will be different. > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21001: --- Assignee: Mikhail Petrov (was: Nikita Amelchev) > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21001) Thin client: cluster group returns cached nodes after cluster restart
[ https://issues.apache.org/jira/browse/IGNITE-21001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21001: Fix Version/s: 2.17 > Thin client: cluster group returns cached nodes after cluster restart > - > > Key: IGNITE-21001 > URL: https://issues.apache.org/jira/browse/IGNITE-21001 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Mikhail Petrov >Priority: Critical > Labels: ise > Fix For: 2.17 > > > The reproducer: > {noformat} > @Test > public void testClusterGroup() throws Exception { > IgniteEx srv = startGrid(0); > try (IgniteClient client = startClient(0)) { > assertTrue(client.cluster().nodes().contains(srv.localNode())); > stopAllGrids(); > srv = startGrid(0); > assertTrue(client.cluster().nodes().contains(srv.localNode())); > } > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Description: Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. It is proposed to not consider classes that are not in org.apache.ignite package as system. was:Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. > It is proposed to not consider classes that are not in org.apache.ignite > package as system. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Fix Version/s: 2.17 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Affects Version/s: 2.16 2.15 > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.15, 2.16 >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Component/s: security > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21216: Ignite Flags: (was: Docs Required,Release Notes Required) > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21216. - Resolution: Fixed > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805070#comment-17805070 ] Mikhail Petrov commented on IGNITE-21216: - [~NSAmelchev] Thank you for the review. > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21216: --- Assignee: Mikhail Petrov > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
Mikhail Petrov created IGNITE-21216: --- Summary: Do not consider tasks that are not in org.apache.ignite package as system Key: IGNITE-21216 URL: https://issues.apache.org/jira/browse/IGNITE-21216 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20922) Java Thin: direct service invocation with ClientClusterGroup and Service Awareness
[ https://issues.apache.org/jira/browse/IGNITE-20922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798531#comment-17798531 ] Mikhail Petrov commented on IGNITE-20922: - [~vladsz83] Thank you for the contribution. > Java Thin: direct service invocation with ClientClusterGroup and Service > Awareness > -- > > Key: IGNITE-20922 > URL: https://issues.apache.org/jira/browse/IGNITE-20922 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Once we implemented Service Awareness for Java Thin Client, we might improve > the service invocation with `IgniteClient.services(ClientClusterGroup grp)` > Consider: > 1) There is a cluster with some nodes A, B, C, D, F > 1) A service is deployed on nodes A,B,C > 2) Service Awareness is enabled. > 3) User limits the service instance nodes set with > `IgniteClient.services('node A', 'node B')` skipping node C. > 4) The thin client requests the service randomly on node C because it has the > service instance too. > 5) Node C redirects the invocation to node A or to node B as user required. > We should prevent the redirection call at #5 and call service only on A or B. > And this would help user to choose nodes for loading purposes. > It looks simple to intersect passed `ClientClusterGroup` and known set of > service instance nodes before the service calling. I.e. the client can > exclude node C from the options where to send the invocation request. > If user chosses `services('node A', 'node B', 'node F')`, where F has no > service instance, we do not invoke F. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the result is already saved in the buffer > mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the serialization result is already saved in > the buffer mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Description: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see a) pyignite.datatypes.complex.BinaryObject.hashcode b) pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the serialization result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) was: Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see pyignite.datatypes.complex.BinaryObject.hashcode, pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > a) pyignite.datatypes.complex.BinaryObject.hashcode > b) pyignite/binary.py#write_footer:203 > ). > The hash code of a key object is used to determine which node this key > belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the serialization result is already saved in > the buffer mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21100) [Python Thin Client] Key class binary metadata registration is skipped
[ https://issues.apache.org/jira/browse/IGNITE-21100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21100: Summary: [Python Thin Client] Key class binary metadata registration is skipped (was: [Python Thin Client] Key class binary metadata is not registered) > [Python Thin Client] Key class binary metadata registration is skipped > -- > > Key: IGNITE-21100 > URL: https://issues.apache.org/jira/browse/IGNITE-21100 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > > Python thin client does not register binary metadata for user classes that > are used as a key for cache operations. > It seems that it happens because > 1. When we calculate hash code of a key object, we serialize it. The result > is cached in `_buffer` attribute of the object. (see > pyignite.datatypes.complex.BinaryObject.hashcode, > pyignite/binary.py#write_footer:203 ). The hash code of a key object is used > to determine which node this key belongs to (PA). > 2. But when we are about to send key object to the server side - we skip > cache object serialization as the result is already saved in the buffer > mentioned above AND skip its binary type registration. > (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21100) [Python Thin Client] Key class binary metadata is not registered
Mikhail Petrov created IGNITE-21100: --- Summary: [Python Thin Client] Key class binary metadata is not registered Key: IGNITE-21100 URL: https://issues.apache.org/jira/browse/IGNITE-21100 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov Python thin client does not register binary metadata for user classes that are used as a key for cache operations. It seems that it happens because 1. When we calculate hash code of a key object, we serialize it. The result is cached in `_buffer` attribute of the object. (see pyignite.datatypes.complex.BinaryObject.hashcode, pyignite/binary.py#write_footer:203 ). The hash code of a key object is used to determine which node this key belongs to (PA). 2. But when we are about to send key object to the server side - we skip cache object serialization as the result is already saved in the buffer mentioned above AND skip its binary type registration. (see pyignite.datatypes.complex.BinaryObject.from_python_not_null) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21026) [Extensions] Fixed NPE in the performance statistics extension if there are no jobs for a task
[ https://issues.apache.org/jira/browse/IGNITE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21026: Labels: ise (was: ) > [Extensions] Fixed NPE in the performance statistics extension if there are > no jobs for a task > -- > > Key: IGNITE-21026 > URL: https://issues.apache.org/jira/browse/IGNITE-21026 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > > {noformat} > Exception in thread "main" java.lang.NullPointerException > at > org.apache.ignite.internal.performancestatistics.handlers.ComputeHandler.lambda$results$5(ComputeHandler.java:137) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at > org.apache.ignite.internal.performancestatistics.handlers.ComputeHandler.results(ComputeHandler.java:130) > at > org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:129) > at > org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69) > {noformat} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21029) Update Ignite dependency log4j2
[ https://issues.apache.org/jira/browse/IGNITE-21029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21029: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency log4j2 > --- > > Key: IGNITE-21029 > URL: https://issues.apache.org/jira/browse/IGNITE-21029 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency log4j2 2.20.0 to 2.22.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21029) Update Ignite dependency log4j2
[ https://issues.apache.org/jira/browse/IGNITE-21029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21029: Docs Text: Updated log4j2 dependency to 2.22.0 version (was: Update Ignite dependency log4j2) > Update Ignite dependency log4j2 > --- > > Key: IGNITE-21029 > URL: https://issues.apache.org/jira/browse/IGNITE-21029 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency log4j2 2.20.0 to 2.22.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793623#comment-17793623 ] Mikhail Petrov commented on IGNITE-21021: - --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793623#comment-17793623 ] Mikhail Petrov edited comment on IGNITE-21021 at 12/6/23 10:36 AM: --- --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the CONTROL UTILITY commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. was (Author: petrovmikhail): --cache destroy (CACHE_DESTROY) --cache clear (CACHE_REMOVE) --cache create (CACHE_CREATE) --cache scan (CACHE_READ) All the commands mentioned above have been corrected so that when executed, only the permissions specified in parentheses are checked. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-21021. - Resolution: Fixed > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21021: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793619#comment-17793619 ] Mikhail Petrov commented on IGNITE-21021: - [~NSAmelchev] Thank you for the review. > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21021) control.sh cache scan permissions
[ https://issues.apache.org/jira/browse/IGNITE-21021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21021: --- Assignee: Mikhail Petrov > control.sh cache scan permissions > - > > Key: IGNITE-21021 > URL: https://issues.apache.org/jira/browse/IGNITE-21021 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > At startup control.sh --cache scan CACHE_NAME the permissions for ADMIN_OPS > and CACHE_READ are checked, at least it would be more logical to use only > CACHE_READ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21023) [Control Utility] Authorization errors are propagated to user as a task execution exception
Mikhail Petrov created IGNITE-21023: --- Summary: [Control Utility] Authorization errors are propagated to user as a task execution exception Key: IGNITE-21023 URL: https://issues.apache.org/jira/browse/IGNITE-21023 Project: Ignite Issue Type: Task Reporter: Mikhail Petrov If the control utility command authorization fails, the user output will contain only an illegible stack trace of the exception associated with the execution of the internal task. In some cases it is impossible to determine the root caused command to fail. As an example you can execute `--cache clear --caches DEFAULT_CACHE_NAME` on behalf of the user with no "CACHE_REMOVE" permission granted. As a result you will get something like that {code:java} Command [CACHE] finished with code: 4 Error stack trace: class org.apache.ignite.internal.client.GridClientException: Failed to reduce job results due to undeclared user exception [task=org.apache.ignite.internal.processors.cache.ClearCachesTask@63acb0d2, err=class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to execute job due to unexpected runtime exception [jobId=5e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80, ses=GridJobSessionImpl [ses=GridTaskSessionImpl [taskName=org.apache.ignite.internal.processors.cache.ClearCachesTask, dep=GridDeployment [ts=1701791460030, depMode=SHARED, clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, clsLdrId=4e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80, userVer=0, loc=true, sampleClsName=org.apache.ignite.internal.processors.cache.ClearCachesTask, pendingUndeploy=false, undeployed=false, usage=2], taskClsName=org.apache.ignite.internal.processors.cache.ClearCachesTask, sesId=3e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80, startTime=1701791460020, endTime=9223372036854775807, taskNodeId=3ea239af-6e36-4bde-bc0b-121aca80, clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=true, topPred=null, mapFut=IgniteFuture [orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null, hash=972210139]], execName=null, secCtx=TestSecurityContext{subject=TestSecuritySubject{id=26ddd492-a139-4dff-8d6d-27c412101dcc, type=REMOTE_CLIENT, login=no-permissions-login}}], jobId=5e5ecaa3c81-3ea239af-6e36-4bde-bc0b-121aca80], err=class org.apache.ignite.IgniteCheckedException: Remote job threw exception.]] at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:634) at org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:565) at org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:691) at org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279) at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) at org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116) at org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) at org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3753) at org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175) at org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1211) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2527) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2282) at org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1911) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) at java.lang.Thread.run(Thread.java:750) {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21008) Update Ignite dependency: Netty
[ https://issues.apache.org/jira/browse/IGNITE-21008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-21008: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Update Ignite dependency: Netty > --- > > Key: IGNITE-21008 > URL: https://issues.apache.org/jira/browse/IGNITE-21008 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: Netty 4.1.89.Final to 4.1.101.Final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[ https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-12625: --- Assignee: Mikhail Petrov > Thin client: Marshaling/unmarshaling of objects performed twice > --- > > Key: IGNITE-12625 > URL: https://issues.apache.org/jira/browse/IGNITE-12625 > Project: Ignite > Issue Type: Bug > Components: binary, thin client >Reporter: Aleksey Plekhanov >Assignee: Mikhail Petrov >Priority: Major > > For each thin client cache operation marshaling/unmarshaling of objects > performed twice. For example, cache "put" operation marshal object on the > client-side, then unmarshal object (with keep binaries) on the server-side > and marshal it again before putting it to the cache. It causes some > undesirable effects. For example, references to the same binary object in a > collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized > as different objects. > Reproducer: > {code:java} > try (IgniteClient client = startClient()) { > ClientCache cache = > client.getOrCreateCache(DEFAULT_CACHE_NAME); > Person person = new Person(0, "name"); > cache.put(0, new Object[] {person, person} ); > Object[] res = cache.get(0); > assertTrue(res[0] == res[1]); > }{code} > Also, we need to unwrap binaries recursively since all objects inside > collections, arrays and maps become binary objects after > marshaling/unmarshalling (see IGNITE-12468) > Also, we don't know do we really need to deserialize binary objects. If > object was originally binary there is no evidence of this after > marshaling/unmarshaling on server-side. This leads to problems when a binary > object was created for unknown class. > Reproducer: > {code:java} > cache.put(0, client.binary().builder("TestType").setField("test", > "val").build()); > cache.get(0);{code} > Will throw exception: > {noformat} > class org.apache.ignite.binary.BinaryInvalidTypeException: TestType > at > org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:762) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757) > at > org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:319) > at > org.apache.ignite.internal.client.thin.ClientBinaryMarshaller.deserialize(ClientBinaryMarshaller.java:74) > at > org.apache.ignite.internal.client.thin.ClientUtils.unwrapBinary(ClientUtils.java:558) > at > org.apache.ignite.internal.client.thin.ClientUtils.readObject(ClientUtils.java:547){noformat} > To avoid double marshaling we could pass byte array from request content to > cache directly (for example using {{CacheObject}}), but we don't have object > size in thin client protocol, so in any case, we need to traverse the > objects. Also, we don't have the ability to get {{CacheObject}} from the > cache now, so such an approach will only work in one way, for "put" > operations, but not for "get" operations. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787072#comment-17787072 ] Mikhail Petrov commented on IGNITE-15419: - Fixed as part of https://issues.apache.org/jira/browse/IGNITE-19807 > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reopened IGNITE-15419: - > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-15419. - Resolution: Duplicate > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-15419: Ignite Flags: (was: Docs Required,Release Notes Required) > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15419) [Security] Unify the authentication and authorization process for joining node across all discovery implementations
[ https://issues.apache.org/jira/browse/IGNITE-15419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov resolved IGNITE-15419. - Resolution: Fixed > [Security] Unify the authentication and authorization process for joining > node across all discovery implementations > --- > > Key: IGNITE-15419 > URL: https://issues.apache.org/jira/browse/IGNITE-15419 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > It is needed to unify the authentication and authorization process for > joining node across all discovery implementations. Currently the logic of new > node authentication and authorization is duplicated with some differences. > For example in TCP discovery implementation node is authorized for > NODE_JOINED permission in zookeeper discovery implementation this check is > missed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785036#comment-17785036 ] Mikhail Petrov commented on IGNITE-19807: - [~NSAmelchev] Thank you for the review. > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 1h > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20656) Service awareness for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-20656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784577#comment-17784577 ] Mikhail Petrov commented on IGNITE-20656: - Merged to the master branch. [~vladsz83] Thank you for the contribution! [~ptupitsyn] Thank you for the review! > Service awareness for java thin client > -- > > Key: IGNITE-20656 > URL: https://issues.apache.org/jira/browse/IGNITE-20656 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Java thin client (like the other clients) can call service on a node where > service is not deployed. We might implement service awareness like partition > awareness starting with java thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20656) Service awareness for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-20656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20656: Fix Version/s: 2.16 > Service awareness for java thin client > -- > > Key: IGNITE-20656 > URL: https://issues.apache.org/jira/browse/IGNITE-20656 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 4h > Remaining Estimate: 0h > > Java thin client (like the other clients) can call service on a node where > service is not deployed. We might implement service awareness like partition > awareness starting with java thin client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779912#comment-17779912 ] Mikhail Petrov commented on IGNITE-20627: - [~NSAmelchev] Thank you for the review. > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Labels: ise (was: ) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Ignite Flags: Docs Required (was: Docs Required,Release Notes Required) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Fix Version/s: 2.16 > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20627) Add the number of partitions processed by the indexing worker to the output of the index_rebuild_status command.
[ https://issues.apache.org/jira/browse/IGNITE-20627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20627: Priority: Minor (was: Major) > Add the number of partitions processed by the indexing worker to the output > of the index_rebuild_status command. > > > Key: IGNITE-20627 > URL: https://issues.apache.org/jira/browse/IGNITE-20627 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)