[jira] [Updated] (IGNITE-21202) Use node ID instead of node name to identify primary node in client primary replica tracker
[
https://issues.apache.org/jira/browse/IGNITE-21202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21202:
---
Description:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
# Here we are using the deprecated property, but we should use the leasholder
ID.
{code:java}
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
primaryReplicaEvent.leaseholder()); {code}
# The lesholder property should be removed from the event parameters.
was:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
# Here we are using the deprecated property, but we should use the leasholder
ID.
{code:java}
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
primaryReplicaEvent.leaseholder()); {code}
# The lesholder property should be removed from the event parameters.
> Use node ID instead of node name to identify primary node in client primary
> replica tracker
> ---
>
> Key: IGNITE-21202
> URL: https://issues.apache.org/jira/browse/IGNITE-21202
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Recently, we changed the process of granting leases. This process uses the
> node ID as a leaseholder identifier. The other components should also follow
> this consistently.
> h3. Definition of done
> # Here we are using the deprecated property, but we should use the
> leasholder ID.
> {code:java}
> updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
> primaryReplicaEvent.leaseholder()); {code}
> # The lesholder property should be removed from the event parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21202) Use node ID instead of node name to identify primary node in client primary replica tracker
[
https://issues.apache.org/jira/browse/IGNITE-21202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21202:
---
Description:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
# Here we are using the deprecated property, but we should use the leasholder
ID.
{code:java}
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
primaryReplicaEvent.leaseholder()); {code}
# The lesholder property should be removed from the event parameters.
was:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
# Here we are using the deprecated property, but we should use the leasholder
ID.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
# The lesholder property should be removed from the event parameters.
> Use node ID instead of node name to identify primary node in client primary
> replica tracker
> ---
>
> Key: IGNITE-21202
> URL: https://issues.apache.org/jira/browse/IGNITE-21202
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Recently, we changed the process of granting leases. This process uses the
> node ID as a leaseholder identifier. The other components should also follow
> this consistently.
> h3. Definition of done
> # Here we are using the deprecated property, but we should use the
> leasholder ID.
> {code:java}
> updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
> primaryReplicaEvent.leaseholder()); {code}
> # The lesholder property should be removed from the event parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21202) Use node ID instead of node name to identify primary node in client primary replica tracker
[
https://issues.apache.org/jira/browse/IGNITE-21202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21202:
---
Description:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
# Here we are using the deprecated property, but we should use the leasholder
ID.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
# The lesholder property should be removed from the event parameters.
was:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
Here we resolve a node name by the node ID, but we should use the ID as is.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
> Use node ID instead of node name to identify primary node in client primary
> replica tracker
> ---
>
> Key: IGNITE-21202
> URL: https://issues.apache.org/jira/browse/IGNITE-21202
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Recently, we changed the process of granting leases. This process uses the
> node ID as a leaseholder identifier. The other components should also follow
> this consistently.
> h3. Definition of done
> # Here we are using the deprecated property, but we should use the leasholder
> ID.
> {code}
> String leaseholderName =
> topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
> updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
> leaseholderName);
> {code}
> # The lesholder property should be removed from the event parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20883) ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query was cancelled while executing
[
https://issues.apache.org/jira/browse/IGNITE-20883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803272#comment-17803272
]
Vladislav Pyatkov edited comment on IGNITE-20883 at 1/4/24 6:23 PM:
I am not 100% sure, but in the log, I noted a suspected behavior:
{noformat}
[2023-12-19T10:24:58,211][INFO
][%node2%JRaft-Request-Processor-17][ReplicaManager] Lease accepted
[group=5_part_15, leaseStartTime=HybridTimestamp [physical=2023-12-19
10:24:58:207 +, logical=8, composite=111606595466493960]].
[2023-12-19T10:24:58,222][INFO
][%node2%metastorage-watch-executor-0][PartitionReplicaListener] Primary
replica expired [grp=5_part_15]
{noformat}
The lease was withdrew after several milliseconds that had been accepted. It is
not possible because the lease interval is much longer than several
milliseconds. But this happens because we are incorrectly checking a threshold
in the placement driver event listener.
{code}
org.apache.ignite.internal.placementdriver.event.PrimaryReplicaEventParameters#leaseholder
{code}
In this ticket, I am replacing a lesholder name with a lesholder ID to handle
this event correctly.
This malicious behavior can also be a reason for incorrect mapping in the thin
client. I have created another ticket to resolve this IGNITE-21202
was (Author: v.pyatkov):
I am not 100% sure, but in the log, I noted a suspected behavior:
{noformat}
[2023-12-19T10:24:58,211][INFO
][%node2%JRaft-Request-Processor-17][ReplicaManager] Lease accepted
[group=5_part_15, leaseStartTime=HybridTimestamp [physical=2023-12-19
10:24:58:207 +, logical=8, composite=111606595466493960]].
[2023-12-19T10:24:58,222][INFO
][%node2%metastorage-watch-executor-0][PartitionReplicaListener] Primary
replica expired [grp=5_part_15]
{noformat}
The lease was withdrew after several milliseconds that had been accepted. It is
not possible because the lease interval is much longer than several
milliseconds. But this happens because we are incorrectly checking a threshold
in the placement driver event listener.
{code}
org.apache.ignite.internal.placementdriver.event.PrimaryReplicaEventParameters#leaseholder
{code}
In this ticket, I am replacing a lesholder name with a lesholder ID to handle
this event correctly.
This malicious behavior can also be a reason for incorrect mapping in the thin
client. I created another issue to resolve this IGNITE-21202
> ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query
> was cancelled while executing
> -
>
> Key: IGNITE-20883
> URL: https://issues.apache.org/jira/browse/IGNITE-20883
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-SQL-8
> TraceId:bdc067e0-18f5-4c17-a3c7-9777e02a9abd The query was cancelled while
> executing. at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:536)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:487)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest.checkSchemasCorrectlyRestore(ItDataSchemaSyncTest.java:268)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
>
[jira] [Comment Edited] (IGNITE-20883) ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query was cancelled while executing
[
https://issues.apache.org/jira/browse/IGNITE-20883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803272#comment-17803272
]
Vladislav Pyatkov edited comment on IGNITE-20883 at 1/4/24 6:22 PM:
I am not 100% sure, but in the log, I noted a suspected behavior:
{noformat}
[2023-12-19T10:24:58,211][INFO
][%node2%JRaft-Request-Processor-17][ReplicaManager] Lease accepted
[group=5_part_15, leaseStartTime=HybridTimestamp [physical=2023-12-19
10:24:58:207 +, logical=8, composite=111606595466493960]].
[2023-12-19T10:24:58,222][INFO
][%node2%metastorage-watch-executor-0][PartitionReplicaListener] Primary
replica expired [grp=5_part_15]
{noformat}
The lease was withdrew after several milliseconds that had been accepted. It is
not possible because the lease interval is much longer than several
milliseconds. But this happens because we are incorrectly checking a threshold
in the placement driver event listener.
{code}
org.apache.ignite.internal.placementdriver.event.PrimaryReplicaEventParameters#leaseholder
{code}
In this ticket, I am replacing a lesholder name with a lesholder ID to handle
this event correctly.
This malicious behavior can also be a reason for incorrect mapping in the thin
client. I created another issue to resolve this IGNITE-21202
was (Author: v.pyatkov):
I am not 100% sure, but in the log, I noted a suspected behavior:
{noformat}
[2023-12-19T10:24:58,211][INFO
][%node2%JRaft-Request-Processor-17][ReplicaManager] Lease accepted
[group=5_part_15, leaseStartTime=HybridTimestamp [physical=2023-12-19
10:24:58:207 +, logical=8, composite=111606595466493960]].
[2023-12-19T10:24:58,222][INFO
][%node2%metastorage-watch-executor-0][PartitionReplicaListener] Primary
replica expired [grp=5_part_15]
{noformat}
The lease was withdrew after several milliseconds that had been accepted. It is
not possible because the lease interval is much longer than several
milliseconds. But this happens because we are incorrectly checking a threshold
in the placement driver event listener.
{code}
org.apache.ignite.internal.placementdriver.event.PrimaryReplicaEventParameters#leaseholder
{code}
In this ticket, I am replacing a lesholder name with a lesholder ID to handle
this event correctly.
> ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query
> was cancelled while executing
> -
>
> Key: IGNITE-20883
> URL: https://issues.apache.org/jira/browse/IGNITE-20883
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-SQL-8
> TraceId:bdc067e0-18f5-4c17-a3c7-9777e02a9abd The query was cancelled while
> executing. at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:536)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:487)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest.checkSchemasCorrectlyRestore(ItDataSchemaSyncTest.java:268)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
>
[jira] [Commented] (IGNITE-20883) ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query was cancelled while executing
[
https://issues.apache.org/jira/browse/IGNITE-20883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803272#comment-17803272
]
Vladislav Pyatkov commented on IGNITE-20883:
I am not 100% sure, but in the log, I noted a suspected behavior:
{noformat}
[2023-12-19T10:24:58,211][INFO
][%node2%JRaft-Request-Processor-17][ReplicaManager] Lease accepted
[group=5_part_15, leaseStartTime=HybridTimestamp [physical=2023-12-19
10:24:58:207 +, logical=8, composite=111606595466493960]].
[2023-12-19T10:24:58,222][INFO
][%node2%metastorage-watch-executor-0][PartitionReplicaListener] Primary
replica expired [grp=5_part_15]
{noformat}
The lease was withdrew after several milliseconds that had been accepted. It is
not possible because the lease interval is much longer than several
milliseconds. But this happens because we are incorrectly checking a threshold
in the placement driver event listener.
{code}
org.apache.ignite.internal.placementdriver.event.PrimaryReplicaEventParameters#leaseholder
{code}
In this ticket, I am replacing a lesholder name with a lesholder ID to handle
this event correctly.
> ItDataSchemaSyncTest.checkSchemasCorrectlyRestore() is flaky with The query
> was cancelled while executing
> -
>
> Key: IGNITE-20883
> URL: https://issues.apache.org/jira/browse/IGNITE-20883
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-SQL-8
> TraceId:bdc067e0-18f5-4c17-a3c7-9777e02a9abd The query was cancelled while
> executing. at
> java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:536)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:487)
> at
> app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> app//org.apache.ignite.internal.runner.app.ItDataSchemaSyncTest.checkSchemasCorrectlyRestore(ItDataSchemaSyncTest.java:268)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566) at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
>
[jira] [Updated] (IGNITE-21202) Use node ID instead of node name to identify primary node in client primary replica tracker
[
https://issues.apache.org/jira/browse/IGNITE-21202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-21202:
---
Description:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
Here we resolve a node name by the node ID, but we should use the ID as is.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
was:
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
Here we resolve a node name by the node ID, but we should use the ID as is.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
> Use node ID instead of node name to identify primary node in client primary
> replica tracker
> ---
>
> Key: IGNITE-21202
> URL: https://issues.apache.org/jira/browse/IGNITE-21202
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Recently, we changed the process of granting leases. This process uses the
> node ID as a leaseholder identifier. The other components should also follow
> this consistently.
> h3. Definition of done
> Here we resolve a node name by the node ID, but we should use the ID as is.
> {code}
> String leaseholderName =
> topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
> updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
> leaseholderName);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21202) Use node ID instead of node name to identify primary node in client primary replica tracker
Vladislav Pyatkov created IGNITE-21202:
--
Summary: Use node ID instead of node name to identify primary node
in client primary replica tracker
Key: IGNITE-21202
URL: https://issues.apache.org/jira/browse/IGNITE-21202
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
h3. Motivation
Recently, we changed the process of granting leases. This process uses the node
ID as a leaseholder identifier. The other components should also follow this
consistently.
h3. Definition of done
Here we resolve a node name by the node ID, but we should use the ID as is.
{code}
String leaseholderName =
topologyService.getById(primaryReplicaEvent.leaseholderId()).name();
updatePrimaryReplica(tablePartitionId, primaryReplicaEvent.startTime(),
leaseholderName);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21201) Sql. Move computations from the listener thread
[ https://issues.apache.org/jira/browse/IGNITE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21201: -- Description: Invalidation of cached plan mappings is performed from listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. was: Invalidation of cached plan mappings is performed from placement driver listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. > Sql. Move computations from the listener thread > --- > > Key: IGNITE-21201 > URL: https://issues.apache.org/jira/browse/IGNITE-21201 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Invalidation of cached plan mappings is performed from listener thread (see > MappingServiceImpl#onPrimaryReplicaExpired). > It seems that this calculation should be moved to another thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21201) Sql. Move computations from the listener thread
[ https://issues.apache.org/jira/browse/IGNITE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21201: -- Summary: Sql. Move computations from the listener thread (was: Sql. Move computations from the replica listener thread) > Sql. Move computations from the listener thread > --- > > Key: IGNITE-21201 > URL: https://issues.apache.org/jira/browse/IGNITE-21201 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Invalidation of cached plan mappings is performed from placement driver > listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). > It seems that this calculation should be moved to another thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21201) Sql. Move computations from the listener thread
[ https://issues.apache.org/jira/browse/IGNITE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21201: -- Description: Invalidation of cached plan mappings is performed from listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this computations should be moved to another thread. was: Invalidation of cached plan mappings is performed from listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. > Sql. Move computations from the listener thread > --- > > Key: IGNITE-21201 > URL: https://issues.apache.org/jira/browse/IGNITE-21201 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Invalidation of cached plan mappings is performed from listener thread (see > MappingServiceImpl#onPrimaryReplicaExpired). > It seems that this computations should be moved to another thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21201) Sql. Move computations from the replica listener thread
[ https://issues.apache.org/jira/browse/IGNITE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21201: -- Description: Invalidation of cached plan mappings is performed from placement driver listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. was: Invalidation of cached plan mappings is performed from partition replica listener (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. > Sql. Move computations from the replica listener thread > --- > > Key: IGNITE-21201 > URL: https://issues.apache.org/jira/browse/IGNITE-21201 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Invalidation of cached plan mappings is performed from placement driver > listener thread (see MappingServiceImpl#onPrimaryReplicaExpired). > It seems that this calculation should be moved to another thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21201) Sql. Move computations from the replica listener thread
Pavel Pereslegin created IGNITE-21201: - Summary: Sql. Move computations from the replica listener thread Key: IGNITE-21201 URL: https://issues.apache.org/jira/browse/IGNITE-21201 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Pereslegin Invalidation of cached plan mappings is performed from partition replica listener (see MappingServiceImpl#onPrimaryReplicaExpired). It seems that this calculation should be moved to another thread. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21200) IgniteRunner start fails in Windows via git-bash
[
https://issues.apache.org/jira/browse/IGNITE-21200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-21200:
--
Labels: ignite-3 windows (was: ignite-3)
> IgniteRunner start fails in Windows via git-bash
>
>
> Key: IGNITE-21200
> URL: https://issues.apache.org/jira/browse/IGNITE-21200
> Project: Ignite
> Issue Type: Bug
> Components: binary, cli
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3, windows
> Fix For: 3.0.0-beta2
>
>
> h3. Steps to reproduce:
> # Build ignite3-db-3.0.0-SNAPSHOT.zip distribution from sources.
> # Use git-bash to run `./ignite3db start` in Windows.
> h3. Expected:
> IgniteRunner started.
> h3. Actual:
> Error:
> {code:java}
> ./ignite3db: line 38: C:\Program: No such file or directory{code}
> h3. Details:
> The space in path to java (C:\Program Files) is considered as separation
> between command and arguments. To avoid it, usage of all variables have to
> replaced to arrays. For example `${JAVA_CMD_WITH_ARGS}` have to be replaced
> to `${JAVA_CMD_WITH_ARGS[@]}` and so on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21200) IgniteRunner start fails in Windows via git-bash
Igor created IGNITE-21200:
-
Summary: IgniteRunner start fails in Windows via git-bash
Key: IGNITE-21200
URL: https://issues.apache.org/jira/browse/IGNITE-21200
Project: Ignite
Issue Type: Bug
Components: binary, cli
Affects Versions: 3.0.0-beta2
Reporter: Igor
Fix For: 3.0.0-beta2
h3. Steps to reproduce:
# Build ignite3-db-3.0.0-SNAPSHOT.zip distribution from sources.
# Use git-bash to run `./ignite3db start` in Windows.
h3. Expected:
IgniteRunner started.
h3. Actual:
Error:
{code:java}
./ignite3db: line 38: C:\Program: No such file or directory{code}
h3. Details:
The space in path to java (C:\Program Files) is considered as separation
between command and arguments. To avoid it, usage of all variables have to
replaced to arrays. For example `${JAVA_CMD_WITH_ARGS}` have to be replaced to
`${JAVA_CMD_WITH_ARGS[@]}` and so on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21089) [YCSB] "IgniteException: readerIndex: 0, writerIndex: 257" on SQL SELECT
[
https://issues.apache.org/jira/browse/IGNITE-21089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803016#comment-17803016
]
Yury Gerzhedovich commented on IGNITE-21089:
[~Artukhov] could you please switch on sendServerExceptionStackTraceToClient
property for all tests?
It give us more information.
> [YCSB] "IgniteException: readerIndex: 0, writerIndex: 257" on SQL SELECT
>
>
> Key: IGNITE-21089
> URL: https://issues.apache.org/jira/browse/IGNITE-21089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Ivan Artiukhov
>Priority: Major
> Labels: ignite-3
> Attachments: 2023-12-15-04-58-54_run.txt, logs-818.zip
>
>
> AI3 rev. {{ba6cd4dfff0e4bc2eacb437a1331454e030bff84}}
> Benchmark:
> [https://github.com/gridgain/YCSB/blob/ycsb-2023.9/ignite3/src/main/java/site/ycsb/db/ignite3/IgniteSqlClient.java]
>
> The benchmark uses Ignite 3 Java SQL API to perform SQL queries.
> h1. Setup
> 1 server node, 1 client node (1 thread)
> h1. Steps
> The benchmark was started 2 times:
> # in {{load}} mode to preload 165k unique entries via {{INSERT}} (15k in
> warmup phase + 150k in payload phase)
> # in {{run}} mode to {{SELECT}} each entry one by one
> h1. Expected result
> # The {{load}} mode finishes successfully without errors
> # The {{run}} mode finishes successfully without errors
> h1. Actual result
> # The {{load}} mode finishes successfully without errors
> # In the {{run}} mode the very first 128 entries were read with the
> following error. All other entries were read successfully.
> {noformat}
> org.apache.ignite.lang.IgniteException: readerIndex: 0, writerIndex: 257
> (expected: 0 <= readerIndex <= writerIndex <= capacity(256))
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:754)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:688)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:623)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at site.ycsb.db.ignite3.IgniteSqlClient.read(IgniteSqlClient.java:51)
> [ignite3-binding-2023.9.jar:?]
> at site.ycsb.DBWrapper.read(DBWrapper.java:145) [core-2023.9.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransactionRead(CoreWorkload.java:746)
> [core-2023.9.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransaction(CoreWorkload.java:666)
> [core-2023.9.jar:?]
> at site.ycsb.ClientThread.run(ClientThread.java:145) [core-2023.9.jar:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:b0e3aa62-ba41-47bd-8238-f39537f78e28 readerIndex: 0, writerIndex: 257
> (expected: 0 <= readerIndex <= writerIndex <= capacity(256))
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> ~[?:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:417)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:241)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> ~[?:?]
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> ~[?:?]
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> ~[?:?]
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) ~[?:?]
> at
[jira] [Updated] (IGNITE-20878) Basic criteria queries for record view
[
https://issues.apache.org/jira/browse/IGNITE-20878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-20878:
Fix Version/s: 3.0.0-beta2
> Basic criteria queries for record view
> --
>
> Key: IGNITE-20878
> URL: https://issues.apache.org/jira/browse/IGNITE-20878
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 18h 20m
> Remaining Estimate: 0h
>
> Implement basic criteria query for record view.
> The only field in {{CreteriaQueryOptions}} should be {{{}pageSize{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21196) PrimaryReplicaEvent handling is inefficient
[
https://issues.apache.org/jira/browse/IGNITE-21196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-21196:
---
Reviewer: Vladislav Pyatkov (was: Vladislav Pyatkov)
> PrimaryReplicaEvent handling is inefficient
> ---
>
> Key: IGNITE-21196
> URL: https://issues.apache.org/jira/browse/IGNITE-21196
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, every partition replica listener has its own set of instances of
> {{PrimaryReplicaEvent}} listeners. In
> {{LeaseTracker.UpdateListener#onUpdate}} we create these events in a loop.
>
> This results in 2 nested loops, which might be extremely inefficient if we
> have a lot of replicas on the node. Most of iterations will do nothing
> because the following condition won't pass:
> {{!replicationGroupId.equals(evt.groupId())}}
>
> I suggest subscribing to these events in {{ReplicaManager}} and perform
> necessary filtering in advance. Such change will greatly improve the
> performance of lease update watch event processing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21196) PrimaryReplicaEvent handling is inefficient
[
https://issues.apache.org/jira/browse/IGNITE-21196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-21196:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> PrimaryReplicaEvent handling is inefficient
> ---
>
> Key: IGNITE-21196
> URL: https://issues.apache.org/jira/browse/IGNITE-21196
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, every partition replica listener has its own set of instances of
> {{PrimaryReplicaEvent}} listeners. In
> {{LeaseTracker.UpdateListener#onUpdate}} we create these events in a loop.
>
> This results in 2 nested loops, which might be extremely inefficient if we
> have a lot of replicas on the node. Most of iterations will do nothing
> because the following condition won't pass:
> {{!replicationGroupId.equals(evt.groupId())}}
>
> I suggest subscribing to these events in {{ReplicaManager}} and perform
> necessary filtering in advance. Such change will greatly improve the
> performance of lease update watch event processing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21198) Optimize memory usage of AbstractEventProducer#fireEvent
[ https://issues.apache.org/jira/browse/IGNITE-21198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-21198: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Optimize memory usage of AbstractEventProducer#fireEvent > > > Key: IGNITE-21198 > URL: https://issues.apache.org/jira/browse/IGNITE-21198 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > In current implementation, most of listeners do their work synchronously and > return already completed futures. In that cases there's no sense to allocate > the entire array of futures and fill it. > Another reason for not allocating an array right away is the fact that we may > have a big number of listeners, and allocating an array will be expensive and > wasteful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21199) Introduce a mechanism to manage and schedule Ignite services tasks
Ivan Gagarkin created IGNITE-21199: -- Summary: Introduce a mechanism to manage and schedule Ignite services tasks Key: IGNITE-21199 URL: https://issues.apache.org/jira/browse/IGNITE-21199 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin We have service tasks such as GC, and we anticipate more, which consume resources shared with user tasks, such as queries. These tasks should not monopolize resources when a node is engaged in user queries but should utilize all resources during idle times. We need to develop a common mechanism to manage resource allocation between service tasks and user tasks, ensuring this component is reusable across different service task-creating components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21195) Fix ClientArchTest
[
https://issues.apache.org/jira/browse/IGNITE-21195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Pochatkin resolved IGNITE-21195.
Resolution: Won't Fix
> Fix ClientArchTest
> ---
>
> Key: IGNITE-21195
> URL: https://issues.apache.org/jira/browse/IGNITE-21195
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> Architecture Violation [Priority: MEDIUM] - Rule 'no fields that have raw
> type org.apache.ignite.internal.logger.IgniteLogger should have modifier
> STATIC' was violated (1 times):
> Field has
> modifier STATIC in (TrackableNetworkMessageHandler.java:0)
> java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule
> 'no fields that have raw type org.apache.ignite.internal.logger.IgniteLogger
> should have modifier STATIC' was violated (1 times):
> Field has
> modifier STATIC in (TrackableNetworkMessageHandler.java:0)
> at
> com.tngtech.archunit.lang.ArchRule$Assertions.assertNoViolation(ArchRule.java:94)...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21009) .NET: Thin 3.0: Nullable columns are not supported in KeyValueView with primitive mapping
[
https://issues.apache.org/jira/browse/IGNITE-21009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802628#comment-17802628
]
Pavel Tupitsyn commented on IGNITE-21009:
-
Merged to main: ba4f9572bb2e2509cdf6dd1758dda5bd05b2b88c
> .NET: Thin 3.0: Nullable columns are not supported in KeyValueView with
> primitive mapping
> -
>
> Key: IGNITE-21009
> URL: https://issues.apache.org/jira/browse/IGNITE-21009
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test fails:
> {code}
> [Test]
> public async Task TestPutGetNullable()
> {
> await Client.Sql.ExecuteAsync(null, "CREATE TABLE TestPutGetNullable
> (ID BIGINT PRIMARY KEY, VAL BIGINT)");
> await Client.Sql.ExecuteAsync(null, "INSERT INTO TestPutGetNullable
> VALUES (1, 1), (2, NULL)");
> var table = await Client.Tables.GetTableAsync("TestPutGetNullable");
> var view = table!.GetKeyValueView();
> var res1 = await view.GetAsync(null, 1);
> var res2 = await view.GetAsync(null, 2);
> }
> {code}
> Result:
> {code}
> System.InvalidOperationException : Binary tuple element with index 1 is null.
>at
> Apache.Ignite.Internal.Proto.BinaryTuple.BinaryTupleReader.ThrowNullElementException[T](Int32
> index) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Proto/BinaryTuple/BinaryTupleReader.cs:line
> 572
>at
> Apache.Ignite.Internal.Proto.BinaryTuple.BinaryTupleReader.GetLong(Int32
> index) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Proto/BinaryTuple/BinaryTupleReader.cs:line
> 155
>at
> ReadApache.Ignite.Internal.Table.Serialization.KvPair`2[System.Int64,System.Int64](BinaryTupleReader&
> )
>at
> Apache.Ignite.Internal.Table.Serialization.ObjectSerializerHandler`1.Read(MsgPackReader&
> reader, Schema schema, Boolean keyOnly)
>at
> Apache.Ignite.Internal.Table.Serialization.RecordSerializer`1.ReadValue(PooledBuffer
> buf, Schema schema)
>at Apache.Ignite.Internal.Table.RecordView`1.GetAsync(ITransaction
> transaction, T key)
>at Apache.Ignite.Internal.Table.KeyValueView`2.GetAsync(ITransaction
> transaction, TK key)
>at
> Apache.Ignite.Tests.Table.KeyValueViewPrimitiveTests.TestPutGetNullable()
> {code}
> *ITable.GetKeyValueView* does not allow nullable types ("where TV : notnull")
> - so we don't have a way to work with nullable columns in this case.
> See how Java handles this with additional nullable methods: IGNITE-16115
> *Option* can represent 3 states to handle this situation:
> * hasValue=true, value != null
> * hasValue=true, value = null
> * hasValue=false
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
