[jira] [Created] (IGNITE-13733) Executor name not available within ComputeTaskSession
Moti Nisenson-Ken created IGNITE-13733: -- Summary: Executor name not available within ComputeTaskSession Key: IGNITE-13733 URL: https://issues.apache.org/jira/browse/IGNITE-13733 Project: Ignite Issue Type: Bug Affects Versions: 2.8.1, 2.9, 2.7.6 Reporter: Moti Nisenson-Ken Not having the executor name available can impact ability of user contributions to take advantage of this information without access to internals. For example, a CollisionSPI which rejects jobs to an executor if that executor already has a certain number of active jobs. In such a case, we should be able to determine the number of active jobs per executor and which executor a job wants to run on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Custom Affinity Functions proposed for removal?
I saw at https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist that custom affinity functions are on the potential wishlist for removal. The way we're using it's very critical that we be able to control the placement of data quite precisely - as part of that we specify explicitly the partition we want in the key, and then our affinity function uses that (else delegating to default rendezvous). We don't need all the abilities there, although I think that often others do. This seems to me to be a case that the benefit of removing this is minimal and could cause quite a lot of disruption to users. Thanks!
[jira] [Created] (IGNITE-12727) BYOK support
Moti Nisenson-Ken created IGNITE-12727: -- Summary: BYOK support Key: IGNITE-12727 URL: https://issues.apache.org/jira/browse/IGNITE-12727 Project: Ignite Issue Type: Wish Reporter: Moti Nisenson-Ken Transparent Data Encryption currently works with all keys being held by Ignite. It would be preferable if a Key Wrapping/Unwrapping facility (e.g. Azure Key Vault, IBM Key Protect) could be configured on a per-cache basis. By default the wrapper/unwrapper can just be pas-thru and return the key material as received. Additionally, unwrapping should be able to give a new "storage format" key (in case the underlying root keys have been rotated) which Ignite would then store in place of the original stored wrapped key. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12133) O(log n) partition exchange
Moti Nisenson-Ken created IGNITE-12133: -- Summary: O(log n) partition exchange Key: IGNITE-12133 URL: https://issues.apache.org/jira/browse/IGNITE-12133 Project: Ignite Issue Type: Improvement Reporter: Moti Nisenson-Ken Currently, partition exchange leverages a ring. This means that communications is O(n) in number of nodes. It also means that if non-coordinator nodes hang it can take much longer to successfully resolve the topology. Instead, why not use something like a skip-list where the coordinator is first. The coordinator can notify the first node at each level of the skip-list. Each node then notifies all of its "near-neighbours" in the skip-list, where node B is a near-neighbour of node-A, if max-level(nodeB) <= max-level(nodeA), and nodeB is the first node at its level when traversing from nodeA in the direction of nodeB, skipping over nodes C which have max-level(C) > max-level(A). 1 1 . . .3 1 3 . . . 5 1 . 2 . 3 . 4 . 5 . 6 In the above 1 would notify 2 and 3, 3 would notify 4 and 5, 2 -> 4, and 4 -> 6, and 5 -> 6. One can achieve better redundancy by having each node traverse in both directions, and having the coordinator also notify the last node in the list at each level. This way in the above example if 2 and 3 were both down, 4 would still get notified from 5 and 6 (in the backwards direction). The idea is that each individual node has O(log n) nodes to notify - so the overall time is reduced. Additionally, we can deal well with at least 1 node failure - if one includes the option of processing backwards, 2 consecutive node failures can be handled as well. By taking this kind of an approach, then the coordinator can basically treat any nodes it didn't receive a message from as not-connected, and update the topology as well (disconnecting any nodes that it didn't get a notification from). While there are some edge cases here (e.g. 2 disconnected nodes, then 1 connected node, then 2 disconnected nodes - the connected node would be wrongly ejected from the topology), these would generally be too rare to need explicit handling for. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12115) No event on partition exchange failure
Moti Nisenson-Ken created IGNITE-12115: -- Summary: No event on partition exchange failure Key: IGNITE-12115 URL: https://issues.apache.org/jira/browse/IGNITE-12115 Project: Ignite Issue Type: Bug Reporter: Moti Nisenson-Ken Partition exchange failure can (and does) happen for many different reasons - when it happens the cluster hangs. Currently, it just gets dumped out to logs. An error event should be raised to enable action to be taken; for example, have each node restart itself -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12114) Missing information from JavaDoc - CacheConfiguration setGroupName
Moti Nisenson-Ken created IGNITE-12114: -- Summary: Missing information from JavaDoc - CacheConfiguration setGroupName Key: IGNITE-12114 URL: https://issues.apache.org/jira/browse/IGNITE-12114 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 2.7.5, 2.7, 2.6, 2.5, 2.4 Reporter: Moti Nisenson-Ken All caches in a group must have the same number of backups, otherwise an exception is thrown. CacheConfiguration#setGroupName doesn't document this. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-11619) Misleading Javadoc for IgniteConfiguration.setMetricsExpireTime
Moti Nisenson-Ken created IGNITE-11619:
--
Summary: Misleading Javadoc for
IgniteConfiguration.setMetricsExpireTime
Key: IGNITE-11619
URL: https://issues.apache.org/jira/browse/IGNITE-11619
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7, 2.4
Reporter: Moti Nisenson-Ken
The javadoc reads:
* Sets time in milliseconds after which a certain metric value is considered
expired.
* If not set explicitly, then default value is \{@code 600,000}
milliseconds (10 minutes).
*
* @param metricsExpTime The metricsExpTime to set.
* @see #DFLT_METRICS_EXPIRE_TIME
* @return \{@code this} for chaining.
Note that DFLT_METRICS_EXPIRE_TIME is:
/**
* Default metrics expire time. The value is {@link Long#MAX_VALUE} which
* means that metrics never expire.
*/
I haven't verified which versions are impacted - it has likely been present for
a very long time (at least since 2.4, perhaps much longer)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
