[jira] [Updated] (IGNITE-1432) .Net: Fix InteropCacheEntryProcessor performance on remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1432: --- Issue Type: Improvement (was: Task) > .Net: Fix InteropCacheEntryProcessor performance on remote nodes > > > Key: IGNITE-1432 > URL: https://issues.apache.org/jira/browse/IGNITE-1432 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Considerations: > 1) Invoke with single key is expected to be called only once, so no changes > is needed here - deploy and execute in a single JNI call. > 2) If there are several keys, there is a high chance (but still not 100% due > to partitioning) that processor will be called multiple times. > Proposed solution: > 1) Check amout of keys. > 2) If cnt == 1, no changes to current logic. > 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor > entry must be put into weak-map located somewhere inside the interop > processor. Interop processor must constantly listen for corresponding > reference queue and release .Net entries as soon as processor is weakly > reacheable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1432) .NET: Fix InteropCacheEntryProcessor performance on remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1432: --- Summary: .NET: Fix InteropCacheEntryProcessor performance on remote nodes (was: .Net: Fix InteropCacheEntryProcessor performance on remote nodes) > .NET: Fix InteropCacheEntryProcessor performance on remote nodes > > > Key: IGNITE-1432 > URL: https://issues.apache.org/jira/browse/IGNITE-1432 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Considerations: > 1) Invoke with single key is expected to be called only once, so no changes > is needed here - deploy and execute in a single JNI call. > 2) If there are several keys, there is a high chance (but still not 100% due > to partitioning) that processor will be called multiple times. > Proposed solution: > 1) Check amout of keys. > 2) If cnt == 1, no changes to current logic. > 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor > entry must be put into weak-map located somewhere inside the interop > processor. Interop processor must constantly listen for corresponding > reference queue and release .Net entries as soon as processor is weakly > reacheable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1432) .Net: Fix InteropCacheEntryProcessor performance on remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1432: Priority: Minor (was: Critical) > .Net: Fix InteropCacheEntryProcessor performance on remote nodes > > > Key: IGNITE-1432 > URL: https://issues.apache.org/jira/browse/IGNITE-1432 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Considerations: > 1) Invoke with single key is expected to be called only once, so no changes > is needed here - deploy and execute in a single JNI call. > 2) If there are several keys, there is a high chance (but still not 100% due > to partitioning) that processor will be called multiple times. > Proposed solution: > 1) Check amout of keys. > 2) If cnt == 1, no changes to current logic. > 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor > entry must be put into weak-map located somewhere inside the interop > processor. Interop processor must constantly listen for corresponding > reference queue and release .Net entries as soon as processor is weakly > reacheable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1432) .Net: Fix InteropCacheEntryProcessor performance on remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1432: --- Labels: .net (was: ) > .Net: Fix InteropCacheEntryProcessor performance on remote nodes > > > Key: IGNITE-1432 > URL: https://issues.apache.org/jira/browse/IGNITE-1432 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Critical > Labels: .net > > Considerations: > 1) Invoke with single key is expected to be called only once, so no changes > is needed here - deploy and execute in a single JNI call. > 2) If there are several keys, there is a high chance (but still not 100% due > to partitioning) that processor will be called multiple times. > Proposed solution: > 1) Check amout of keys. > 2) If cnt == 1, no changes to current logic. > 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor > entry must be put into weak-map located somewhere inside the interop > processor. Interop processor must constantly listen for corresponding > reference queue and release .Net entries as soon as processor is weakly > reacheable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
