[jira] [Created] (IGNITE-23237) Calcite engine. Refactor CalciteQueryProcessorTest
Aleksey Plekhanov created IGNITE-23237:
--
Summary: Calcite engine. Refactor CalciteQueryProcessorTest
Key: IGNITE-23237
URL: https://issues.apache.org/jira/browse/IGNITE-23237
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
CalciteQueryProcessorTest contains a lot of not grouped tests. We can split
this class into several different classes and group tests somehow (or at least
move some tests to the new classes).
It also contains a lot of boilerplate code, like:
{noformat}
QueryEngine engine = Commons.lookupComponent(grid(1).context(),
QueryEngine.class);
List>> qry = engine.query(...)
{noformat}
We can inherit CalciteQueryProcessorTest (or any new test classes) from
AbstractBasicIntegrationTest and replace query start routine to `sql(...)`.
Some methods can be removed (like testThroughput), it doesn't called by any
test, and it assumes that querySqlFields is executed on H2 engine (it's not
true anymore).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23235) Calcite engine. Wrong result for not-null count if index rebuild in progress
[
https://issues.apache.org/jira/browse/IGNITE-23235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-23235:
---
Labels: calcite ise (was: )
> Calcite engine. Wrong result for not-null count if index rebuild in progress
>
>
> Key: IGNITE-23235
> URL: https://issues.apache.org/jira/browse/IGNITE-23235
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Queries like:
> {noformat}
> SELECT COUNT(val) FROM table
> {noformat}
> Can produce the wrong result if column {{val}} is indexed and index rebuild
> is in progress.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23235) Calcite engine. Wrong result for not-null count if index rebuild in progress
Aleksey Plekhanov created IGNITE-23235:
--
Summary: Calcite engine. Wrong result for not-null count if index
rebuild in progress
Key: IGNITE-23235
URL: https://issues.apache.org/jira/browse/IGNITE-23235
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Queries like:
{noformat}
SELECT COUNT(val) FROM table
{noformat}
Can produce the wrong result if column {{val}} is indexed and index rebuild is
in progress.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23190) Client node deployment manager can be broken on client disconnection
Aleksey Plekhanov created IGNITE-23190:
--
Summary: Client node deployment manager can be broken on client
disconnection
Key: IGNITE-23190
URL: https://issues.apache.org/jira/browse/IGNITE-23190
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
On client disconnect we call {{onDisconnected}} method for each grid component.
For {{GridDeploymentManager}} this callback stops and starts again deployment
stores (including local deployment store).
If some process registers a class between client disconnection and client
reconnection (default timeout between before reconnection is 10 seconds) - new
local deployment will be registered in local deployment store, but this
deployment will be binded to the old node id (node id is regenerated on
reconnect). All futher class registrations with the same local classloader will
use the same deployment and will throw an exception.
Reproducer:
{code:java}
@WithSystemProperty(key = IGNITE_DISCO_FAILED_CLIENT_RECONNECT_DELAY, value =
"1000")
public class IgniteClientReconnectDeploymentTest extends
IgniteClientReconnectAbstractTest {
/** {@inheritDoc} */
@Override protected int serverCount() {
return 1;
}
/** {@inheritDoc} */
@Override protected int clientCount() {
return 1;
}
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return
super.getConfiguration(igniteInstanceName).setPeerClassLoadingEnabled(true);
}
/**
* @throws Exception If failed.
*/
@Test
public void testDeploy() throws Exception {
IgniteEx client = grid(serverCount());
Ignite srv = ignite(0);
IgniteCache cache =
client.getOrCreateCache("test_cache");
reconnectClientNode(client, srv, () -> {
try {
client.context().deploy().deploy(TestEntryProcessor.class,
TestEntryProcessor.class.getClassLoader());
}
catch (IgniteCheckedException e) {
throw new AssertionError(e);
}
});
cache.invoke(0, new TestEntryProcessor());
}
/** */
private static class TestEntryProcessor implements EntryProcessor {
/** {@inheritDoc} */
@Override public Boolean process(MutableEntry entry,
Object... args) {
return true;
}
}
}
{code}
Shows a warning:
{noformat}
[WARN
][test-runner-#137%internal.IgniteClientReconnectDeploymentTest%][GridCacheDeploymentManager]
Should not use deployment to prepare deployable, because local node id does
not correspond with class loader id, and there are no more participants
[locNodeId=061e738c-b0d5-4f19-bef9-c220a77619a3,
deployment=GridDeploymentInfoBean
[clsLdrId=a1f5ca0e191-914c1515-3b63-4a33-bf76-efaf5831, depMode=SHARED,
userVer=0, locDepOwner=false, participants=null],
deployable=GridNearAtomicSingleUpdateRequest [key=UserKeyCacheObjectImpl
[part=0, val=0, hasValBytes=true], super=GridNearAtomicSingleUpdateRequest
[key=UserKeyCacheObjectImpl [part=0, val=0, hasValBytes=true],
parent=GridNearAtomicAbstractSingleUpdateRequest
[nodeId=cf943568-0cf9-4848-9037-ed0f2e70, futId=1,
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
parent=GridNearAtomicAbstractUpdateRequest [res=null, flags=needRes,
locDep=GridDeployment [ts=1726051279184, depMode=SHARED,
clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
clsLdrId=a1f5ca0e191-914c1515-3b63-4a33-bf76-efaf5831, userVer=0, loc=true,
sampleClsName=org.apache.ignite.internal.IgniteClientReconnectDeploymentTest$TestEntryProcessor,
pendingUndeploy=false, undeployed=false, usage=0]]
{noformat}
And throws an exception later:
{noformat}
javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.IgnitePeerToPeerClassLoadingException:
Failed to load class using class loader with given id (loader id doesn't match
sender id and there are no more participants)
[clsLdrId=a1f5ca0e191-914c1515-3b63-4a33-bf76-efaf5831,
senderId=061e738c-b0d5-4f19-bef9-c220a77619a3, participants=null]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1207)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2090)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1731)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1220)
~[classes/:?]
at
org.apache.ignite.internal.IgniteClientReconnectDeploymentTest.testDeploy(IgniteClientReconnectDeploymentTest.java:71)
~[test-classes/:?]
at sun.ref
[jira] [Created] (IGNITE-23008) Calcite engine. Object dynamic parameters are not converted to binary objects
Aleksey Plekhanov created IGNITE-23008:
--
Summary: Calcite engine. Object dynamic parameters are not
converted to binary objects
Key: IGNITE-23008
URL: https://issues.apache.org/jira/browse/IGNITE-23008
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Objects inside Ignite are stored in binary object format. When we pass dynamic
parameters to the query, we left compound objects as is. These objects can't be
compared with objects inside cache. For example:
{code:java}
IgniteCache emp = client.getOrCreateCache(
new CacheConfiguration("emp")
.setSqlSchema("PUBLIC")
.setQueryEntities(F.asList(new QueryEntity(Integer.class,
Employer.class).setTableName("emp")))
);
emp.put(0, new Employer("emp", 0d));
assertQuery("SELECT _key FROM emp WHERE _val = ?").withParams(new
Employer("emp", 0d)).resultSize(1).check();
{code}
This query returns 0 rows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23004) Calcite engine. Multi-node index scan fails on index with binary object field
Aleksey Plekhanov created IGNITE-23004:
--
Summary: Calcite engine. Multi-node index scan fails on index with
binary object field
Key: IGNITE-23004
URL: https://issues.apache.org/jira/browse/IGNITE-23004
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Reproducer:
{code:java}
public class IndexScanMultiNodeIntegrationTest extends
AbstractBasicIntegrationTest {
/** */
@Test
public void testComplexKeyScan() {
IgniteCache emp = client.getOrCreateCache(
new CacheConfiguration("emp")
.setSqlSchema("PUBLIC")
.setQueryEntities(F.asList(new QueryEntity(EmployerKey.class,
Employer.class).setTableName("emp")))
);
for (int i = 0; i < 100; i++)
emp.put(new EmployerKey(i, i), new Employer("emp" + i, (double)i));
assertQuery("SELECT /*+ FORCE_INDEX(\"_key_PK\") */ _key FROM
emp").resultSize(100).check();
}
/** */
private static class EmployerKey {
/** */
@QuerySqlField
private final int id0;
/** */
@QuerySqlField
private final int id1;
/** */
private EmployerKey(int id0, int id1) {
this.id0 = id0;
this.id1 = id1;
}
}
}
{code}
Fails with:
{noformat}
...
Caused by: java.lang.ClassCastException:
org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
java.lang.Comparable
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:248)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.access$300(ExpressionFactoryImpl.java:86)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$1.compare(ExpressionFactoryImpl.java:182)
at java.util.Map$Entry.lambda$comparingByKey$6d558cbf$1(Map.java:508)
at java.util.PriorityQueue.siftUpUsingComparator(PriorityQueue.java:669)
at java.util.PriorityQueue.siftUp(PriorityQueue.java:645)
at java.util.PriorityQueue.offer(PriorityQueue.java:344)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.pushOrdered(Inbox.java:239)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.push(Inbox.java:201)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.Inbox.onBatchReceived(Inbox.java:177)
...
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22994) Refactor subscription to activation/deactivation events for internal components
Aleksey Plekhanov created IGNITE-22994: -- Summary: Refactor subscription to activation/deactivation events for internal components Key: IGNITE-22994 URL: https://issues.apache.org/jira/browse/IGNITE-22994 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently components, which require action on activation and deactivation hardcoded in activation/deactivation code (DataStructuresProcessor, GridTaskProcessor, GridEncryptionManager, DistributedMetaStorage). It will be more convinient to have listeners to these events (IGNITE-22717 will require such a listener too). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22972) [Extensions] Override abstract method indexDefinition() in GeoSpatialIndexImpl.java and GeoSpatialClientIndex.java
[
https://issues.apache.org/jira/browse/IGNITE-22972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22972:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> [Extensions] Override abstract method indexDefinition() in
> GeoSpatialIndexImpl.java and GeoSpatialClientIndex.java
> --
>
> Key: IGNITE-22972
> URL: https://issues.apache.org/jira/browse/IGNITE-22972
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Polozhaev
>Assignee: Denis Polozhaev
>Priority: Major
> Labels: ise
>
> Ignite-Extentions build failure in geospatial module
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure:
> Compilation failure:
> [ERROR]
> /C:/Users/22160647/open/ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialIndexImpl.java:[56,8]
> org.apache.ignite.internal.processors.query.h2.opt.
> GeoSpatialIndexImpl is not abstract and does not override abstract method
> indexDefinition() in org.apache.ignite.internal.cache.query.index.Index
> [ERROR]
> /C:/Users/22160647/open/ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialClientIndex.java:[30,8]
> org.apache.ignite.internal.processors.query.h2.ot.GeoSpatialClientIndex is
> not abstract and does not override abstract method indexDefinition() in
> org.apache.ignite.internal.cache.query.index.Index
> {code}
> https://issues.apache.org/jira/browse/IGNITE-22798 adds a new method
> {code:java}
> public IndexDefinition indexDefinition();
> {code}
> in org.apache.ignite.internal.cache.query.index.Index, that must be overrided
> in
> ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialIndexImpl.java
> and
> ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialClientIndex.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22972) [Extensions] Override abstract method indexDefinition() in GeoSpatialIndexImpl.java and GeoSpatialClientIndex.java
[
https://issues.apache.org/jira/browse/IGNITE-22972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-22972.
Release Note: Fixed Geo-spatial indexes compilation after IGNITE-22798
Resolution: Fixed
[~polozhaevd], looks good to me. Merged to master. Thanks for the contribution!
> [Extensions] Override abstract method indexDefinition() in
> GeoSpatialIndexImpl.java and GeoSpatialClientIndex.java
> --
>
> Key: IGNITE-22972
> URL: https://issues.apache.org/jira/browse/IGNITE-22972
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Polozhaev
>Assignee: Denis Polozhaev
>Priority: Major
> Labels: ise
>
> Ignite-Extentions build failure in geospatial module
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure:
> Compilation failure:
> [ERROR]
> /C:/Users/22160647/open/ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialIndexImpl.java:[56,8]
> org.apache.ignite.internal.processors.query.h2.opt.
> GeoSpatialIndexImpl is not abstract and does not override abstract method
> indexDefinition() in org.apache.ignite.internal.cache.query.index.Index
> [ERROR]
> /C:/Users/22160647/open/ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialClientIndex.java:[30,8]
> org.apache.ignite.internal.processors.query.h2.ot.GeoSpatialClientIndex is
> not abstract and does not override abstract method indexDefinition() in
> org.apache.ignite.internal.cache.query.index.Index
> {code}
> https://issues.apache.org/jira/browse/IGNITE-22798 adds a new method
> {code:java}
> public IndexDefinition indexDefinition();
> {code}
> in org.apache.ignite.internal.cache.query.index.Index, that must be overrided
> in
> ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialIndexImpl.java
> and
> ignite-extensions/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialClientIndex.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22992) Calcite engine. Refactor BaseQueryContext.Builder
Aleksey Plekhanov created IGNITE-22992: -- Summary: Calcite engine. Refactor BaseQueryContext.Builder Key: IGNITE-22992 URL: https://issues.apache.org/jira/browse/IGNITE-22992 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, there are several usages of BaseQueryContext.Builder#frameworkConfig in code, which build new FrameworkConfig instance only to provide default schema. These usages can be simplified. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22991) Calcite engine. Bump Calcite version to 1.37.0
Aleksey Plekhanov created IGNITE-22991: -- Summary: Calcite engine. Bump Calcite version to 1.37.0 Key: IGNITE-22991 URL: https://issues.apache.org/jira/browse/IGNITE-22991 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Current version used by Ignite 2.x is 1.34. There are a lot of useful fixes in the new versions of Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20077) Sql. Bump calcite version to 1.35.0
[ https://issues.apache.org/jira/browse/IGNITE-20077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-20077: --- Labels: ignite-3 (was: calcite2-required ignite-3) > Sql. Bump calcite version to 1.35.0 > --- > > Key: IGNITE-20077 > URL: https://issues.apache.org/jira/browse/IGNITE-20077 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Time Spent: 1h 10m > Remaining Estimate: 0h > > New calcite version was updated [1]. So we need to update > org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable too and as > described in class header item`s : 2, 3, 5 seems can be removed and changed > into native ones. > Also interesting new rule was introduced, probably it would be helpful to > include it. > [1] https://calcite.apache.org/docs/history.html#v1-35-0 > [2] https://issues.apache.org/jira/browse/CALCITE-5669 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22862) Add address information to ClientConnectionException stacktrace
[
https://issues.apache.org/jira/browse/IGNITE-22862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-22862.
Fix Version/s: 2.17
Release Note: Added address information to ClientConnectionException
Resolution: Fixed
[~mmdavydov], looks good to me. Merged to master. Thanks for the contribution!
> Add address information to ClientConnectionException stacktrace
> ---
>
> Key: IGNITE-22862
> URL: https://issues.apache.org/jira/browse/IGNITE-22862
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Minor
> Labels: ise, newbie
> Fix For: 2.17
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> It will be useful to find out from stacktrace which address connection causes
> error. Currently, stacktrace does not have address information:
> {code}
> org.apache.ignite.client.ClientConnectionException: Connection refused
> at
> org.apache.ignite.internal.client.thin.io.gridnioserver.GridNioClientConnectionMultiplexer.open(GridNioClientConnectionMultiplexer.java:197)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:208)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:1055)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:1033)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.applyOnDefaultChannel(ReliableChannel.java:837)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.channelsInit(ReliableChannel.java:749)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.channelsInit(ReliableChannel.java:733)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:155)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:127)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:442)
> at org.apache.ignite.Ignition.startClient(Ignition.java:587)
> at
> org.apache.ignite.examples.client.ClientPutGetExample.main(ClientPutGetExample.java:45)
> Caused by: org.apache.ignite.client.ClientConnectionException: Connection
> refused
> at
> org.apache.ignite.internal.client.thin.io.gridnioserver.GridNioClientConnectionMultiplexer.open(GridNioClientConnectionMultiplexer.java:172)
> ... 11 more
> Caused by: java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.connect0(Native Method)
> at java.base/sun.nio.ch.Net.connect(Net.java:483)
> at java.base/sun.nio.ch.Net.connect(Net.java:472)
> at
> java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:692)
> at java.base/sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:100)
> at
> org.apache.ignite.internal.client.thin.io.gridnioserver.GridNioClientConnectionMultiplexer.open(GridNioClientConnectionMultiplexer.java:152)
> ... 11 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22798) Refactor Index heirarchy
Aleksey Plekhanov created IGNITE-22798: -- Summary: Refactor Index heirarchy Key: IGNITE-22798 URL: https://issues.apache.org/jira/browse/IGNITE-22798 Project: Ignite Issue Type: Task Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, ClientInlineIndex implements InlineIndex interface, which extends SortedSegmentedIndex, but all methods of ClientInlineIndex inherited from SortedSegmentedIndex throw "Unsupported" exception. Client index actually has nothing in common with SortedSegmentedIndex and should be inherited from Index. Inline size method of ClientInlineIndex actually required only to show inline size in system view. And I think, configured inline size will be enough on non-affinity node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22762) Calcite engine. Validated COALESCE return type not equals to relational algebra return type
[
https://issues.apache.org/jira/browse/IGNITE-22762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22762:
---
Description:
Reproducer:
{noformat}
sql("select coalesce(?, 1)", 0);
{noformat}
Fails with an exception:
{noformat}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
converted type:
RecordType(INTEGER EXPR$0) NOT NULL
rel:
LogicalProject(EXPR$0=[CASE(IS NOT NULL(?0), ?0, 1)])
LogicalValues(tuples=[[{ 0 }]])
at
org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:497)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:612)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:340)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:76)
~[classes/:?]
{noformat}
Root cause: COALESCE converted to CASE operator via
{{SqlCoalesceFunction#rewriteCall}} method. After convertion each operand is
cloned (IF IS NOT NULL (op) THEN op), and type is derived for each clone of
operand individually. These types can be different, and CASE operator can't
determine that operands are equal, since it has another type (see
SqlCaseOperator#inferTypeFromValidator and
SqlCaseOperator#inferTypeFromOperands methods)
was:
Reproducer:
{noformat}
sql("select coalesce(?, 1)", 0);
{noformat}
Fails with an exception:
{noformat}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
converted type:
RecordType(INTEGER EXPR$0) NOT NULL
rel:
LogicalProject(EXPR$0=[CASE(IS NOT NULL(?0), ?0, 1)])
LogicalValues(tuples=[[{ 0 }]])
at
org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:497)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:612)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:340)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:76)
~[classes/:?]
{noformat}
> Calcite engine. Validated COALESCE return type not equals to relational
> algebra return type
> ---
>
> Key: IGNITE-22762
> URL: https://issues.apache.org/jira/browse/IGNITE-22762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
>
> Reproducer:
> {noformat}
> sql("select coalesce(?, 1)", 0);
> {noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
> converted type:
> RecordType(INTEGER EXPR$0) NOT NULL
> rel:
> LogicalProject(EXPR$0=[CASE(IS NOT NULL(?0), ?0, 1)])
> LogicalValues(tuples=[[{ 0 }]])
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:497)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:612)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:76)
> ~[classes/:?]
> {noformat}
> Root cause: COALESCE converted to CASE operator via
> {{SqlCoalesceFunction#rewriteCall}} method. After convertion each operand is
> cloned (IF IS NOT NULL (op) THEN op), and type is derived for each clone of
> operand individually. These types can be different, and CASE operator can't
> determine that operands are equal, since it has another type (see
> SqlCaseOperator#inferTypeFromValidator and
> SqlCaseOperator#inferTypeFromOperands methods)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22762) Calcite engine. Validated COALESCE return type not equals to relational algebra return type
[
https://issues.apache.org/jira/browse/IGNITE-22762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22762:
---
Summary: Calcite engine. Validated COALESCE return type not equals to
relational algebra return type (was: Calcite engine. Validated COALESCE return
type can be invalid )
> Calcite engine. Validated COALESCE return type not equals to relational
> algebra return type
> ---
>
> Key: IGNITE-22762
> URL: https://issues.apache.org/jira/browse/IGNITE-22762
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
>
> Reproducer:
> {noformat}
> sql("select coalesce(?, 1)", 0);
> {noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
> converted type:
> RecordType(INTEGER EXPR$0) NOT NULL
> rel:
> LogicalProject(EXPR$0=[CASE(IS NOT NULL(?0), ?0, 1)])
> LogicalValues(tuples=[[{ 0 }]])
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:497)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:612)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:76)
> ~[classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22716) Calcite engine. DECODE can't convert INT to DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22716:
---
Labels: calcite ise (was: ise)
> Calcite engine. DECODE can't convert INT to DECIMAL
> ---
>
> Key: IGNITE-22716
> URL: https://issues.apache.org/jira/browse/IGNITE-22716
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
>
> Reproducer:
> {noformat}
> sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22762) Calcite engine. Validated COALESCE return type can be invalid
Aleksey Plekhanov created IGNITE-22762:
--
Summary: Calcite engine. Validated COALESCE return type can be
invalid
Key: IGNITE-22762
URL: https://issues.apache.org/jira/browse/IGNITE-22762
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Reproducer:
{noformat}
sql("select coalesce(?, 1)", 0);
{noformat}
Fails with an exception:
{noformat}
java.lang.AssertionError: Conversion to relational algebra failed to preserve
datatypes:
validated type:
RecordType(INTEGER NOT NULL EXPR$0) NOT NULL
converted type:
RecordType(INTEGER EXPR$0) NOT NULL
rel:
LogicalProject(EXPR$0=[CASE(IS NOT NULL(?0), ?0, 1)])
LogicalValues(tuples=[[{ 0 }]])
at
org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:497)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:612)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.rel(IgnitePlanner.java:340)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:76)
~[classes/:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22716) Calcite engine. DECODE can't convert INT to DECIMAL
[
https://issues.apache.org/jira/browse/IGNITE-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-22716:
--
Assignee: Aleksey Plekhanov
> Calcite engine. DECODE can't convert INT to DECIMAL
> ---
>
> Key: IGNITE-22716
> URL: https://issues.apache.org/jira/browse/IGNITE-22716
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> Reproducer:
> {noformat}
> sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
> Fails with an exception:
> {noformat}
> java.lang.AssertionError: For conversion to decimal,
> ConverterUtils#convertToDecimal method should be used instead.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
> ~[classes/:?]
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
> ~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18372) Add CDC metrics to KafkaToIgniteStreamer
[
https://issues.apache.org/jira/browse/IGNITE-18372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-18372:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Add CDC metrics to KafkaToIgniteStreamer
>
>
> Key: IGNITE-18372
> URL: https://issues.apache.org/jira/browse/IGNITE-18372
> Project: Ignite
> Issue Type: New Feature
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Major
> Labels: IEP-59, ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need metrics for received events count and last received event timestamp
> for the {{KafkaToIgniteStreamer}}, because there can be situations, when
> events sent by {{IgniteToKafkaStreamer}} are lost in Kafka due to Kafka
> failures or topic's retention configuration.
> In such situations we should be able to compare to sent messages count on
> source cluster with received messages count on destination one. Timestamp of
> last received event would be also useful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22738) Sql. Select from several nested subqueries fails when aliases are used
Aleksey Plekhanov created IGNITE-22738:
--
Summary: Sql. Select from several nested subqueries fails when
aliases are used
Key: IGNITE-22738
URL: https://issues.apache.org/jira/browse/IGNITE-22738
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Query:
{noformat}
select * from (select * from (select age as a from person) where a > 10)
{noformat}
Fails with an assertion:
{noformat}
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.normalizeExpression(GridSqlQuerySplitter.java:1485)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.normalizeExpression(GridSqlQuerySplitter.java:1473)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.normalizeQuery(GridSqlQuerySplitter.java:1364)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split0(GridSqlQuerySplitter.java:278)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:219)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:489)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:222)
at
org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:135)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22717) Calcite engine. User defined SQL views
Aleksey Plekhanov created IGNITE-22717:
--
Summary: Calcite engine. User defined SQL views
Key: IGNITE-22717
URL: https://issues.apache.org/jira/browse/IGNITE-22717
Project: Ignite
Issue Type: New Feature
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
A view is a virtual table whose contents are defined by a query. It's a
convenient mechanism to simplify queries.
Views are supported by many databases. Calcite Framework also supports user
defined views (see {{ViewTable.viewMacro}}) and we can add support of views to
Calcite based SQL engine to Ignite.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22716) Calcite engine. DECODE can't convert INT to DECIMAL
Aleksey Plekhanov created IGNITE-22716:
--
Summary: Calcite engine. DECODE can't convert INT to DECIMAL
Key: IGNITE-22716
URL: https://issues.apache.org/jira/browse/IGNITE-22716
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Reproducer:
{noformat}
sql("select decode(?, 0, 0, 1, 1.0)", 0);{noformat}
Fails with an exception:
{noformat}
java.lang.AssertionError: For conversion to decimal,
ConverterUtils#convertToDecimal method should be used instead.
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:214)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:178)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementRecursively(RexToLixTranslator.java:1144)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.implementCaseWhen(RexToLixTranslator.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1018)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:80)
~[classes/:?]
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:932)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:80)
~[classes/:?]
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
~[calcite-core-1.34.0.jar:1.34.0]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:206)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:199)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:809)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:180)
~[classes/:?]
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:516)
~[classes/:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864974#comment-17864974
]
Aleksey Plekhanov edited comment on IGNITE-15080 at 7/11/24 9:58 AM:
-
[~jooger], sure. I've unassigned the ticket.
was (Author: alex_pl):
[~alex_pl], sure. I've unassigned the ticket.
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864974#comment-17864974
]
Aleksey Plekhanov commented on IGNITE-15080:
[~alex_pl], sure. I've unassigned the ticket.
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-15080) Calcite. Functions extends string parameters by trailing spaces
[
https://issues.apache.org/jira/browse/IGNITE-15080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-15080:
--
Assignee: (was: Aleksey Plekhanov)
> Calcite. Functions extends string parameters by trailing spaces
> ---
>
> Key: IGNITE-15080
> URL: https://issues.apache.org/jira/browse/IGNITE-15080
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
>
> I discovered the strange behavior of functions with several string
> parameters, which then returns one of these parameters. In this case, the
> returned parameter string is expanded with trailing spaces to the length of
> the longest string.
> {code:java}
> query T
> SELECT COALESCE(COALESCE(null, 'world'), 'blabla')
>
> world - result is 'world ' - so we have extra trailing spaces from max
> length string parameter'blabla'{code}
> {code:java}
> query I
> SELECT DECODE(102, 101, 'IBM', 102, 'GRIDGAIN', 103, 'Hewlett Packard','BALL')
>
> GRIDGAIN - result is 'GRIDGAIN ' - so we have extra traiing spaces
> from max length string parameter 'Hewlett Packard'{code}
> see src/test/sql/function/generic/test_decode.test_ignore
> see src/test/sql/function/generic/test_coalesce.test_ignore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22707) Node fails when runtime exception occurs on snapshot start stage
Aleksey Plekhanov created IGNITE-22707:
--
Summary: Node fails when runtime exception occurs on snapshot
start stage
Key: IGNITE-22707
URL: https://issues.apache.org/jira/browse/IGNITE-22707
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer:
{code:java}
/** Any node failed. */
private boolean failed;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return
super.getConfiguration(igniteInstanceName).setFailureHandler((ignite, ctx) ->
failed = true);
}
/** @throws Exception If fails. */
@Test
public void testExceptionOnStartStage() throws Exception {
IgniteEx ignite = startGridsWithCache(2, dfltCacheCfg, CACHE_KEYS_RANGE);
IgniteFuture fut = snp(ignite).createSnapshot(SNAPSHOT_NAME, null,
false, onlyPrimary);
File snpDir = snp(ignite).snapshotLocalDir(SNAPSHOT_NAME);
assertTrue(snpDir.mkdirs());
File snpMeta = new File(snpDir,
IgniteSnapshotManager.snapshotMetaFileName(ignite.localNode().consistentId().toString()));
assertTrue(snpMeta.createNewFile());
assertThrowsAnyCause(log, fut::get, IgniteException.class, "Snapshot
metafile must not exist");
assertFalse(failed);
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22317) [Extensions] Release Ignite Spring Extensions
[ https://issues.apache.org/jira/browse/IGNITE-22317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864505#comment-17864505 ] Aleksey Plekhanov commented on IGNITE-22317: [~anovikov] can you please don't break compilation for JDK<17? It's a second time already when you break the master branch with this activity ([https://github.com/apache/ignite-extensions/commit/8f50f512ac48fe8be9660b4c78e99a55a7a41ae2|https://github.com/apache/ignite-extensions/commit/8f50f512ac48fe8be9660b4c78e99a55a7a41ae2,] [https://github.com/apache/ignite-extensions/commit/49cec55354df85ad592ed14d28d2e1dda53e072b]) We are still on java 8, and project should be compiled on java 8 and java 11, not only on java 17. Github workflow should use minimal supported java version. What for spring-auto-restdocs-json-doclet-jdk9 has been added? No information in the ticket about this. Are we use generated JSON javadoc anywhere? This plugin: * Break java8 compilation * Has some problem with jackson dependency version and check each version from all available repositories (and in some time in the future can be broken by the new jackson version, since version is not fixed) * Has been deprecated by the authors several years ago I propose to revert changes from [https://github.com/apache/ignite-extensions/commit/49cec55354df85ad592ed14d28d2e1dda53e072b] not related to release notes and maven-deploy-plugin. > [Extensions] Release Ignite Spring Extensions > - > > Key: IGNITE-22317 > URL: https://issues.apache.org/jira/browse/IGNITE-22317 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.16 > > > The following extenstions must be released: > - ignite-spring-data-ext > - ignite-spring-session-ext > - ignite-spring-cache-ext > - ignite-spring-tx-ext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22590) Calcite engine. Distribution by affinity function for columns with null values fails
Aleksey Plekhanov created IGNITE-22590:
--
Summary: Calcite engine. Distribution by affinity function for
columns with null values fails
Key: IGNITE-22590
URL: https://issues.apache.org/jira/browse/IGNITE-22590
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
If one side of the join converted to distribution of another side by affinity
function there can be an errors like:
{noformat}
Caused by: java.lang.IllegalArgumentException: Null key is passed for a
partition calculation. Make sure that an affinity key that is used is
initialized properly.
at
org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction.partition(RendezvousAffinityFunction.java:506)
at
org.apache.ignite.internal.processors.query.calcite.trait.AffinityAdapter.applyAsInt(AffinityAdapter.java:46)
at
org.apache.ignite.internal.processors.query.calcite.trait.Partitioned.targets(Partitioned.java:42)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.Outbox.flush(Outbox.java:233)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.Outbox.push(Outbox.java:141)
{noformat}
If input to rehash contains null values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22576) Calcite engine. Cast varchar to timestamp truncates millis
Aleksey Plekhanov created IGNITE-22576:
--
Summary: Calcite engine. Cast varchar to timestamp truncates millis
Key: IGNITE-22576
URL: https://issues.apache.org/jira/browse/IGNITE-22576
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer:
{noformat}
SELECT CAST('2021-01-01 01:02:03.456' AS TIMESTAMP)
{noformat}
Returns "2021-01-01 01:02:03.000"
Root cause: default precision for {{TIMESTAMP}} in Calcite is 0, so
{{TIMESTAMP}} threated as {{TIMESTAMP(0)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-16181) Calcite engine. Handle arithmetic overflows
[
https://issues.apache.org/jira/browse/IGNITE-16181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16181:
--
Assignee: Aleksey Plekhanov (was: Ilhom Ulmasov)
> Calcite engine. Handle arithmetic overflows
> ---
>
> Key: IGNITE-16181
> URL: https://issues.apache.org/jira/browse/IGNITE-16181
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required, ise
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, we silently ignore arithmetic overflows and return the wrong
> result, for example:
> {noformat}
> SELECT 2147483647 + 2147483647{noformat}
> Returns -2. But SQL standard says that exception should be thrown:
> {noformat}
> 5) If the most specific type of the result of an arithmetic operation is
> exact numeric, then Case:
> a) If the operator is not division and the mathematical result of the
> operation is not exactly representable with the precision and scale of the
> result data type, then an exception condition is raised: data exception —
> numeric value out of range.{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
[
https://issues.apache.org/jira/browse/IGNITE-22375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22375:
---
Description: We serialize {{long}} and {{int}} data types in communication
messages as {{varint}} to safe the space. UUID contains two {{long}} components
{{LeastSignificantBits}} and {{MostSignificantBits}}, which currently
serialized as {{varint}} too. But usually UUIDs are generated randomly and in
most cases there is no any space optimization for random {{long}} values. To
store {{long}} as 7 bytes or less in {{varint}} format (instead of 8 bytes to
store {{long}} as is) it's required top 15 bits of {{long}} to be 0.
Probability of such outcame for random long: 1/32768. (was: We serialize
{{long}} and {{int}} data types in communication messages as {{varint}} to safe
the space. UUID contains two {{long}} components {{LeastSignificantBits}} and
{{MostSignificantBits}}, which currently serialized as {{varint}} too. But
usually UUIDs are generated randomly and in most cases there is no any space
optimization for random {{long}} values. To store {{long}} as 7 bytes or less
in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's required
it's required top 15 bits of {{{}long{}}}. Probability of such outcame for
random long: 1/32768. )
> Inefficient serialization of UUIDs in communication messages
>
>
> Key: IGNITE-22375
> URL: https://issues.apache.org/jira/browse/IGNITE-22375
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We serialize {{long}} and {{int}} data types in communication messages as
> {{varint}} to safe the space. UUID contains two {{long}} components
> {{LeastSignificantBits}} and {{MostSignificantBits}}, which currently
> serialized as {{varint}} too. But usually UUIDs are generated randomly and in
> most cases there is no any space optimization for random {{long}} values. To
> store {{long}} as 7 bytes or less in {{varint}} format (instead of 8 bytes to
> store {{long}} as is) it's required top 15 bits of {{long}} to be 0.
> Probability of such outcame for random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
[
https://issues.apache.org/jira/browse/IGNITE-22375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22375:
---
Description: We serialize {{long}} and {{int}} data types in communication
messages as {{varint}} to safe the space. UUID contains two {{long}} components
{{LeastSignificantBits}} and {{MostSignificantBits}}, which currently
serialized as {{varint}} too. But usually UUIDs are generated randomly and in
most cases there is no any space optimization for random {{long}} values. To
store {{long}} as 7 bytes or less in {{varint}} format (instead of 8 bytes to
store {{long}} as is) it's required it's required top 15 bits of {{{}long{}}}.
Probability of such outcame for random long: 1/32768. (was: We serialize
{{long}} and {{int}} data types in communication messages as {{varint}} to safe
the space. UUID contains two {{long}} components {{LeastSignificantBits}} and {{
MostSignificantBits}}, which currently serialized as {{varint}} too. But
usually UUIDs are generated randomly and in most cases the are no any space
optimization for random {{long}} values. To store {{long}} as 7 bytes or less
in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's required
it's required top 15 bits of {{{}long{}}}. Probability of such outcame for
random long: 1/32768. )
> Inefficient serialization of UUIDs in communication messages
>
>
> Key: IGNITE-22375
> URL: https://issues.apache.org/jira/browse/IGNITE-22375
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We serialize {{long}} and {{int}} data types in communication messages as
> {{varint}} to safe the space. UUID contains two {{long}} components
> {{LeastSignificantBits}} and {{MostSignificantBits}}, which currently
> serialized as {{varint}} too. But usually UUIDs are generated randomly and in
> most cases there is no any space optimization for random {{long}} values. To
> store {{long}} as 7 bytes or less in {{varint}} format (instead of 8 bytes to
> store {{long}} as is) it's required it's required top 15 bits of
> {{{}long{}}}. Probability of such outcame for random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
[
https://issues.apache.org/jira/browse/IGNITE-22375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17856237#comment-17856237
]
Aleksey Plekhanov commented on IGNITE-22375:
JMH results:
{noformat}
Benchmark (ver) Mode Cnt
Score Error Units
JmhDirectByteBufferStreamBenchmark.writeReadIgniteUuid 3 thrpt3
173729,589 ± 11265,776 ops/s
JmhDirectByteBufferStreamBenchmark.writeReadIgniteUuid 4 thrpt3
582064,505 ± 4258,032 ops/s
JmhDirectByteBufferStreamBenchmark.writeReadUuid3 thrpt3
325306,801 ± 5562,056 ops/s
JmhDirectByteBufferStreamBenchmark.writeReadUuid4 thrpt3
1203484,342 ± 7195,944 ops/s
{noformat}
> Inefficient serialization of UUIDs in communication messages
>
>
> Key: IGNITE-22375
> URL: https://issues.apache.org/jira/browse/IGNITE-22375
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We serialize {{long}} and {{int}} data types in communication messages as
> {{varint}} to safe the space. UUID contains two {{long}} components
> {{LeastSignificantBits}} and {{
> MostSignificantBits}}, which currently serialized as {{varint}} too. But
> usually UUIDs are generated randomly and in most cases the are no any space
> optimization for random {{long}} values. To store {{long}} as 7 bytes or less
> in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's
> required it's required top 15 bits of {{{}long{}}}. Probability of such
> outcame for random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21492) Calcite engine: Unexpected error at query optimizer
[
https://issues.apache.org/jira/browse/IGNITE-21492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-21492:
--
Assignee: Aleksey Plekhanov
> Calcite engine: Unexpected error at query optimizer
> ---
>
> Key: IGNITE-21492
> URL: https://issues.apache.org/jira/browse/IGNITE-21492
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: QueryTest.java
>
>
> The reproducer attached. The query runs successfully on the old engine.
> {noformat}
> [2024-02-07T23:01:18,113][ERROR][test-runner-#1%calcite.QueryTest%][PrepareServiceImpl]
> Unexpected error at query optimizer.
> java.lang.AssertionError: null
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:67)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.dummyProject(RelFieldTrimmer.java:562)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.trimFields(RelFieldTrimmer.java:508)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_201]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_201]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_201]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_201]
> at org.apache.calcite.util.ReflectUtil$2.invoke(ReflectUtil.java:532)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.dispatchTrimFields(RelFieldTrimmer.java:283)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.RelFieldTrimmer.trim(RelFieldTrimmer.java:170)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.trimUnusedFields(SqlToRelConverter.java:554)
> ~[calcite-core-1.34.0.jar:1.34.0]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.trimUnusedFields(IgnitePlanner.java:464)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.PlannerHelper.optimize(PlannerHelper.java:95)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.PrepareServiceImpl.prepareQuery(PrepareServiceImpl.java:168)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.PrepareServiceImpl.prepareSingle(PrepareServiceImpl.java:94)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.lambda$null$5(CalciteQueryProcessor.java:515)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.lambda$queryPlan$0(QueryPlanCacheImpl.java:70)
> ~[classes/:?]
> at
> java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:70)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.lambda$parseAndProcessQuery$6(CalciteQueryProcessor.java:512)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.processQuery(CalciteQueryProcessor.java:632)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.parseAndProcessQuery(CalciteQueryProcessor.java:509)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:391)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3107)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3087)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3822)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3133)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3261)
> [classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:3083)
> [classes/:?]
> at
> org.apache.ignite.inte
[jira] [Updated] (IGNITE-22481) Documentation: Java thin client events
[ https://issues.apache.org/jira/browse/IGNITE-22481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22481: --- Fix Version/s: 2.17 > Documentation: Java thin client events > -- > > Key: IGNITE-22481 > URL: https://issues.apache.org/jira/browse/IGNITE-22481 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Priority: Major > Fix For: 2.17 > > > Add documentation for java thin client events (see > org.apache.ignite.client.events package) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22481) Documentation: Java thin client events
Aleksey Plekhanov created IGNITE-22481: -- Summary: Documentation: Java thin client events Key: IGNITE-22481 URL: https://issues.apache.org/jira/browse/IGNITE-22481 Project: Ignite Issue Type: Task Components: documentation Reporter: Aleksey Plekhanov Add documentation for java thin client events (see org.apache.ignite.client.events package) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22464) Java thin client: Introduce events for start/stop of client
Aleksey Plekhanov created IGNITE-22464: -- Summary: Java thin client: Introduce events for start/stop of client Key: IGNITE-22464 URL: https://issues.apache.org/jira/browse/IGNITE-22464 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, we have events for connect/disconnect and for start/end of each request. Sometimes it's required to track start/stop of client (for example, some metrics can be exposed on client start), so it's nice to have an ability to listen start/stop client events. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22439) Add tests for duplicate keys in Calcite
[ https://issues.apache.org/jira/browse/IGNITE-22439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22439: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Add tests for duplicate keys in Calcite > --- > > Key: IGNITE-22439 > URL: https://issues.apache.org/jira/browse/IGNITE-22439 > Project: Ignite > Issue Type: Test >Reporter: Andrei Nadyktov >Assignee: Andrei Nadyktov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 20m > Remaining Estimate: 0h > > In H2 Engine we have tests for cases when user tries to insert duplicate key > into table, and then CacheException is thrown. We need the same tests for > Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22189) Display Expiry Policy information in the system view
[
https://issues.apache.org/jira/browse/IGNITE-22189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22189:
---
Ignite Flags: Docs Required,Release Notes Required (was: Docs Required)
> Display Expiry Policy information in the system view
>
>
> Key: IGNITE-22189
> URL: https://issues.apache.org/jira/browse/IGNITE-22189
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Davydov
>Assignee: Maksim Davydov
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> The {{CacheView#expiryPolicyFactory}} method returns the ExpiryPolicyFactory
> string representation, which at this point is a simple className +@ +
> hashCode in hex, that is default {{Object#toString()}} behaviour. This is not
> informative for an end user of the API.
> In addition, it is useful to have information about existing cache entries
> that are about to expire (eligible for cache expiry policy).
> {*}TODO{*}:
> * To make the {{CacheView#expiryPolicyFactory}} method return readable,
> human-oriented output, one should refactor the method or
> {{Factory}} child classes to provide the cache expiry policy
> setting in readable form with policy type and ttl.
> * Within the cache view ({{{}CacheView{}}}), check the entries presence
> eligible for expiry policy. It can be done with O(logN) time complexity for
> in-memory, and O(number of partitions) for persistent mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[ https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851992#comment-17851992 ] Aleksey Plekhanov commented on IGNITE-22381: [~serge.korotkov], thanks for the review! Merged to master. > Extensions: Broken compilation by java8, java11 > > > Key: IGNITE-22381 > URL: https://issues.apache.org/jira/browse/IGNITE-22381 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > > Compilation on java8 is broken by IGNITE-21679 > Compilation on java11 is broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[ https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22381: --- Labels: ise (was: ) > Extensions: Broken compilation by java8, java11 > > > Key: IGNITE-22381 > URL: https://issues.apache.org/jira/browse/IGNITE-22381 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > > Compilation on java8 is broken by IGNITE-21679 > Compilation on java11 is broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[
https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850944#comment-17850944
]
Aleksey Plekhanov commented on IGNITE-22381:
[~serge.korotkov], [~nshakarov], [~anovikov] can you please have a look.
Changes have been made:
* Moved {{gatling-ext}} module under {{java-11+}} profile (some dependencies
of this module compiled with java-11 and can't be recognized by java-8).
* For {{java-11+}} profile target compiler version is set to 11 (the same we
have for the parent {{ignite}} project, even if we try to compile with 1.8
target, compiled classes still can't be used by java-8, but {{target=1.8}} or
{{release=1.8}} brokes usage of {{{}add-opens{}}}).
* Gatling maven plugin execution is disabled when {{-DskipTest}} or
{{-Dmaven.test.skip=true}} parameters are passed to maven (currently, this
plugin always executed on test phase, even if we disable tests explicitely).
* Options {{--add-opens}} also added to {{java-11+}} (They are not mandatory
for java-11, but they remove warnings about reflection usage).
Tested compilation locally on java8, java11, java17 (unfortunately java21
compilation still not working due to some {{spark-ext}} problems).
Tested with {{-DskipTest}} and {{-Dmaven.test.skip=true}} JVM options.
Started tests on both team-city servers.
> Extensions: Broken compilation by java8, java11
>
>
> Key: IGNITE-22381
> URL: https://issues.apache.org/jira/browse/IGNITE-22381
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Compilation on java8 is broken by IGNITE-21679
> Compilation on java11 is broken by IGNITE-22077
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22381) Extensions: Broken compilation by java8, java11
[ https://issues.apache.org/jira/browse/IGNITE-22381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22381: --- Description: Compilation on java8 is broken by IGNITE-21679 Compilation on java11 is broken by IGNITE-22077 was: Compilation by java8 broken by IGNITE-21679 Compilation by java11 broken by IGNITE-22077 > Extensions: Broken compilation by java8, java11 > > > Key: IGNITE-22381 > URL: https://issues.apache.org/jira/browse/IGNITE-22381 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > Compilation on java8 is broken by IGNITE-21679 > Compilation on java11 is broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22381) Extensions: Broken compilation by java8, java11
Aleksey Plekhanov created IGNITE-22381: -- Summary: Extensions: Broken compilation by java8, java11 Key: IGNITE-22381 URL: https://issues.apache.org/jira/browse/IGNITE-22381 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Compilation by java8 broken by IGNITE-21679 Compilation by java11 broken by IGNITE-22077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
Aleksey Plekhanov created IGNITE-22375:
--
Summary: Inefficient serialization of UUIDs in communication
messages
Key: IGNITE-22375
URL: https://issues.apache.org/jira/browse/IGNITE-22375
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
We serialize {{long}} and {{int}} data types in communication messages as
{{varint}} to safe the space. UUID contains two {{long}} components
{{LeastSignificantBits}} and {{
MostSignificantBits}}, which currently serialized as {{varint}} too. But
usually UUIDs are generated randomly and in most cases the are no any space
optimization for random {{long}} values. To store {{long}} as 7 bytes or less
in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's required
it's required top 15 bits of {{{}long{}}}. Probability of such outcame for
random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
[
https://issues.apache.org/jira/browse/IGNITE-22375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22375:
---
Labels: ise (was: )
> Inefficient serialization of UUIDs in communication messages
>
>
> Key: IGNITE-22375
> URL: https://issues.apache.org/jira/browse/IGNITE-22375
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> We serialize {{long}} and {{int}} data types in communication messages as
> {{varint}} to safe the space. UUID contains two {{long}} components
> {{LeastSignificantBits}} and {{
> MostSignificantBits}}, which currently serialized as {{varint}} too. But
> usually UUIDs are generated randomly and in most cases the are no any space
> optimization for random {{long}} values. To store {{long}} as 7 bytes or less
> in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's
> required it's required top 15 bits of {{{}long{}}}. Probability of such
> outcame for random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22375) Inefficient serialization of UUIDs in communication messages
[
https://issues.apache.org/jira/browse/IGNITE-22375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-22375:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Inefficient serialization of UUIDs in communication messages
>
>
> Key: IGNITE-22375
> URL: https://issues.apache.org/jira/browse/IGNITE-22375
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> We serialize {{long}} and {{int}} data types in communication messages as
> {{varint}} to safe the space. UUID contains two {{long}} components
> {{LeastSignificantBits}} and {{
> MostSignificantBits}}, which currently serialized as {{varint}} too. But
> usually UUIDs are generated randomly and in most cases the are no any space
> optimization for random {{long}} values. To store {{long}} as 7 bytes or less
> in {{varint}} format (instead of 8 bytes to store {{long}} as is) it's
> required it's required top 15 bits of {{{}long{}}}. Probability of such
> outcame for random long: 1/32768.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21225) Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
[
https://issues.apache.org/jira/browse/IGNITE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-21225.
Fix Version/s: 2.17
Release Note: Fixed redundant lambda object allocation in
ClockPageReplacementFlags#
Resolution: Fixed
[~timonin.maksim], thanks for the review! Merged to master.
> Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
> ---
>
> Key: IGNITE-21225
> URL: https://issues.apache.org/jira/browse/IGNITE-21225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Every time we call {{ClockPageReplacementFlags#setFlag/clearFlag}} methods
> the new lambda object is created, since lambda is accessing the variable in
> enclosing scope. \{{ClockPageReplacementFlags#setFlag}} method called every
> time when page is modified, so, it's a relatevily hot method and we should
> avoid new object allocation here.
> Here is the test to show redundant allocations:
>
> {code:java}
> /** */
> @Test
> public void testAllocation() {
> clockFlags = new ClockPageReplacementFlags(MAX_PAGES_CNT,
> region.address());
> int cnt = 1_000_000;
> ThreadMXBean bean = (ThreadMXBean)ManagementFactory.getThreadMXBean();
> // Warmup.
> clockFlags.setFlag(0);
> long allocated0 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> for (int i = 0; i < cnt; i++)
> clockFlags.setFlag(i % MAX_PAGES_CNT);
> long allocated1 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> assertTrue("Too many bytes allocated: " + (allocated1 - allocated0),
> allocated1 - allocated0 < cnt);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-21823: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Minor > Labels: ise, newbie > Fix For: 2.17 > > Time Spent: 40m > Remaining Estimate: 0h > > If you do not indicate in the configuration, the size of pageSize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21225) Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
[
https://issues.apache.org/jira/browse/IGNITE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21225:
---
Labels: ise (was: )
> Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
> ---
>
> Key: IGNITE-21225
> URL: https://issues.apache.org/jira/browse/IGNITE-21225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Every time we call {{ClockPageReplacementFlags#setFlag/clearFlag}} methods
> the new lambda object is created, since lambda is accessing the variable in
> enclosing scope. \{{ClockPageReplacementFlags#setFlag}} method called every
> time when page is modified, so, it's a relatevily hot method and we should
> avoid new object allocation here.
> Here is the test to show redundant allocations:
>
> {code:java}
> /** */
> @Test
> public void testAllocation() {
> clockFlags = new ClockPageReplacementFlags(MAX_PAGES_CNT,
> region.address());
> int cnt = 1_000_000;
> ThreadMXBean bean = (ThreadMXBean)ManagementFactory.getThreadMXBean();
> // Warmup.
> clockFlags.setFlag(0);
> long allocated0 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> for (int i = 0; i < cnt; i++)
> clockFlags.setFlag(i % MAX_PAGES_CNT);
> long allocated1 =
> bean.getThreadAllocatedBytes(Thread.currentThread().getId());
> assertTrue("Too many bytes allocated: " + (allocated1 - allocated0),
> allocated1 - allocated0 < cnt);
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22101) Performance drop for thin client requests
[ https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22101: --- Ignite Flags: (was: Release Notes Required) > Performance drop for thin client requests > - > > Key: IGNITE-22101 > URL: https://issues.apache.org/jira/browse/IGNITE-22101 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Fix For: 2.17 > > Attachments: perf_drop.png > > Time Spent: 1h > Remaining Estimate: 0h > > After IGNITE-21183 there is performance drop for thin client transactional > operations up to 38%: > !perf_drop.png|width=1083,height=168! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22028) Thin client: Implement invoke/invokeAll operations
[ https://issues.apache.org/jira/browse/IGNITE-22028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22028: --- Labels: IEP-122 ise (was: ise) > Thin client: Implement invoke/invokeAll operations > -- > > Key: IGNITE-22028 > URL: https://issues.apache.org/jira/browse/IGNITE-22028 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-122, ise > > We must implement invoke/invokeAll methods for thin client. > Dev. list thread and IEP should be started to discuss protocol and > implementation details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22101) Performance drop for thin client requests
[
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844343#comment-17844343
]
Aleksey Plekhanov edited comment on IGNITE-22101 at 5/7/24 3:30 PM:
Benchmark results (latancy, ms) after fix:
| | | |ignite-20240405-IGNITE-13114-fbdd3deb70| | |
ignite-20240426-IGNITE-22069-0947a8b9fb| | |
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark ("PESSIMISTIC",
"REPEATABLE_READ")|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"REPEATABLE_READ")|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark (
"OPTIMISTIC")|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
was (Author: alex_pl):
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark ("PESSIMISTIC",
"REPEATABLE_READ")|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"REPEATABLE_READ")|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark (
"OPTIMISTIC")|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: perf_drop.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22101) Performance drop for thin client requests
[
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844343#comment-17844343
]
Aleksey Plekhanov edited comment on IGNITE-22101 at 5/7/24 3:28 PM:
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark ("PESSIMISTIC",
"REPEATABLE_READ")|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"REPEATABLE_READ")|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark (
"OPTIMISTIC")|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
was (Author: alex_pl):
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark ("PESSIMISTIC",
"REPEATABLE_READ")|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"REPEATABLE_READ")|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark (
"OPTIMISTIC")|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: perf_drop.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22101) Performance drop for thin client requests
[
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844343#comment-17844343
]
Aleksey Plekhanov edited comment on IGNITE-22101 at 5/7/24 3:26 PM:
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark ("PESSIMISTIC",
"REPEATABLE_READ")|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"REPEATABLE_READ")|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark (
"OPTIMISTIC")|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark ("OPTIMISTIC",
"SERIALIZABLE")|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
was (Author: alex_pl):
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "PESSIMISTIC", "txi":
"REPEATABLE_READ"}}|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"REPEATABLE_READ"}}|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc":
"OPTIMISTIC"}}|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: perf_drop.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22101) Performance drop for thin client requests
[
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17844343#comment-17844343
]
Aleksey Plekhanov commented on IGNITE-22101:
Benchmark results (latancy, ms) after fix:
|
|ignite-20240405-IGNITE-13114-fbdd3deb70|ignite-20240426-IGNITE-22069-0947a8b9fb|
|storage|client_type|benchmark|value|error%|runs#|value|error%|runs#|dif%|
|MEM|Thin|PutAllBenchmark|5.21|±4.70%|3|5.24|±5.12%|3|+0.66%|
|MEM|Thin|PutAllSerializableTxBenchmark|38.17|±1.34%|3|38.40|±2.66%|3|+0.58%|
|MEM|Thin|PutAllTxBenchmark|53.43|±2.30%|3|53.72|±0.57%|3|+0.55%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "PESSIMISTIC", "txi":
"REPEATABLE_READ"}}|3.43|±3.52%|3|3.44|±4.35%|3|+0.53%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"REPEATABLE_READ"}}|2.22|±1.52%|3|2.23|±3.02%|3|+0.31%|
|MEM|Thin|PutBenchmark|0.46|±0.89%|3|0.46|±1.49%|3|+0.30%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc":
"OPTIMISTIC"}}|57.18|±1.64%|3|57.23|±1.24%|3|+0.10%|
|MEM|Thin|PutGetBatchBenchmark|8.32|±1.48%|3|8.32|±2.40%|3|-0.06%|
|MEM|Thin|PutGetBenchmark|0.85|±2.38%|3|0.85|±2.90%|3|-0.43%|
|MEM|Thin|GetAllPutAllTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|49.89|±2.02%|3|49.64|±1.51%|3|-0.49%|
|MEM|Thin|PutGetTxBenchmark \{"options": {"txc": "OPTIMISTIC", "txi":
"SERIALIZABLE"}}|3.06|±5.78%|3|3.03|±2.85%|3|-0.83%|
|MEM|Thin|PutTxImplicitBenchmark|0.70|±6.08%|3|0.68|±3.07%|3|-2.70%|
> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: perf_drop.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22101) Performance drop for thin client requests
[ https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22101: --- Description: After IGNITE-21183 there is performance drop for thin client transactional operations up to 38%: !perf_drop.png|width=1083,height=168! was: After IGNITE-21183 there is performance drop for thin client transactional operations up to 38%: !image-2024-04-24-18-40-52-125.png|width=884,height=137! > Performance drop for thin client requests > - > > Key: IGNITE-22101 > URL: https://issues.apache.org/jira/browse/IGNITE-22101 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Attachments: perf_drop.png > > > After IGNITE-21183 there is performance drop for thin client transactional > operations up to 38%: > !perf_drop.png|width=1083,height=168! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22101) Performance drop for thin client requests
[ https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-22101: --- Attachment: (was: image-2024-04-24-18-40-52-125.png) > Performance drop for thin client requests > - > > Key: IGNITE-22101 > URL: https://issues.apache.org/jira/browse/IGNITE-22101 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Attachments: perf_drop.png > > > After IGNITE-21183 there is performance drop for thin client transactional > operations up to 38%: > !image-2024-04-24-18-40-52-125.png|width=884,height=137! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22101) Performance drop for thin client requests
Aleksey Plekhanov created IGNITE-22101: -- Summary: Performance drop for thin client requests Key: IGNITE-22101 URL: https://issues.apache.org/jira/browse/IGNITE-22101 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Attachments: perf_drop.png After IGNITE-21183 there is performance drop for thin client transactional operations up to 38%: !image-2024-04-24-18-40-52-125.png|width=884,height=137! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22069) Fix contention on expiration for persistent caches
[
https://issues.apache.org/jira/browse/IGNITE-22069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838695#comment-17838695
]
Aleksey Plekhanov commented on IGNITE-22069:
Benchmark results ({{{}JmhCacheExpireBenchmark{}}}) on my laptop:
Before fix:
{noformat}
Benchmark (persistence) Mode Cnt Score
Error Units
JmhCacheExpireBenchmark.putWithExpire TRUE thrpt 3 29,968 ±
15,287 ops/ms
{noformat}
After fix:
{noformat}
Benchmark (persistence) Mode Cnt Score
Error Units
JmhCacheExpireBenchmark.putWithExpire TRUE thrpt3 172,777 ±
22,737 ops/ms
{noformat}
> Fix contention on expiration for persistent caches
> --
>
> Key: IGNITE-22069
> URL: https://issues.apache.org/jira/browse/IGNITE-22069
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We've fixed contention on expiration for in-memory caches by IGNITE-14341 and
> IGNITE-21929 tickets, but persistent caches use another method to expire
> entries and this method should be fixed too. Moreover, there are some other
> optimizations related to expiration we can made:
> # Use batch pending tree entries removal for persistent caches (already
> implemented for in-memory)
> # Randomize iteration over cache data stores during expiration to reduce
> contention
> # For each transaction, we try to expire entries for every cache in the
> cluster. At least we can limit the list of caches to caches related to
> transaction.
> # On cache destroy batch removal from pending entries tree can be used
> (instead of one-by-one deletion).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22069) Fix contention on expiration for persistent caches
Aleksey Plekhanov created IGNITE-22069: -- Summary: Fix contention on expiration for persistent caches Key: IGNITE-22069 URL: https://issues.apache.org/jira/browse/IGNITE-22069 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We've fixed contention on expiration for in-memory caches by IGNITE-14341 and IGNITE-21929 tickets, but persistent caches use another method to expire entries and this method should be fixed too. Moreover, there are some other optimizations related to expiration we can made: # Use batch pending tree entries removal for persistent caches (already implemented for in-memory) # Randomize iteration over cache data stores during expiration to reduce contention # For each transaction, we try to expire entries for every cache in the cluster. At least we can limit the list of caches to caches related to transaction. # On cache destroy batch removal from pending entries tree can be used (instead of one-by-one deletion). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22028) Thin client: Implement invoke/invokeAll operations
Aleksey Plekhanov created IGNITE-22028: -- Summary: Thin client: Implement invoke/invokeAll operations Key: IGNITE-22028 URL: https://issues.apache.org/jira/browse/IGNITE-22028 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We must implement invoke/invokeAll methods for thin client. Dev. list thread and IEP should be started to discuss protocol and implementation details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21990) [PerfStat] Report can skip properties/rows/reads records from remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-21990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-21990: --- Labels: ise (was: ) > [PerfStat] Report can skip properties/rows/reads records from remote nodes > -- > > Key: IGNITE-21990 > URL: https://issues.apache.org/jira/browse/IGNITE-21990 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > > In IGNITE-21863 after processing "query" record, we store aggregated result, > assuming that after this point there are no more records related to this > query. But such records may exist in other files (from other nodes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21990) [PerfStat] Report can skip properties/rows/reads records from remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-21990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-21990: --- Ignite Flags: (was: Docs Required,Release Notes Required) > [PerfStat] Report can skip properties/rows/reads records from remote nodes > -- > > Key: IGNITE-21990 > URL: https://issues.apache.org/jira/browse/IGNITE-21990 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > > In IGNITE-21863 after processing "query" record, we store aggregated result, > assuming that after this point there are no more records related to this > query. But such records may exist in other files (from other nodes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21929) Skip pending list extra cleanup in TTL Manager
[ https://issues.apache.org/jira/browse/IGNITE-21929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov resolved IGNITE-21929. Release Note: Fixed pending tree redundant cleanup on entries expiration Resolution: Fixed [~yuri.naryshkin], looks good to me. Merged to master. Thanks for the contribution! > Skip pending list extra cleanup in TTL Manager > -- > > Key: IGNITE-21929 > URL: https://issues.apache.org/jira/browse/IGNITE-21929 > Project: Ignite > Issue Type: Improvement >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: ise > Fix For: 2.17 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently when records expire with high rate, several threads (sys-stripe, > client-connector) try to cleanup those records and get stuck waiting to > acquire lock on main page of PendingEntriesTree. This is unnecessary > contention. > After introducing fix for IGNITE-14341 expired records PendingEntriesTree > cleanup is done using range. After that each record is deleted from dataTree. > And after that another attempt is done to remove each record from > PendingEntriesTree once again, which is not necessary as the record is > already removed. > This ticket is to improve cleaning up expired entries by skipping second > attempt to remove each record from PendingEntriesTree. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21990) [PerfStat] Report can skip properties/rows/reads records from remote nodes
Aleksey Plekhanov created IGNITE-21990: -- Summary: [PerfStat] Report can skip properties/rows/reads records from remote nodes Key: IGNITE-21990 URL: https://issues.apache.org/jira/browse/IGNITE-21990 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov In IGNITE-21863 after processing "query" record, we store aggregated result, assuming that after this point there are no more records related to this query. But such records may exist in other files (from other nodes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21961) Don't remove entries one-by-one for in-memory node on shutdown
Aleksey Plekhanov created IGNITE-21961: -- Summary: Don't remove entries one-by-one for in-memory node on shutdown Key: IGNITE-21961 URL: https://issues.apache.org/jira/browse/IGNITE-21961 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, for in-memory node we remove each entry one-by-one on cluster deactivation or on node shutdown. If there are a lot of entries in cache it can take a long time. But it's a redundant action, since all page memory will be released after deactivation/shutdown. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21886) Refactor CompressionProcessorImpl, move code partially to ignite-core module
Aleksey Plekhanov created IGNITE-21886: -- Summary: Refactor CompressionProcessorImpl, move code partially to ignite-core module Key: IGNITE-21886 URL: https://issues.apache.org/jira/browse/IGNITE-21886 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov CompressionProcessorImpl contains some logic, which can be used without extra dependencies. For example, all page compaction logic implemented in ignite-core, but we still can't enable SKIP_GARBAGE compression mode without ignite-compress module. Mode SKIP_GARBAGE without extra dependencies can be helpful for WAL page snapshot compression or for IGNITE-20697. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21863) [PerfStat] OOM when using build-report.sh from performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-21863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-21863:
--
Assignee: Aleksey Plekhanov
> [PerfStat] OOM when using build-report.sh from performance statistics
> --
>
> Key: IGNITE-21863
> URL: https://issues.apache.org/jira/browse/IGNITE-21863
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.16
>Reporter: Luchnikov Alexander
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: ise
>
> The problem is reproduced on a large volume collected using
> {code:java}
> ./control.sh --performance-statistics
> {code}
> statistics, in our cases the total volume was 50GB.
> Increasing xmx to 64gb did not solve the problem.
> {code:java}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.HashMap.resize(HashMap.java:700)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1112)
> at
> org.apache.ignite.internal.performancestatistics.handlers.QueryHandler.queryProperty(QueryHandler.java:160)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.deserialize(FilePerformanceStatisticsReader.java:345)
> at
> org.apache.ignite.internal.processors.performancestatistics.FilePerformanceStatisticsReader.read(FilePerformanceStatisticsReader.java:169)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.createReport(PerformanceStatisticsReportBuilder.java:124)
> at
> org.apache.ignite.internal.performancestatistics.PerformanceStatisticsReportBuilder.main(PerformanceStatisticsReportBuilder.java:69)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21866) Calcite engine. Add memory quotas control for Cursor.getAll() method
Aleksey Plekhanov created IGNITE-21866: -- Summary: Calcite engine. Add memory quotas control for Cursor.getAll() method Key: IGNITE-21866 URL: https://issues.apache.org/jira/browse/IGNITE-21866 Project: Ignite Issue Type: Improvement Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Cursor.getAll() method can collect a lot of rows before return result to the user and can cause OOM errors. We should control memory consumption for Cursor.getAll() the same way as we do for execution nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21478) OOM crash with unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-21478.
Fix Version/s: 2.17
Release Note: Fixed OOM crash on unstable topology
Resolution: Fixed
[~yuri.naryshkin], looks good to me. Merged to master. Thanks for the
contribution!
> OOM crash with unstable topology
>
>
> Key: IGNITE-21478
> URL: https://issues.apache.org/jira/browse/IGNITE-21478
> Project: Ignite
> Issue Type: Bug
>Reporter: Luchnikov Alexander
>Assignee: Yuri Naryshkin
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Attachments: HistoMinorTop.png, histo.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> User cases:
> 1) Frequent entry/exit of a thick client into the topology leads to a crash
> of the server node due to OMM.
> 2) Frequent creation and destroy of caches leads to a server node crash due
> to OOM.
> topVer=20098
> *Real case*
> Part of the log before the OOM crash, pay attention to *topVer=20098*
> {code:java}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f080abcd, uptime=3 days, 09:00:55.274]
> ^-- Cluster [hosts=4, CPUs=6, servers=2, clients=2, topVer=20098,
> minorTopVer=6]
> ^-- Network [addrs=[192.168.1.2, 127.0.0.1], discoPort=47500,
> commPort=47100]
> ^-- CPU [CPUs=2, curLoad=86.83%, avgLoad=21.9%, GC=23.9%]
> ^-- Heap [used=867MB, free=15.29%, comm=1024MB]
> ^-- Outbound messages queue [size=0]
> ^-- Public thread pool [active=0, idle=7, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> ^-- Striped thread pool [active=0, idle=8, qSize=0]
> {code}
> Histogram from heap-dump after node failed
> !histo.png!
> *MinorTop example*
> {code:java}
> @Test
> public void testMinorVer() throws Exception {
> Ignite server = startGrids(1);
> IgniteEx client = startClientGrid();
> String cacheName = "cacheName";
> for (int i = 0; i < 500; i++) {
> client.getOrCreateCache(cacheName);
> client.destroyCache(cacheName);
> }
> System.err.println("Heap dump time");
> Thread.sleep(100);
> }
> {code}
> {code:java}
> [INFO
> ][exchange-worker-#149%internal.IgniteOomTest%][GridCachePartitionExchangeManager]
> AffinityTopologyVersion [topVer=2, minorTopVer=1000],
> evt=DISCOVERY_CUSTOM_EVT, evtNode=52b4c130-1a01-4858-813a-ebc8a5dabf1e,
> client=true]
> {code}
> !HistoMinorTop.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21769) [ducktests] ignitetest/tests/dns_failure_test.py doesn't start with JDK11 and JDK17
[
https://issues.apache.org/jira/browse/IGNITE-21769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21769:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> [ducktests] ignitetest/tests/dns_failure_test.py doesn't start with JDK11 and
> JDK17
> ---
>
> Key: IGNITE-21769
> URL: https://issues.apache.org/jira/browse/IGNITE-21769
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Attachments: dns_failure_test_jdk11.zip, dns_failure_test_jdk17.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
> Ignite node can not start with the following exception:
> {noformat}
> Class not found: java.net.BlockingDnsInet4AddressImpl:
> check impl.prefix property in your properties file.
> java.lang.Error: System property impl.prefix incorrect
> at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
> at
> java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
> at java.base/java.net.InetAddress.(InetAddress.java:1141)
> at
> org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
> at
> org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
> at
> org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
> at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
> at
> org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
> at
> org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.prepareSpringContext(IgniteSpringHelperImpl.java:458)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:386)
> {noformat}
> Logs attached obtained with the below jdk versions:
> OpenJDK Runtime Environment 11.0.19+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 11.0.19+7
> OpenJDK Runtime Environment 17.0.7+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 17.0.7+7
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21630) Cluster falls apart on topology change when DNS service is unavailable
Aleksey Plekhanov created IGNITE-21630:
--
Summary: Cluster falls apart on topology change when DNS service
is unavailable
Key: IGNITE-21630
URL: https://issues.apache.org/jira/browse/IGNITE-21630
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Requests to DNS service performed synchroniously by some critical discovery
threads. Timeout for such requests can't be controlled by java code (see
[https://bugs.openjdk.org/browse/JDK-6450279]). This leads to segmentation of
nodes and falling apart cluster.
For example, stack of {{tcp-disco-msg-worker}} thread with request to DNS
service:
{noformat}
at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1330)
at java.net.InetAddress.getAllByName0(InetAddress.java:1283)
at java.net.InetAddress.getAllByName(InetAddress.java:1199)
at java.net.InetAddress.getAllByName(InetAddress.java:1127)
at java.net.InetAddress.getByName(InetAddress.java:1077)
at java.net.InetSocketAddress.(InetSocketAddress.java:220)
at
org.apache.ignite.internal.util.IgniteUtils.createResolved(IgniteUtils.java:9829)
at
org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9792)
at
org.apache.ignite.internal.util.IgniteUtils.toSocketAddresses(IgniteUtils.java:9770)
at
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.socketAddresses(TcpDiscoveryNode.java:392)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.getNodeAddresses(TcpDiscoverySpi.java:1267)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.interruptPing(ServerImpl.java:985)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$6800(ServerImpl.java:206)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:5433)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:3221)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2894)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21587) Calcite engine. Add operations authorization
Aleksey Plekhanov created IGNITE-21587:
--
Summary: Calcite engine. Add operations authorization
Key: IGNITE-21587
URL: https://issues.apache.org/jira/browse/IGNITE-21587
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently, Calcite engine do not check authorization to perform SELECT
operation.
For INSERT/UPDATE/DELETE/MERGE operations authorization is checked internally
by {{{}cache.invoke{}}}, but security context is not initialized and server
node security context is checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-14317) IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
[
https://issues.apache.org/jira/browse/IGNITE-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815247#comment-17815247
]
Aleksey Plekhanov commented on IGNITE-14317:
Related sync op fix:
https://github.com/apache/ignite/commit/126ab60fe6fa0f47e19a26dafecc7feb7c57b60b
> IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
> ---
>
> Key: IGNITE-14317
> URL: https://issues.apache.org/jira/browse/IGNITE-14317
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Denis Garus
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> [reproducer|https://github.com/apache/ignite/pull/8841/files]
> IgniteCache.removeAsync(key,val) fails inside an optimistic tx with the
> exception:
> {code:java}
> [17:39:28] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError[17:39:28]
> (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2955)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2937)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:3475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3217)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3212)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheFutureAdapter.onDone(GridCacheFutureAdapter.java:55)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:935)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setSkipValueResult(GridPartitionedSingleGetFuture.java:759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:636)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:133)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:131)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1143)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1908)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1529)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1422)
> at
> org.apache.ignite.internal.managers.communica
[jira] [Assigned] (IGNITE-14317) IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
[
https://issues.apache.org/jira/browse/IGNITE-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-14317:
--
Assignee: Aleksey Plekhanov
> IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
> ---
>
> Key: IGNITE-14317
> URL: https://issues.apache.org/jira/browse/IGNITE-14317
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Denis Garus
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> [reproducer|https://github.com/apache/ignite/pull/8841/files]
> IgniteCache.removeAsync(key,val) fails inside an optimistic tx with the
> exception:
> {code:java}
> [17:39:28] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError[17:39:28]
> (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2955)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2937)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:3475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3217)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3212)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheFutureAdapter.onDone(GridCacheFutureAdapter.java:55)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:935)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setSkipValueResult(GridPartitionedSingleGetFuture.java:759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:636)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:133)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:131)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1143)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1908)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1529)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1422)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
>
[jira] [Updated] (IGNITE-14317) IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
[
https://issues.apache.org/jira/browse/IGNITE-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14317:
---
Labels: ise (was: )
> IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
> ---
>
> Key: IGNITE-14317
> URL: https://issues.apache.org/jira/browse/IGNITE-14317
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Denis Garus
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> [reproducer|https://github.com/apache/ignite/pull/8841/files]
> IgniteCache.removeAsync(key,val) fails inside an optimistic tx with the
> exception:
> {code:java}
> [17:39:28] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError[17:39:28]
> (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2955)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2937)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:3475)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3217)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3212)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheFutureAdapter.onDone(GridCacheFutureAdapter.java:55)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:935)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setSkipValueResult(GridPartitionedSingleGetFuture.java:759)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:636)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:88)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:133)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:131)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1143)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1908)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1529)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1422)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:
[jira] [Updated] (IGNITE-21478) OOM crash with unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21478:
---
Labels: ise (was: )
> OOM crash with unstable topology
>
>
> Key: IGNITE-21478
> URL: https://issues.apache.org/jira/browse/IGNITE-21478
> Project: Ignite
> Issue Type: Bug
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
> Attachments: histo.png
>
>
> User cases:
> 1) Frequent entry/exit of a thick client into the topology leads to a crash
> of the server node due to OMM.
> 2) Frequent creation and destroy of caches leads to a server node crash due
> to OOM.
> topVer=20098
> Part of the log before the OOM crash, pay attention to *topVer=20098*
> {code:java}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f080abcd, uptime=3 days, 09:00:55.274]
> ^-- Cluster [hosts=4, CPUs=6, servers=2, clients=2, topVer=20098,
> minorTopVer=6]
> ^-- Network [addrs=[192.168.1.2, 127.0.0.1], discoPort=47500,
> commPort=47100]
> ^-- CPU [CPUs=2, curLoad=86.83%, avgLoad=21.9%, GC=23.9%]
> ^-- Heap [used=867MB, free=15.29%, comm=1024MB]
> ^-- Outbound messages queue [size=0]
> ^-- Public thread pool [active=0, idle=7, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> ^-- Striped thread pool [active=0, idle=8, qSize=0]
> {code}
> Histogram from heap-dump after node failed
> !histo.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21478) OOM crash with unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21478:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> OOM crash with unstable topology
>
>
> Key: IGNITE-21478
> URL: https://issues.apache.org/jira/browse/IGNITE-21478
> Project: Ignite
> Issue Type: Bug
>Reporter: Luchnikov Alexander
>Priority: Minor
> Labels: ise
> Attachments: histo.png
>
>
> User cases:
> 1) Frequent entry/exit of a thick client into the topology leads to a crash
> of the server node due to OMM.
> 2) Frequent creation and destroy of caches leads to a server node crash due
> to OOM.
> topVer=20098
> Part of the log before the OOM crash, pay attention to *topVer=20098*
> {code:java}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f080abcd, uptime=3 days, 09:00:55.274]
> ^-- Cluster [hosts=4, CPUs=6, servers=2, clients=2, topVer=20098,
> minorTopVer=6]
> ^-- Network [addrs=[192.168.1.2, 127.0.0.1], discoPort=47500,
> commPort=47100]
> ^-- CPU [CPUs=2, curLoad=86.83%, avgLoad=21.9%, GC=23.9%]
> ^-- Heap [used=867MB, free=15.29%, comm=1024MB]
> ^-- Outbound messages queue [size=0]
> ^-- Public thread pool [active=0, idle=7, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> ^-- Striped thread pool [active=0, idle=8, qSize=0]
> {code}
> Histogram from heap-dump after node failed
> !histo.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21366) AssertionError during the execution of the request
[
https://issues.apache.org/jira/browse/IGNITE-21366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21366:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> AssertionError during the execution of the request
> ---
>
> Key: IGNITE-21366
> URL: https://issues.apache.org/jira/browse/IGNITE-21366
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Nikolaev
>Assignee: Aleksandr Nikolaev
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If GridH2Table#cache size is greater than int, then we get an AssertionError:
> {code}
> -26T19:32:35,247][ERROR][main][] Test failed
> [test=RowCountTableStatisticsUsageTest#compareJoinsWithConditionsOnBothTables[cacheMode=REPLICATED],
> duration=10]
> java.lang.AssertionError: totalRowCnt=-4294967096, localRowCount=-2147483548
> at
> org.apache.ignite.internal.processors.query.h2.opt.TableStatistics.(TableStatistics.java:34)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.refreshStatsIfNeeded(GridH2Table.java:1055)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.getRowCountApproximation(GridH2Table.java:1013)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.getRowCountApproximation(GridH2IndexBase.java:226)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getRowCountApproximation(H2ScanIndex.java:158)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2ScanIndex.getCost(H2ScanIndex.java:289)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.opt.H2TableScanIndex.getCost(H2TableScanIndex.java:74)
> ~[classes/:?]
> at org.h2.table.Table.getBestPlanItem(Table.java:714)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.TableFilter.getBestPlanItem(TableFilter.java:224)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.table.Plan.calculateCost(Plan.java:121)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.testPlan(Optimizer.java:180)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.calculateBestPlan(Optimizer.java:81)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Optimizer.optimize(Optimizer.java:239)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.preparePlan(Select.java:1018)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Select.prepare(Select.java:884)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.dml.Explain.prepare(Explain.java:49)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> ~[h2-1.4.197.jar:1.4.197]
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> ~[h2-1.4.197.jar:1.4.197]
> at
> org.apache.ignite.internal.processors.query.h2.H2Connection.prepareStatementNoCache(H2Connection.java:191)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.H2PooledConnection.prepareStatementNoCache(H2PooledConnection.java:109)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:341)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse0(QueryParser.java:225)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parse(QueryParser.java:138)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1011)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3115)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3086)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3821)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3132)
> ~[
[jira] [Created] (IGNITE-21421) Calcite engine. Tuple (row) comparison is not working
Aleksey Plekhanov created IGNITE-21421:
--
Summary: Calcite engine. Tuple (row) comparison is not working
Key: IGNITE-21421
URL: https://issues.apache.org/jira/browse/IGNITE-21421
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currentrly, row comparison fails with an error and don't use index.
Reproducer:
{code:java}
sql("CREATE TABLE test (id INTEGER, val INTEGER)");
sql("CREATE INDEX test_idx ON test (id, val)");
sql("INSERT INTO test VALUES (0, 0), (0, 1), (1, 0), (1, 1)");
assertQuery("SELECT * FROM test WHERE (id, val) >= (?, ?)")
.withParams(0, 1)
//.matches(QueryChecker.containsIndexScan("PUBLIC", "TEST", "TEST_IDX"))
.returns(0, 1)
.returns(1, 0)
.returns(1, 1)
.check(); {code}
Exception:
{noformat}
Caused by: java.lang.RuntimeException: while resolving method 'ge[class
[Ljava.lang.Object;, class [Ljava.lang.Object;]' in class class
org.apache.calcite.runtime.SqlFunctions
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:449)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$BinaryImplementor.implementSafe(RexImpTable.java:1233)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:1950)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:1911)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21351) NPE on metric "TransactionsHoldingLockNumber" if tx is not initialized
[
https://issues.apache.org/jira/browse/IGNITE-21351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21351:
---
Labels: ise (was: )
> NPE on metric "TransactionsHoldingLockNumber" if tx is not initialized
> --
>
> Key: IGNITE-21351
> URL: https://issues.apache.org/jira/browse/IGNITE-21351
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> Attempt to get metric "TransactionsHoldingLockNumber" via JMX for not
> initialized transaction failed with:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.empty(IgniteTxStateImpl.java:448)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.empty(IgniteTxLocalAdapter.java:244)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter.txHoldingLockNum(TransactionMetricsAdapter.java:368)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter.getTransactionsHoldingLockNumber(TransactionMetricsAdapter.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter$TransactionMetricsSnapshot.getTransactionsHoldingLockNumber(TransactionMetricsAdapter.java:468)
> at
> org.apache.ignite.internal.TransactionMetricsMxBeanImpl.getTransactionsHoldingLockNumber(TransactionMetricsMxBeanImpl.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21351) NPE on metric "TransactionsHoldingLockNumber" if tx is not initialized
Aleksey Plekhanov created IGNITE-21351:
--
Summary: NPE on metric "TransactionsHoldingLockNumber" if tx is
not initialized
Key: IGNITE-21351
URL: https://issues.apache.org/jira/browse/IGNITE-21351
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Attempt to get metric "TransactionsHoldingLockNumber" via JMX for not
initialized transaction failed with:
{noformat}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.empty(IgniteTxStateImpl.java:448)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.empty(IgniteTxLocalAdapter.java:244)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter.txHoldingLockNum(TransactionMetricsAdapter.java:368)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter.getTransactionsHoldingLockNumber(TransactionMetricsAdapter.java:188)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionMetricsAdapter$TransactionMetricsSnapshot.getTransactionsHoldingLockNumber(TransactionMetricsAdapter.java:468)
at
org.apache.ignite.internal.TransactionMetricsMxBeanImpl.getTransactionsHoldingLockNumber(TransactionMetricsMxBeanImpl.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21349) Calcite engine. Failure on DDL when INCLUDE_SENSITIVE is false and DDL statement contains literals
Aleksey Plekhanov created IGNITE-21349:
--
Summary: Calcite engine. Failure on DDL when INCLUDE_SENSITIVE is
false and DDL statement contains literals
Key: IGNITE-21349
URL: https://issues.apache.org/jira/browse/IGNITE-21349
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Queries like:
{noformat}
CREATE INDEX ON test(val) INLINE_SIZE 10{noformat}
Can't be executed when property IGNITE_TO_STRING_INCLUDE_SENSITIVE=false.
Error stack:
{noformat}
java.lang.UnsupportedOperationException: class
org.apache.calcite.sql.SqlSyntax$7: SPECIAL at
org.apache.calcite.util.Util.needToImplement(Util.java:)
at org.apache.calcite.sql.SqlSyntax$7.unparse(SqlSyntax.java:129)
at org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:385)
at org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:466)
at org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:126)
at org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:156)
at org.apache.calcite.sql.SqlNode.toString(SqlNode.java:131)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.removeSensitive(CalciteQueryProcessor.java:555)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.parseAndProcessQuery(CalciteQueryProcessor.java:520)
{noformat}
SqlCall is created when cloning custom DDL commands and calcite can't unparse
it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21171) Calcite engine. Field nullability flag lost for data types with precession or scale
[
https://issues.apache.org/jira/browse/IGNITE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21171:
---
Release Note: SQL Calcite: Fixed column nullability check for data types
with precession or scale (was: Fixed column nullability check for data types
with precession or scale)
> Calcite engine. Field nullability flag lost for data types with precession or
> scale
> ---
>
> Key: IGNITE-21171
> URL: https://issues.apache.org/jira/browse/IGNITE-21171
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> CREATE TABLE test(id INT PRIMARY KEY, val DECIMAL(10,2));
> INSERT INTO test(id, val) VALUES (0, NULL); {code}
> Fail with: {{Column 'VAL' has no default value and does not allow NULLs}}
> But it works if {{val}} data type is {{DECIMAL}} or {{INT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21315) Node can't join the cluster when create index in progress and caches have the same deploymentId
[
https://issues.apache.org/jira/browse/IGNITE-21315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21315:
---
Summary: Node can't join the cluster when create index in progress and
caches have the same deploymentId (was: Node can't join then cluster when
create index in progress and caches have the same deploymentId)
> Node can't join the cluster when create index in progress and caches have the
> same deploymentId
> ---
>
> Key: IGNITE-21315
> URL: https://issues.apache.org/jira/browse/IGNITE-21315
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> Reproducer:
> {code:java}
> public class DynamicIndexCreateAfterClusterRestartTest extends
> GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName)
> .setDataStorageConfiguration(
> new
> DataStorageConfiguration().setDefaultDataRegionConfiguration(
> new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> cfg.setConsistentId(igniteInstanceName);
> return cfg;
> }
> /** */
> @Test
> public void testNodeJoinOnCreateIndex() throws Exception {
> IgniteEx grid = startGrids(2);
> grid.cluster().state(ClusterState.ACTIVE);
> grid.getOrCreateCache(new
> CacheConfiguration<>("CACHE1").setSqlSchema("PUBLIC")
> .setIndexedTypes(Integer.class, Integer.class));
> grid.getOrCreateCache(new
> CacheConfiguration<>("CACHE2").setSqlSchema("PUBLIC")
> .setIndexedTypes(Integer.class, TestValue.class));
> stopAllGrids();
> startGrids(2);
> try (IgniteDataStreamer ds =
> grid(0).dataStreamer("CACHE2")) {
> for (int i = 0; i < 1_500_000; i++)
> ds.addData(i, new TestValue(i));
> }
> GridTestUtils.runAsync(() -> {
> grid(1).cache("CACHE2").query(new SqlFieldsQuery("CREATE INDEX ON
> TestValue(val)")).getAll();
> });
> doSleep(100);
> stopGrid(0, true);
> cleanPersistenceDir(getTestIgniteInstanceName(0));
> startGrid(0);
> }
> /** */
> private static class TestValue {
> /** */
> @QuerySqlField
> private final int val;
> /** */
> private TestValue(int val) {
> this.val = val;
> }
> }
> }
> {code}
> Fails on last node join with an exception:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1124)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$ff7b936b$1(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$16(GridCacheProcessor.java:1754)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1863)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1753)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1699)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:1162)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1007)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3336)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3170)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21315) Node can't join then cluster when create index in progress and caches have the same deploymentId
[
https://issues.apache.org/jira/browse/IGNITE-21315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21315:
---
Labels: ise (was: )
> Node can't join then cluster when create index in progress and caches have
> the same deploymentId
>
>
> Key: IGNITE-21315
> URL: https://issues.apache.org/jira/browse/IGNITE-21315
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> Reproducer:
> {code:java}
> public class DynamicIndexCreateAfterClusterRestartTest extends
> GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName)
> .setDataStorageConfiguration(
> new
> DataStorageConfiguration().setDefaultDataRegionConfiguration(
> new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> cfg.setConsistentId(igniteInstanceName);
> return cfg;
> }
> /** */
> @Test
> public void testNodeJoinOnCreateIndex() throws Exception {
> IgniteEx grid = startGrids(2);
> grid.cluster().state(ClusterState.ACTIVE);
> grid.getOrCreateCache(new
> CacheConfiguration<>("CACHE1").setSqlSchema("PUBLIC")
> .setIndexedTypes(Integer.class, Integer.class));
> grid.getOrCreateCache(new
> CacheConfiguration<>("CACHE2").setSqlSchema("PUBLIC")
> .setIndexedTypes(Integer.class, TestValue.class));
> stopAllGrids();
> startGrids(2);
> try (IgniteDataStreamer ds =
> grid(0).dataStreamer("CACHE2")) {
> for (int i = 0; i < 1_500_000; i++)
> ds.addData(i, new TestValue(i));
> }
> GridTestUtils.runAsync(() -> {
> grid(1).cache("CACHE2").query(new SqlFieldsQuery("CREATE INDEX ON
> TestValue(val)")).getAll();
> });
> doSleep(100);
> stopGrid(0, true);
> cleanPersistenceDir(getTestIgniteInstanceName(0));
> startGrid(0);
> }
> /** */
> private static class TestValue {
> /** */
> @QuerySqlField
> private final int val;
> /** */
> private TestValue(int val) {
> this.val = val;
> }
> }
> }
> {code}
> Fails on last node join with an exception:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1124)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$ff7b936b$1(GridCacheProcessor.java:1869)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$16(GridCacheProcessor.java:1754)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1863)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1753)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1699)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:1162)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1007)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3336)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3170)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21315) Node can't join then cluster when create index in progress and caches have the same deploymentId
Aleksey Plekhanov created IGNITE-21315:
--
Summary: Node can't join then cluster when create index in
progress and caches have the same deploymentId
Key: IGNITE-21315
URL: https://issues.apache.org/jira/browse/IGNITE-21315
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer:
{code:java}
public class DynamicIndexCreateAfterClusterRestartTest extends
GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName)
.setDataStorageConfiguration(
new
DataStorageConfiguration().setDefaultDataRegionConfiguration(
new DataRegionConfiguration().setPersistenceEnabled(true)));
cfg.setConsistentId(igniteInstanceName);
return cfg;
}
/** */
@Test
public void testNodeJoinOnCreateIndex() throws Exception {
IgniteEx grid = startGrids(2);
grid.cluster().state(ClusterState.ACTIVE);
grid.getOrCreateCache(new
CacheConfiguration<>("CACHE1").setSqlSchema("PUBLIC")
.setIndexedTypes(Integer.class, Integer.class));
grid.getOrCreateCache(new
CacheConfiguration<>("CACHE2").setSqlSchema("PUBLIC")
.setIndexedTypes(Integer.class, TestValue.class));
stopAllGrids();
startGrids(2);
try (IgniteDataStreamer ds =
grid(0).dataStreamer("CACHE2")) {
for (int i = 0; i < 1_500_000; i++)
ds.addData(i, new TestValue(i));
}
GridTestUtils.runAsync(() -> {
grid(1).cache("CACHE2").query(new SqlFieldsQuery("CREATE INDEX ON
TestValue(val)")).getAll();
});
doSleep(100);
stopGrid(0, true);
cleanPersistenceDir(getTestIgniteInstanceName(0));
startGrid(0);
}
/** */
private static class TestValue {
/** */
@QuerySqlField
private final int val;
/** */
private TestValue(int val) {
this.val = val;
}
}
}
{code}
Fails on last node join with an exception:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1124)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1257)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$ff7b936b$1(GridCacheProcessor.java:1869)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$16(GridCacheProcessor.java:1754)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1863)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1753)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1699)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:1162)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1007)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3336)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3170)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21171) Calcite engine. Field nullability flag lost for data types with precession or scale
[
https://issues.apache.org/jira/browse/IGNITE-21171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807199#comment-17807199
]
Aleksey Plekhanov commented on IGNITE-21171:
[~jooger] it should allow null values, but it doesn't allowed now for types
with scale.
> Calcite engine. Field nullability flag lost for data types with precession or
> scale
> ---
>
> Key: IGNITE-21171
> URL: https://issues.apache.org/jira/browse/IGNITE-21171
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> CREATE TABLE test(id INT PRIMARY KEY, val DECIMAL(10,2));
> INSERT INTO test(id, val) VALUES (0, NULL); {code}
> Fail with: {{Column 'VAL' has no default value and does not allow NULLs}}
> But it works if {{val}} data type is {{DECIMAL}} or {{INT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21239) Take into account SUSPENDED transaction state for some operations
[
https://issues.apache.org/jira/browse/IGNITE-21239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-21239:
---
Description:
There are some operations in Ignite, which check only {{ACTIVE}} transaction
state, but looks like {{SUSPENDED}} state should also match the condition for
these operations.
Transaction state {{SUSPENDED}} is almost the same as {{{}ACTIVE{}}}, but
detached from a thread.
Examples of methods where {{SUSPENDED}} state should be threated the same way
as {{{}ACTIVE{}}}:
*
{{GridCachePartitionExchangeManager#dumpLongRunningOperations0}}
* {{IncrementalSnapshotMarkWalFuture#init}}
* {{TransactionMetricsAdapter#txHoldingLockNum}} (here condition is strange,
perhaps should be rewriten)
* {{IgniteTxManager#salvageTx}} (not sure about this method, further analysis
required)
was:
There are some operations in Ignite, which check only \{{ACTIVE}} transaction
state, but looks like {{SUSPENDED}} state should also match the condition for
these operations.
Transaction state {{SUSPENDED}} is almost the same as \{{ACTIVE}}, but detached
from a thread.
Examples of methods where {{SUSPENDED}} state should be threated the same way
as {{{}ACTIVE{}}}:
* {\{GridCachePartitionExchangeManager#dumpLongRunningOperations0}}
* {{IncrementalSnapshotMarkWalFuture#init}}
* {{TransactionMetricsAdapter#txHoldingLockNum}} (here condition is strange,
perhaps should be rewriten)
* {{IgniteTxManager#salvageTx}} (not sure about this method, further analysis
required)
> Take into account SUSPENDED transaction state for some operations
> -
>
> Key: IGNITE-21239
> URL: https://issues.apache.org/jira/browse/IGNITE-21239
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: ise
>
> There are some operations in Ignite, which check only {{ACTIVE}} transaction
> state, but looks like {{SUSPENDED}} state should also match the condition for
> these operations.
> Transaction state {{SUSPENDED}} is almost the same as {{{}ACTIVE{}}}, but
> detached from a thread.
> Examples of methods where {{SUSPENDED}} state should be threated the same way
> as {{{}ACTIVE{}}}:
> *
> {{GridCachePartitionExchangeManager#dumpLongRunningOperations0}}
> * {{IncrementalSnapshotMarkWalFuture#init}}
> * {{TransactionMetricsAdapter#txHoldingLockNum}} (here condition is strange,
> perhaps should be rewriten)
> * {{IgniteTxManager#salvageTx}} (not sure about this method, further
> analysis required)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21239) Take into account SUSPENDED transaction state for some operations
Aleksey Plekhanov created IGNITE-21239:
--
Summary: Take into account SUSPENDED transaction state for some
operations
Key: IGNITE-21239
URL: https://issues.apache.org/jira/browse/IGNITE-21239
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
There are some operations in Ignite, which check only \{{ACTIVE}} transaction
state, but looks like {{SUSPENDED}} state should also match the condition for
these operations.
Transaction state {{SUSPENDED}} is almost the same as \{{ACTIVE}}, but detached
from a thread.
Examples of methods where {{SUSPENDED}} state should be threated the same way
as {{{}ACTIVE{}}}:
* {\{GridCachePartitionExchangeManager#dumpLongRunningOperations0}}
* {{IncrementalSnapshotMarkWalFuture#init}}
* {{TransactionMetricsAdapter#txHoldingLockNum}} (here condition is strange,
perhaps should be rewriten)
* {{IgniteTxManager#salvageTx}} (not sure about this method, further analysis
required)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805032#comment-17805032
]
Aleksey Plekhanov commented on IGNITE-21185:
[~dkryukov] {{name()}} method returns interned string (see
[https://github.com/apache/ignite/blob/master/modules/calcite/src/main/java/org/apache/ignite/internal/processors/query/calcite/trait/DistributionFunction.java#L59]),
so it's safe to use {{==}} operator here.
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21225) Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
Aleksey Plekhanov created IGNITE-21225:
--
Summary: Redundant lambda object allocation in
ClockPageReplacementFlags#setFlag
Key: IGNITE-21225
URL: https://issues.apache.org/jira/browse/IGNITE-21225
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Every time we call {{ClockPageReplacementFlags#setFlag/clearFlag}} methods the
new lambda object is created, since lambda is accessing the variable in
enclosing scope. \{{ClockPageReplacementFlags#setFlag}} method called every
time when page is modified, so, it's a relatevily hot method and we should
avoid new object allocation here.
Here is the test to show redundant allocations:
{code:java}
/** */
@Test
public void testAllocation() {
clockFlags = new ClockPageReplacementFlags(MAX_PAGES_CNT, region.address());
int cnt = 1_000_000;
ThreadMXBean bean = (ThreadMXBean)ManagementFactory.getThreadMXBean();
// Warmup.
clockFlags.setFlag(0);
long allocated0 =
bean.getThreadAllocatedBytes(Thread.currentThread().getId());
for (int i = 0; i < cnt; i++)
clockFlags.setFlag(i % MAX_PAGES_CNT);
long allocated1 =
bean.getThreadAllocatedBytes(Thread.currentThread().getId());
assertTrue("Too many bytes allocated: " + (allocated1 - allocated0),
allocated1 - allocated0 < cnt);
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21183) Thin client: Avoid blocking of client-connector threads by transactional operations
Aleksey Plekhanov created IGNITE-21183:
--
Summary: Thin client: Avoid blocking of client-connector threads
by transactional operations
Key: IGNITE-21183
URL: https://issues.apache.org/jira/browse/IGNITE-21183
Project: Ignite
Issue Type: Improvement
Components: thin client
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Currently client-connector threads (workers for thin-client operations) can be
blocked for a long time by cache operation within transaction. If there is not
enough threads configured it can lead to deadlocks. For example, if we have
{{n}} threads and {{n+1}} clients which start the pessimistic transaction and
try to modify the same key, first client lock the key, other {{n}} clients wait
on locked key and hold the whole thread put by blocking operations.
Commit/rollback from the first client can never be proceeded, since all threads
are occupied, and threads can't be released, since they are waiting for
commit/rollback from the first client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21171) Calcite engine. Field nullability flag lost for data types with precession or scale
Aleksey Plekhanov created IGNITE-21171:
--
Summary: Calcite engine. Field nullability flag lost for data
types with precession or scale
Key: IGNITE-21171
URL: https://issues.apache.org/jira/browse/IGNITE-21171
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Reproducer:
{code:java}
CREATE TABLE test(id INT PRIMARY KEY, val DECIMAL(10,2));
INSERT INTO test(id, val) VALUES (0, NULL); {code}
Fail with: {{Column 'VAL' has no default value and does not allow NULLs}}
But it works if {{val}} data type is {{DECIMAL}} or {{INT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21161) Node failure on timeout objects intersection
Aleksey Plekhanov created IGNITE-21161:
--
Summary: Node failure on timeout objects intersection
Key: IGNITE-21161
URL: https://issues.apache.org/jira/browse/IGNITE-21161
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Timeout objects (see \{{GridTimeoutObject}} class) can intersect by timeout
timestamp and id for different subsystem (for example compute and atomic near
cache update) with the following error:
{noformat}
[11:32:10,554][SEVERE][sys-stripe-3-#4%timeout.TimeoutObjectsIntersectionTest1%][]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.AssertionError: Duplicate timeout object
found:
o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout@11da2a92]]
java.lang.AssertionError: Duplicate timeout object found:
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$DeferredUpdateTimeout@11da2a92
at
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor.addTimeoutObject(GridTimeoutProcessor.java:114)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.sendDeferredUpdateResponse(GridDhtAtomicCache.java:3480)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3427)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:147)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:310)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:305)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1164)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:605)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:406)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:324)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:112)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:314)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1527)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1420)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:637)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It can happend when one subsystem use IgniteUuid with local node Id and another
subsystem use IgniteUuid with remote node id.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21131) Calcite engine. OR operator with dynamic parameters can't be used for index scans
Aleksey Plekhanov created IGNITE-21131:
--
Summary: Calcite engine. OR operator with dynamic parameters can't
be used for index scans
Key: IGNITE-21131
URL: https://issues.apache.org/jira/browse/IGNITE-21131
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Calcite can compose OR operator with literals to SEARCH/SARG, and SEARCH/SARG
can be used for index scans. But we can't do this for OR operator with dynamic
parameters.
For example expression {{a IN (1, 2, 3)}} can be converted to {{a = 1 OR a = 2
OR a = 3}} and after that can be converted to {{SEARCH(a, SARG(1, 2, 3))}}, but
expression {{a IN (?, ?, ?)}} can be converted only to {{a = ? OR a = ? OR a =
?}} and can't be used for index scan.
To fix this issue we can create ranges from dynamic parameters during planning,
sort and remove intersections from these ranges in runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21082) Ignite Extensions: Excessive memory usage by performance statistics QueryHandler
[ https://issues.apache.org/jira/browse/IGNITE-21082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-21082: --- Summary: Ignite Extensions: Excessive memory usage by performance statistics QueryHandler (was: Ignite Extensions: Exessive memory usage by performance statistics QueryHandler) > Ignite Extensions: Excessive memory usage by performance statistics > QueryHandler > > > Key: IGNITE-21082 > URL: https://issues.apache.org/jira/browse/IGNITE-21082 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > > When processing queryProperty or queryRows events new strings are generated > and written to the maps (as keys or values). Most of strings are not unique > and already contained in other maps as keys or values, but as different > instance. GC can't collect doublicated strings and this leads to OOM in some > cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21082) Ignite Extensions: Exessive memory usage by performance statistics QueryHandler
Aleksey Plekhanov created IGNITE-21082: -- Summary: Ignite Extensions: Exessive memory usage by performance statistics QueryHandler Key: IGNITE-21082 URL: https://issues.apache.org/jira/browse/IGNITE-21082 Project: Ignite Issue Type: Bug Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov When processing queryProperty or queryRows events new strings are generated and written to the maps (as keys or values). Most of strings are not unique and already contained in other maps as keys or values, but as different instance. GC can't collect doublicated strings and this leads to OOM in some cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
